App prototype development
Your app, working and clickable, two weeks after the kickoff workshop.
You bring the idea. We run a two-hour requirements workshop, build the prototype, and hand you the working app with its source code and documentation. Two weeks from that workshop, matching the requirements you approved, or we refund your fee.
A real app, not a slide deck. Screens your users can open, data they can enter, flows they can finish. You can put it in front of a client and watch what happens.
Two weeks from the kickoff workshop. Not two weeks from your first email. The clock starts the day we sit down and write the requirements together.
The On-Time Prototype Guarantee. On time, matching the requirements we agreed in writing, and at least 75% below the conventional build baseline we wrote down with you. Miss one and you get your fee back.
Free call, no obligation. You leave it knowing what your prototype would take and whether it is worth building at all.
The app that stays a document
You have the idea written down. Maybe a spec, maybe a deck, maybe a folder of screenshots from tools you liked. Everyone who reads it agrees with something slightly different.
So you ask for quotes. They come back with months of discovery, a team you have to keep fed, and a number that turns a test into a commitment. The budget exists. Spending it on a guess is what stops you.
Meanwhile the decision that matters is still open, because nobody has held the thing. Users cannot react to a paragraph. A board cannot fund a paragraph.
How two weeks is possible
We generate the app instead of typing it. The workshop produces a written requirements document, and that document drives the code generation. What used to be weeks of scaffolding takes hours.
Then the slow part starts, and it is the part that matters. We test what came out against your requirements, fix it, and refine it until the flows hold up under a real person.
AI writes the code. We decide what it should do and we check every screen against the document you approved. That split is why two weeks from the workshop is a date we put in the contract, and why the requirements are written before anything is generated.
What you get
One fixed scope, agreed in writing before anything is generated.
A requirements workshop, two hours. We take the idea apart on a call and write down what the prototype must do, screen by screen. You approve that document. It becomes the thing the guarantee is measured against.
The build. Code generation, testing and refinement, run against your requirements rather than a demo dataset.
A presentation session, two hours. We walk the working app with you, agree what happens next, and tell you what a full build would involve.
The working app. Handed over running, with a link you can share for thirty days. The documentation carries the deployment steps, so your own team can host it after that. Put it in front of users, clients or your board the same day.
The source code and the documentation. Yours at handover. If the full build goes to your own team or to somebody else, the code goes with you.
What the two weeks look like
Day 0
The requirements workshop. Two hours. We write down what the prototype does and you approve it. The clock starts here.
Days 1 to 7
Generation and build. You see the first working screens inside the first week, not at the end.
Days 8 and 9
Testing against the requirements document, and the fixes that come out of it.
Day 10
The presentation session. Two hours. We hand over the app, the source code and the documentation, and agree the next step.
Ten working days is two calendar weeks, counted from the workshop. If we are waiting on a decision or an access we do not have yet, the clock pauses, and we tell you the day it happens.
The On-Time Prototype Guarantee
Two weeks from the workshop, matching the requirements you approved, and at least 75% below the conventional build baseline we agreed in writing. Miss any of the three and we refund your fee.
The requirements are written before we build. The workshop ends with a document and you approve it. Nobody moves it afterwards, us included, so "matches the requirements" means something you can check.
The cost baseline is written down with you before the fee is fixed. We agree what the same prototype would take to build the conventional way, in developer days at the rates you already pay. Your fee for this build sits at least 75% under that number. That is a promise with a refund behind it. We are not quoting a result from somebody else’s project.
Defects are ours to fix. Anything that does not do what the approved requirements say is a defect, and we fix it at no cost for thirty days after handover. Email info@fijisolutions.net inside that window. Nobody can promise software with no bugs. We can promise who pays for them, and for how long.
What we need from you. Two hours for the workshop, one person who can approve the requirements, and answers within a working day while we build. That is the whole list.
How you claim. Email info@fijisolutions.net within thirty days of handover, naming which of the three we missed. You get an answer within ten working days.
These terms go into the contract before we build, in these words. You can hold us to every one of them.
Who this is for
This is for you if
- You have an app in mind and a budget already set aside for building it.
- You can describe what it should do in two hours, with one person who can approve it.
- You need something users, clients or a board can open before the money is committed.
- You want the source code, because the full build may go to your own team later.
This is not for you if
- You need a production system carrying real customers and real data on day one. This is a prototype.
- The requirements cannot be settled by anyone available within two hours.
- You want a clickable design mockup with nothing behind it. A design tool does that faster.
- Nobody can be in the room for the workshop or the handover.
The questions we get asked
- What does it cost?
- We quote it after the first call, in writing, against what your prototype actually needs. There is no list price and no rate card. The fee is fixed before anything is built and it does not move afterwards, and the guarantee ties it to the baseline we write down together.
- Is a prototype the same as an MVP?
- No. A prototype exists to answer a question. Does this work, do people understand it, will they use it. An MVP carries real customers and real data. Answer that question first and you know whether the MVP is worth building. That is what this prototype is for.
- Who owns the code?
- You do, from handover. Source code and documentation come with the prototype. If you take the full build to your own team or to another supplier, nothing here holds you back.
- If AI writes it, why do we need you?
- Because generated code is easy to produce and hard to trust. The value sits in the requirements written before it and the testing and refinement after it. That is where the two weeks actually go.
- What happens after the two weeks?
- Three things can happen next. You take the prototype to users and stop there. You commission the full build, with the prototype as the specification. Or you hand the code to your own team. All three suit us, and you decide once you have seen it.
Tell us what the app should do
Describe the app in a couple of lines. We will come back with what a prototype of it would take and what it would answer for you.
Free, no obligation, no sales pitch.
Prefer to skip the form? Book the call directly: Pick a time on Calendly
Free call, no obligation. You leave it knowing what your prototype would take and whether it is worth building at all.
We reply within one business day.