The cost of a first version: what sets the number

You have a product in your head and no number on paper. You ask three people what a first version costs and get three answers that differ more than the briefs they read. One of them is guessing. The answer you keep hearing is that the price comes after a review, and that answer is honest, but it does not help you plan anything. So this article is about the mechanism instead: what the number is made of, why two estimates for the same brief disagree, and how the number becomes predictable before anybody writes a line.

There is no figure in this text, and that is not an accident. A single number without the reasoning behind it is a guess with a decimal point. What you can have before any work starts is a mechanism: a short list of things you can name, a way of billing that keeps each step small, and the questions that expose the difference between two proposals. Predictable is not the same as cheap. It means you know what moves the number, and you agreed on that before the work began.

Every estimate is built from the same parts, and the parts are boring. Workflows. The data model. The outside systems the product has to reach. The people who supply access and materials. Learn to count those parts and you can read any proposal, including the weak ones.

1. What the number is actually made of

Start with workflows. A workflow is one thing a person can finish: a lead becomes a customer, an order becomes a payment and then a shipment, an employee files a request that a manager approves. Each workflow is a chain of screens, rules, states and permissions. Workflows that look similar on a slide are rarely the same work, because the rules behind them are different, and the rules are where the days go.

Then the data model. This is what exists, how the pieces relate, and what must never leak to the wrong person. If two customers can see each other's rows, that is a decision made before the first table, not a bug you find later. A product that keeps one company's documents away from another's has a different shape from a single-account tool, and an estimate has to know which one you are building. The isolation question is worth reading properly: why tenant data has to be isolated.

Roles multiply everything. One admin screen becomes several when a manager, a clerk and an accountant each need their own view with their own limits. Every role is another set of screens, another set of rules, another set of checks. The same goes for the states nobody puts on a slide: a refund, a cancellation, a duplicate record, an approval that gets withdrawn. A first version can hold few of them, but it has to name them, because they decide what done means.

2. The outside world costs more than the inside

The screens are yours. Payments, email, SMS, telephony, invoicing, an accounting system, a courier API, an old CRM: none of those are. Every system the product has to reach is its own piece of work, with its own credentials, its own test environment, its own documentation, and its own idea of what an error looks like. A payment that is one box on the diagram is really a chain with retries, callbacks, a refund path, and a state where the money moved and your database did not.

Waiting belongs in the cost too. A merchant account goes under review. A third party answers a documentation question once a week. Nobody is typing during that time, and the calendar still moves. An estimate that assumes every access arrives on the first day is a different estimate from one that names which accounts you have to open and who chases them.

So ask how much of the product talks to the outside world. Notifications alone mean a provider, a delivery trail, and a way to see what failed. An export into somebody else's system makes you responsible for a schedule you do not control. The count of connections matters more than the count of pages.

3. Who supplies the materials changes the number

Part of the work is yours to supply: access, credentials, content, design, and a person who can say yes. Each of those carries a date. If the design arrives late, the build waits, and an estimate that assumed design on day one was really estimating a different project. The same applies to copy, to product rules, and to the person allowed to decide. An estimate with no decision-maker named is an estimate with an open end.

The attachments that make a start predictable are simple to write down: the outcome in one sentence, the flows that are in, the flows that are out, the checks you will accept the work by, and who supplies what. What to attach before development starts lists them. The written form of that agreement, and what to do when it changes, is covered in how to freeze scope before the build. Both exist so the first number you agreed on still describes the work you get.

4. Why two estimates for the same brief differ

Two developers read the same brief and return different numbers, and both are usually honest. One asked about roles and the other did not. One priced the happy path, the other priced what happens when the payment fails. One assumed a template for the interface, the other assumed a designer. One counted the workflows you wrote down. The other counted the ones you implied and never listed.

The difference is findable. Ask what each estimate includes and, more usefully, what it excludes. A number with nothing named around it is a hope with a date attached. The questions that separate two proposals are the ones about the outside world, the roles, the missing materials, and the states where something goes wrong. Answer them once, in writing, and every proposal afterwards answers the same questions, which is the only way two of them can be compared.

5. How the work is actually billed

One slice at a time. Not one number for the whole product, agreed once and defended for months. Each slice carries its own scope and its own number, agreed before you commit to it, and each slice ends with something you can open and check. If the next slice turns out different from what both of you imagined, only that slice moves. You are never arguing about a total that was written before anyone understood the data model.

This is how the number becomes predictable without being fixed. You know the cost of the next step before the next step starts. You can stop after any slice and keep something that already runs. A change becomes a new line with its own number instead of a renegotiation of the whole job. It also keeps the first version small on purpose: one workflow goes live, the architecture is decided before the code, and the rest of the product lands on top of something real.

6. The questions that make the number predictable

Ask these before anyone commits, in writing, and keep the answers next to the proposal:

• Which workflows are in the first version, and which ones are named as out.
• Which roles exist, and what each one can see and do.
• Which outside systems the product reaches, who opens those accounts, and who waits for them.
• Which materials come from you: access, design, content, decisions, and on what dates.
• How a change becomes a new line with its own number, agreed before the work on it starts.

A developer who cannot answer these yet is telling you something useful: the review has not happened, and the number you were given is a placeholder. Bring someone in to answer them before you compare proposals, not after you have signed one. The questions cost a conversation. A wrong first version costs a rebuild.

Services cover the review that turns a brief into that list of workflows, roles and connections. Selected work shows the same mechanism on products that already run, with the operation next to the result. If you want the first version planned and built in slices like that, product development from scratch is where that starts, and you can write to me. Leave passwords and customer data out of the message.