Application development: the four decisions that set the cost
Estimates for application development are usually built from a feature list, which is why they are usually wrong. Features are the visible part, and the visible part is not where the cost lives.
Four decisions account for most of the variance between an application that costs what everyone expected and one that costs three times that. All four are made in the first fortnight, usually informally, sometimes without anyone noticing a decision was made. Three of them are expensive to reverse.
Working through them deliberately is the first thing custom software development should do, before an estimate means anything.
Decision one: who is allowed to see what
Access control looks like a feature. It is a property of every query in the system.
If the answer is “everyone who logs in sees everything,” the application is dramatically simpler and you should write that down as a deliberate choice. If the answer involves teams, hierarchies, ownership, or the sentence “except managers can also see,” then the permission model has to be settled before the data model, because it changes the data model.
Retrofitting this is the most reliably expensive change I know of. Every read path has to learn a new question, and every one you miss is a leak.
Decision two: what happens when two people act at once
Most applications are read-mostly and the answer is “nothing interesting.” Some are not, and for those this decision dominates everything else.
If two users can act on the same record — approving, assigning, booking, transferring — you need to decide what correct means before you build. Last write wins is a legitimate answer if you choose it knowingly. It is a bug if you inherit it by default.
Anything involving money or inventory almost always needs a stronger answer, and that answer shapes the database, the API, and the parts of the interface that have to cope with being told no.
Decision three: where the truth lives
Applications rarely hold all their own data. There is a payments provider, an identity provider, a CRM, a warehouse. For every piece of data that exists in more than one place, someone has to decide which copy is authoritative and what happens when they disagree.
Teams that skip this end up with reconciliation work that nobody owns, appearing as intermittent support tickets that are impossible to reproduce. The fix is not technical sophistication. It is a written statement, per entity, of where the truth lives and how divergence is detected.
Decision four: what a release costs
Not the deployment mechanism — the ceremony. If shipping a change requires a meeting, a manual test pass, and a maintenance window, then every subsequent decision will be biased toward batching changes, and batching changes is how you get releases scary enough to postpone.
This is the one decision of the four that is genuinely cheap to reverse later, and it is still worth making early because it changes the shape of everything else.
What this looks like when it is done properly
The fine-tuning pipeline case study is the clearest example I can point at publicly, though it is a pipeline rather than an application. It was subjected to an adversarial audit of my own work that surfaced 84 issues, including the reason the model was reciting rather than reasoning. The number is only meaningful because the audit was designed to find things rather than to confirm the build.
That is the standard I would want applied to these four decisions: not a review that agrees with you, but one built to disagree.
The estimate conversation
Once those four are settled, an estimate starts to mean something. Before they are settled, an estimate is a statement about the feature list, and the feature list was never the risk.
I would rather spend the first two weeks on this than produce a confident number in the first two days. The confident number is easier to sell and it is the reason so many projects arrive at the security review with no budget left.
The order matters more than the answers
If you take nothing else: settle these in the order given. Permissions constrain the data model, the data model constrains how concurrency can be handled, and both constrain where the truth is allowed to live. Answering them out of order produces answers that individually look fine and jointly do not hold, which is a failure that surfaces in month five rather than week two.
Related reading: product development covers whether you are building a product or a project, which changes the answer to decision four. Custom software covers whether you should be building at all — worth settling before any of these four, because it is the only question whose answer can be “no.” And the development process covers the sequence these fit into.
What I cannot tell you from here
Which of the four dominates for your application depends on facts I do not have: how many concurrent users, how much of your data lives elsewhere, whether money moves. For a read-mostly internal tool with one permission level, three of these four are near-free and the estimate really is close to the feature list. That case exists. It is just less common than the estimates suggest.