Two teams describe what sounds like the same product and end up with wildly different builds. Not because one was careless, but because the things that actually shape a software project are almost never the things in the feature list. The feature list is the visible part. What determines the shape of the work sits underneath it, and it is knowable in advance if you look at the right things.
The feature list is the least informative document
Ask what a system needs to do and you get nouns and verbs: a dashboard, user accounts, reporting, notifications. Every one of those can be an afternoon or a quarter, and the words give you no way to tell which.
"Reporting" is the classic. It can mean a page showing five numbers pulled straight from a table. It can also mean letting people define their own views across data that lives in four systems, with permissions deciding who sees which rows. Same word, same position on the list, entirely different pieces of engineering.
What separates them is not size. It is how much meaning the software has to hold. The five-number page holds none — it reads what is there and prints it. The self-serve version has to understand what a valid combination is, what a row means to different roles, and what should happen when two sources disagree. Meaning is the expensive thing, and it never appears on a feature list.
Four things that genuinely shape a build
How many states your data can be in. A record that is either draft or published is simple. A record that can be draft, in review, approved, published, superseded or withdrawn — where some transitions are allowed only for some roles, and one of them triggers a notification to a third party — is a different animal. The number of screens barely moved. The number of things that must never happen went up sharply.
Counting states is the single most useful estimating exercise we know, and you can do it yourself before talking to anyone. Take your central entity and list every condition it can be in and every legal move between them. If that fits on a sticky note, your build is probably smaller than you fear. If it needs a whiteboard, that is where the work lives.
What it has to talk to. An integration is rarely just an API call. It is somebody else's model of the world that you now have to reconcile with yours: their idea of a customer, their timing, their notion of what counts as an error. Two systems that disagree about identity — theirs keys on email, yours on account — generate work in every direction forever.
The number of integrations matters far less than whether they agree. Three read-only feeds that all describe the same thing the same way are straightforward. One two-way sync with a system that has its own opinion about who a customer is can outweigh the rest of the build.
Who the software must answer to. Internal tooling used by ten colleagues can be forgiving. If a screen is confusing, someone asks. Software that faces customers, handles regulated data, or produces numbers that go to a board answers to a different standard: audit trails, permissions that hold up under scrutiny, behaviour that stays correct when someone does something unexpected. That standard is not a feature you add later, it is a property the whole build has or does not.
How settled the thinking is. The strongest signal of all. A team that can describe exactly what should happen in the awkward cases has done the hard thinking already, and building it is largely transcription. A team that says "we would decide that when we get there" has a discovery project wearing a build project's clothes. Neither is wrong — but they are different kinds of work and pretending otherwise is how projects go sideways.
Why AI changed the ratio, not the rules
The parts of a build that AI genuinely accelerates are the mechanical parts: scaffolding, wiring, tests, the second and third variation of something that already exists. That is a real change and it is why we can offer a working prototype before anyone signs anything.
What it does not compress is deciding what the software should do. Every one of the four forces above is a judgement about your business, and no amount of generation capacity settles a question nobody has asked yet. If anything, the ratio shifted the wrong way for unclear projects: when construction gets faster, the thinking becomes a larger share of the whole, and vagueness gets more expensive relative to everything else.
This is the practical reason we start with a prototype rather than a specification. A document describing a state machine is an opinion about a state machine. A prototype you can click reveals within a session that there are two states nobody mentioned and one transition that is not actually allowed. We wrote about that in why we build a free prototype first, and it applies most strongly to exactly the projects that look simplest on paper.
What to work out before you talk to anyone
You can do most of this yourself, and it makes every subsequent conversation better regardless of who builds the thing.
Write down your central entity and its states. Whatever your software is mostly about — an order, a case, a lead, a shipment — list what it can be and how it moves. Mark the transitions that are restricted, and the ones that trigger something elsewhere.
List the systems that already hold a version of this data, and for each one write down whether you would be reading, writing, or both, and what identifies a record on each side. Where two systems key on different things, mark it. That mark is usually the largest single piece of work in the project.
Name your standard. Internal tool, customer-facing, or something that produces numbers people rely on. Be honest — a tool that starts internal and later faces customers has to be rebuilt to a standard it was not designed for.
Finally, write down the three cases you are least sure about. Those are the ones worth prototyping first, because they are where the surprises live, and everything else is comparatively predictable once they are settled. Our web and AI work almost always starts there rather than at the home page.
