Ignite: from idea to a working prototype

A prototype answers "can this be built and does it feel right in someone's hands". It does not answer "will anyone pay for this". If your real doubt is whether the market wants it, a landing page, a pre-sale, or twenty customer conversations will tell you more for a fraction of the money. Build the prototype once the commercial question is settled.

If the technical path is obvious and the integrations are proven, a prototype is a detour. You are paying to confirm something you already believe. Take the brief straight to a scoped build instead and put the money into the real thing.

A prototype needs a pass mark set before it starts — the specific thing a user must be able to do, and what result counts as proof. Without it, everyone judges the result against a different picture in their head and the project ends in argument rather than a decision. We set that pass mark in the scoping session, and if it cannot be agreed, we say so.

A prototype trades hardening for speed: lighter error handling, fewer edge cases, no load testing. That is the deal that makes it fast and cheap. If it has to carry real customers, real money, or compliance obligations from launch, you want a scoped build — and paying for a prototype first just delays it.

A prototype proves a concept works; an MVP is the smallest version you can actually sell. The prototype answers a question — can this be built, does the workflow hold up, will a user get it — and it is allowed to be rough behind the scenes. An MVP has to survive real customers, so it needs the hardening, the error handling and the support path a prototype skips. Most people asking for an MVP want a prototype first, and it is usually the cheaper order to do them in.

Close enough in practice, and the words get used interchangeably. If there is a distinction worth keeping: a proof of concept tests whether the hard technical thing is possible, often with no interface at all, while a prototype is something a person can use and react to. Ignite delivers the second — a working product you can put in front of users and investors, not a slide or a clickable mock-up.

An Ignite prototype is $25,000 to $50,000, fixed. Your price is scoped and defined within that band before anything starts, and it comes from a written requirements document rather than an estimate. The one-hour scoping session that produces it is free. Below that band you are usually buying a design mock-up rather than working software; well above it you are buying a production build, which is a different engagement.

Four to eight weeks from an agreed brief to something you can use. The variable is rarely the build — it is how quickly scope gets agreed and how much of the data or the integrations already exist. Anyone promising a working product in a week is describing a design mock-up.

It is real code and you own it, but be honest with yourself about what it is. A prototype is built for speed, so parts of it will be rewritten when it becomes a production system — that is normal and it is cheaper than over-engineering something you were not sure about. What carries forward intact is the hard-won knowledge: the workflow that worked, the integrations that proved out, and a requirements document written from something real rather than a guess.

You do — the code, the repository, the IP, all of it. No licence fee and no dependency on us to keep it running. If you take it to another team to build out, it is documented well enough for them to pick up.

That is the point, and it is the cheapest possible way to arrive at a full build with the risk already taken out. The next step is Amplify: the same team, a fixed price, and a scope written from what the prototype taught you rather than from assumptions. If the operation around the product is the harder problem, an Apex partnership is the other direction. Either way you are deciding with evidence instead of a pitch deck.

When the risk is not technical. If you already know the thing can be built and the real question is whether anyone will pay for it, research and a landing page will answer that faster and cheaper than code. A prototype is also the wrong buy when you need production-grade from day one — real users, real data, real uptime — because building it twice costs more than building it properly once. Ignite is worth it when the uncertainty is in the build, the interaction, or whether people will actually use the thing in front of them.