Custom software prototype
Your software running and testable, two weeks after the kickoff workshop.
You describe the system. We write the requirements down, build against them, and hand over working software with the source code. Two weeks from the kickoff workshop, matching what was approved, at least 75% below the baseline you agree in writing.
Two weeks from the kickoff workshop. The clock starts on the day the requirements are approved at the workshop, and that day goes into the contract.
The requirements are written before anything is built. What is handed over is measured against that document. If it does not match, it is not done and it is not billed as done.
The On-Time Prototype Guarantee. Late, short of the written requirements, or less than 75% below the agreed baseline, and you get your money back.
The system everyone has agreed to and nobody has seen
The need is real. Somebody in operations has been asking for a year, somebody in IT has sized it, and the budget line exists. What does not exist is anything a person can open, so the discussion runs on documents, and every reader pictures a slightly different system.
The quotes that come back price the whole thing at once. A discovery phase, a ramp-up, a team learning your domain before it writes a line, and a commitment made before one person has used one screen. Most of that estimate is the cost of somebody arriving.
So the decision waits for the next steering meeting. It has waited for a few already.
Why two weeks is a real number
The discovery is compressed into one workshop instead of six weeks of meetings. Two hours, everyone with an opinion in the room, and the output is a written requirements document that both sides approve.
The build is short because AI writes the parts of a codebase that have been written a million times before: the scaffolding, the data access, the forms, the wiring that eats most of an estimate and none of the thinking. It does not decide what to build and it does not judge whether the result is correct. That is where the two weeks go.
What you receive is ordinary software in an ordinary repository, reviewed line by line, tested against the requirements document and handed over with the source, because a prototype nobody can extend is a demo.
What you get
One fixed scope, agreed in writing before the build starts.
A requirements workshop, two hours. The scope is fixed here and written down, screen by screen and rule by rule. Anything outside that document is outside the prototype, and both sides know that before the clock starts.
The build: generation, testing and refinement. Code generated against the approved document, tested against the same document, then corrected until it does what the document says.
Working software you can put in front of people. Deployed where you can reach it and share the link. Real screens, real data entry, flows a colleague or a client can finish.
A presentation and handover session, two hours. A walkthrough of what was built, what was deliberately left out, and what the next step would involve.
The source code and written documentation. Yours. Architecture, dependencies, how to run it, how to deploy it. Written so another supplier could pick it up without calling.
What the two weeks look like
Day 0
The requirements workshop. Two hours. The scope is fixed and approved. The clock starts here.
Days 1 to 7
Generation and build. The first working screens are visible inside the first week.
Days 8 and 9
Testing against the requirements document, and the corrections that come out of it.
Day 10
The presentation session. Two hours. Working software, source code and documentation handed over.
Ten working days is two calendar weeks, counted from the day the requirements are approved. If access to a system we need is outstanding, the clock pauses until it is granted, and you are told on the day it happens.
The On-Time Prototype Guarantee
Handed over inside two weeks of the kickoff workshop, matching the approved requirements, at least 75% below the baseline written down with you. Miss any of the three and you get your money back.
The requirements document is the only measure. It is approved before the build starts. What is handed over is compared against that document and nothing else. Neither side moves it afterwards.
The cost baseline is agreed in writing first. In the workshop we write down what the same prototype would cost to build the conventional way, in developer days at the rates you already pay. That figure goes into the contract as the baseline. This is a promise with a refund behind it. It is not a measurement of past work, and without a baseline in writing the clause does not apply.
Defects against the requirements are fixed at no cost. Nobody can guarantee software with no defects. What is guaranteed is that anything failing to match the approved requirements is corrected without a further invoice.
What is needed from you. Two hours of workshop time from somebody who can approve the scope, access to the systems the prototype touches, and an answer within a working day while we build.
How you claim. Email info@peakcodeconsulting.ch within thirty days of handover, naming the requirement that was missed or the figure that was exceeded. You get an answer within ten working days.
These terms go into the contract before the build starts, in these words. You can hold us to every one of them.
Who this is for
This is for you if
- A custom system is on the roadmap and the budget line already exists.
- Something people can use would settle an argument the documents cannot.
- Somebody on your side can approve the scope in one two-hour session.
- You can grant access to the systems the prototype has to talk to.
This is not for you if
- You need production software carrying real customers and live data on day one. That is the full build, and it comes after.
- The scope is still being argued about. Two weeks cannot absorb a discovery phase.
- The prototype depends on a third party who has not committed to a date.
- You want the build without the written requirements. The guarantee is settled against them.
The questions we get asked
- What does it cost?
- It is quoted in writing after the first call, against the scope you bring. There is no list price, because pricing a prototype before seeing the requirements is guessing. The fee is fixed before the build starts and does not move.
- Is a prototype the same as an MVP?
- No. A prototype answers a question: does this work, do people understand it, will they use it. An MVP carries real customers and real data. The prototype is how you find out whether the MVP is worth building, and it becomes the specification for it.
- Who owns the result?
- You do, including the source code and the documentation, from the handover day. There is no runtime licence, no hosting lock-in and nothing that has to be renewed to keep the software working.
- Is AI writing our code?
- AI writes the parts that are the same in every codebase, and they are reviewed line by line before they are committed. The architecture, the domain decisions and the judgement about correctness stay with us. What is handed over is code somebody read.
- What happens after the two weeks?
- One of three things. Take the prototype to your users and stop there. Commission the full build with the prototype as the specification. Or hand the source code to your own team. The recommendation on day ten says which of the three we would choose and why.
Tell us what the software has to do
The first call is free.
Describe the system. We come back within 48 hours on whether it fits two weeks, what would have to be cut if it does not, and what the workshop would cover.
If the honest answer is that this is the wrong shape of engagement for what you are describing, the reply says so.