App prototype development
Two weeks after the kickoff workshop, your app is running software.
You describe the app. We write the requirements down, build against them, and hand over working software with its source. Two weeks from the kickoff workshop, matching what was written.
Two weeks from the kickoff workshop. The clock starts the day the requirements are signed off. That day goes in the contract.
Something people can open and use. A user, a client or a board clicks through it. Slides settle nothing. Working software settles it.
The On-Time Prototype Guarantee. Late, or short of the written requirements, and you get your money back.
The app that keeps getting quoted and never gets built
The budget is approved, or close to it. The idea has been described in a dozen meetings, and everyone carries a different picture of it.
The quotes price a full build. Discovery, design, months before anyone sees a screen that works. A large commitment to an app that exists in a document.
So the decision waits, through another quarter, and the app you could have tested is still an idea.
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 requirements document both sides sign.
The build is short because AI writes the parts every app repeats: screens, forms, navigation, data access, the plumbing that eats most of a quote. What the app must do, and whether the result is right, stay human judgements.
You receive an ordinary application in an ordinary repository, reviewed line by line and handed over with the source.
What you get
One fixed scope, agreed in writing before the build starts.
A two-hour requirements workshop. The screens, the flows and the one thing this prototype must prove get decided and written down.
Code generation, testing and refinement. The build itself, against the signed document, with a working version in front of you partway through.
A working app, deployed where you can reach it. Colleagues, customers or a board open a link. No local setup needed.
A two-hour presentation and next steps. What was built, what was left out, and what a full build would involve.
The source code and written documentation. Yours. Architecture, dependencies, how to run it and how to deploy it.
What the two weeks look like
Day 0
The requirements workshop, two hours. The scope is fixed and signed. The clock starts here.
Days 1 to 7
The build. A working version reaches you after the first week, while a wrong assumption is cheap to fix.
Days 8 and 9
Testing against the requirements document, and the corrections that follow.
Day 10
Presentation, handover of the source and documentation, and a note on what a full build takes.
Two weeks means ten working days from the day the requirements are signed. If a system access we need is outstanding, the clock pauses.
The On-Time Prototype Guarantee
Delivered inside two weeks of the kickoff workshop, matching the signed requirements, at a build cost at least 75% below the conventional-build baseline agreed in writing. Miss one of the three and you get your money back.
The 75% is a promise with a refund behind it. It commits us on your build. It says nothing about work done for anyone else.
The baseline is agreed in writing first. Bring the written estimate you hold for building the same thing conventionally. It goes into the contract. Without one, this clause does not apply.
The requirements document is the only other measure. It is signed before the build starts, and what is handed over is compared against it alone.
Defects against the requirements are fixed at no cost. Nobody can guarantee software with no defects. Anything failing to match the signed requirements is corrected at no charge.
How you claim. Email info@peakcodeconsulting.ch within thirty days of the handover, naming the date, requirement or figure that was missed. You get an answer within ten working days.
These terms go into the contract before the build starts, in these words.
Who this is for
This is for you if
- You have an app in mind and money set aside for it.
- Something must be shown to users or a board before the full build is approved.
- Somebody on your side can fix the scope in one two-hour session.
- You can grant access to the systems the prototype must talk to.
This is not for you if
- The idea is still being argued about. Two weeks cannot absorb a discovery phase.
- You need a production-hardened app on day ten. This is a prototype.
- The app depends on a third party with no committed date.
- You want the prototype without the written requirements. The guarantee is settled against them.
The questions we get asked
- What does it cost?
- Quoted in writing after the first call, against the scope you bring. There is no list price: pricing an app before seeing the requirements is guessing.
- Is this a clickable mock-up?
- No. It is running software with real code behind it, deployed where you can send someone a link.
- Can the prototype become the real product?
- It can, and that is what the source code is for. Some of it will be rebuilt for production load. The day ten presentation says which parts and why.
- Is AI writing our code?
- AI writes the parts that repeat in every app, reviewed line by line before they are committed. Architecture and correctness stay with people.
- Who owns the result?
- You do, including the source and the documentation, from the handover day. There is no runtime licence and no lock-in.
Tell us what the app has to do
The first call is free.
Describe the app in two sentences. We come back within 48 hours on whether it fits two weeks and what the workshop would cover.
If this is the wrong shape of engagement for what you describe, the reply says so.