Somebody at your company built a working version of the app you need. They built it with an AI tool, people can click through it, and now the question is what to hand a developer, and whether you first have to pay for a proposal.
Bring the prototype. It is the most useful thing you can put in front of a developer, because it already answers most of the questions a proposal phase exists to answer. Two years ago I would not have asked a client for one before we start. Now what I ask for is logos, colours and vibe-coded MVPs (first versions built by describing them to an AI tool), and I love when clients do that.
What does a working prototype already answer?
A prototype holds the decisions. Every screen in it is a choice about what the app does, every form is a choice about what information it keeps, and everything you did not build is a choice about what can wait. Those choices are what a developer needs from you before anything useful can be built, and you have made them in a form that is harder to misread than a written description.
The way I see it, a proposal or discovery phase exists to get those same decisions down in writing. Each of its usual questions already has an answer somewhere in what you built.
| What a proposal phase tries to find out | Where the answer already is in your prototype |
|---|---|
| Which screens the app needs and how people move between them | The screens you built and the order you click through them |
| Who uses it and what each of them needs to see | The people you had in mind when you built each screen |
| What information it holds | The fields, lists and forms you made |
| What belongs in the first version | Everything you built, and everything you decided to leave for later |
| Where the difficult parts are | The things you tried and could not get working |
A feature you gave up on tells a developer where the hard part is, and you found that out by building.
What should you bring to the first conversation?
The prototype is the centre of it, and a few things around it make it far more useful. None of them needs tidying up first.
- The prototype itself, running, with a login we can use if it has one.
- The chat history with the AI tool, if you still have it. It shows why you made most decisions, including the ones you changed your mind about.
- A short list of what you gave up on or left for later. A few lines are enough.
- Who uses it, or who will, and which of them matter most in the first version.
- What it has to connect to, such as the CRM, the accounting tool, a spreadsheet the team lives in or the login your company already uses.
- What colleagues said when they tried it, the complaints included.
If some of that does not exist, bring what does. The running prototype on its own is already a better starting point than a written description of the same idea.
Do you have to buy a proposal before anything gets built?
Not on this service, whether you bring a prototype or not. We work in monthly cycles using Shape Up, the method 37signals published: work is shaped before it starts and built inside a fixed cycle, and ours is the month. Shaping is part of the work we do in that month, so your prototype goes straight into the first month.
This is how that month runs when you turn up with one.
- We get into your setup. Repositories, hosting, domains, accounts and whatever already exists, including your prototype. That is usually done inside the first week.
- You get a board. Everything you want built goes on it, and you decide the order. The decisions from your prototype are an obvious first set to put on it, and nothing gets estimated into a proposal first.
- We build, month after month. Each piece shows up for you as it lands, and nothing ships until a person has checked every significant step. If you decide to stop, the running product, the repository and every account are already yours.
The plan for this is full-time build work, month to month, with 30 days notice to cancel or pause. It is the plan meant for turning your own prototype into an application your company runs in production, and the web app and SaaS development page sets out what it costs.
What does a prototype not have to answer?
A prototype is built to show what the app does for the people using it, and yours does that. A second set of questions only comes up once a company starts depending on the app, and nobody expects a prototype to settle them:
- who is allowed to see and change what, once real customers or colleagues log in
- what happens when something breaks at an awkward hour, and who notices
- how it connects to the systems the rest of the company already runs on
- who keeps it running, updated and backed up after launch
Those questions are the part you are hiring someone for. I think writing software keeps getting faster and more of the work now sits in running an app than in writing it, which is the same argument we made about websites in building is getting easier, running is not. You worked out what the app should do. Our job is to answer the second set of questions around it and keep it running.
What if what you built is a website?
Sometimes the prototype turns out to be a marketing website rather than an application behind a login: pages about the company, a contact form, a blog. That is a different job with a different setup, and our headless website service is the page to read instead.
If what you built is an app, an internal tool or a portal, web app and SaaS development is where the prototype comes in, and you can bring it to the first call.