MVP scoping and prototyping

What this actually solves

You have been describing the same idea out loud for three months. Every developer who hears it produces a different number, and the numbers are nowhere near each other. There is no way to tell which of them has misunderstood, because the thing being quoted has never been written down. The difference is not in their rates. It is in what each of them assumed was included, and nobody wrote the assumptions down, so you are comparing three private interpretations of a conversation.

What is actually being bought here is a translated version of the idea — one document that can be handed to three different people so that the numbers coming back are comparable. And alongside it, something to show. Investors and first customers do not respond to slides describing software; they respond to something they can hold on a phone and tap through. Those are two different deliverables and they answer two different problems, which is why this engagement produces both.

What we do, and in what order

1. Problem statement and three real conversations. One sentence on what the product is for, then three people who have the problem, on calls. Not friends, not investors — the people whose day this is meant to change. Two to four days.
2. Fifteen to twenty user stories, then the cutting. Writing the stories is easy. Cutting them is the entire skill of this service — choosing eight from twenty and having the nerve to call the other twelve phase two. This is where a founder's expectations and a buildable first version get reconciled. Two to three days.
3. The scope document. What is in, the data model, the screen list, and an out-of-scope section that should be the longest part of the document. If anyone reading it has to guess, it is not finished. Three to five days.
4. The prototype. Real screens, realistic sample data, every navigation link working, no login, no database, no API calls of any kind. A fixed banner on every screen reading that this is a prototype with sample data. Buttons that would do something out of scope say so in plain words rather than silently doing nothing. Built mobile-width first, because it will be opened on a phone in a meeting. Three to six days.
5. Show it to those three users, and write down what happened. Not what they said about the screens — what they said about their own work while holding it. This is the step that deletes features. Two to four days.
6. A three-route proposal. Minimum, middle and complete, each with a price, a delivery window and its own exclusions, so the decision in front of you is a choice between three defined things rather than a single number to accept or refuse. Two days.

The prototype is deployed to a link on Vercel or Netlify rather than sent as a zip file, because you forward that link to an investor the same evening. Screens are drawn in Excalidraw or Figma, the scope document lives somewhere you can comment on it directly, and the whole prototype opens by clicking one file if you ever need it offline.

What moves the price

The range is $1,000–$10,000 over 2–6 weeks, and three things decide where a project lands in it.

How many screens the prototype has. Six screens and one main flow sits at the bottom of the range. Three user roles each with their own dashboard is three prototypes sharing a stylesheet, and it is priced that way.

Whether real user testing is included. Scope and prototype alone is the lower end. Adding three sessions with real users, and the written record of what they did rather than what they said, is what carries the engagement up the range — and it is the part that consistently earns its cost back in the build.

How much has to survive scrutiny. A prototype for internal alignment can be rough. One that will be opened in front of investors on a phone, with sample data that has to look like a real business, takes longer and is worth the difference.

What usually goes wrong

The prototype gets too good. It looks finished, so you conclude it nearly is, and ask whether we can just make it live. Refusing at that point reads as reluctance and the relationship sours over a misunderstanding that was created on day one. Two cures, both necessary — the banner on every single screen, and this sentence said out loud on the first call before anything is built: there is no database, so anything you type disappears when you refresh, and that is on purpose.

The out-of-scope list is an afterthought. Twenty stories in, nothing named out, and a price on the front. That is not a scope, it is a wish list with a number attached, and every argument in the build will be about something it did not mention. The exclusions section being the longest part of the document is not padding — it is the part that protects both sides when the build starts.

The prototype grows a login screen. Authentication, accounts and password resets are the first things people reach for because real products have them, and they are the fastest way to burn prototype time teaching nobody anything. No user in a feedback session learns anything from typing a password. Anything that needs a real backend belongs in the build, and a prototype that starts behind a sign-in form has already stopped being a prototype.