The missing 80%

An AI tool will give you a convincing version of your idea in an afternoon. It will have your screens, your language, and enough behaviour that people nod along in a demo. That is genuinely useful, and it is not a product.

The distance between the two is not a matter of polish. It is a list of specific, unglamorous things that a buyer's security review will ask about, and that are far cheaper to build early than to retrofit. Here is the list, so you can price it before you commit to it rather than discover it halfway through.

Keeping one customer's data away from another's

If two organisations use your software, the single most expensive mistake available to you is letting one see the other's records. Every serious buyer asks how you prevent it, and "we filter by customer ID in the query" is not an answer that survives follow-up questions.

What survives is isolation enforced somewhere the application cannot forget: separate schemas, row-level policies in the database, or separate stores entirely, chosen deliberately rather than by accident. Then automated tests that attempt the cross-tenant read on every build and fail loudly when it succeeds. The tests matter more than the mechanism, because the mechanism is only true until someone writes a query that bypasses it.

Retrofitting this into a prototype means touching every query you have written. Deciding it on day one costs a conversation.

Knowing who did what, and when

Audit trails are usually the first thing cut and the first thing asked for. An auditor, an insurer or an enterprise customer will want to know who changed a record, what it said before, and when. So will you, the first time a client disputes something.

The version that works is append-only: entries are written and never updated or deleted, including by administrators. The version that does not work is a log table that the application also has permission to tidy up.

Identity and access

Authentication is the easy half and is largely a solved problem you should buy rather than build. Authorisation is the hard half and cannot be bought, because it encodes decisions only you can make: who may see which records, who may approve, who may export, and what happens when someone leaves.

Two things make this expensive later. The first is roles that were invented ad hoc as features were added, so nobody can state the rules in one place. The second is single sign-on, which most enterprise buyers require and which is awkward to bolt on to a system that assumed passwords.

Secrets, keys and where the data lives

Encryption in transit is a checkbox. The questions after it are the real ones: where are the keys, who can read them, what happens when one is rotated, and which country is the data sitting in while it is processed. If your answer to any of those is a value pasted into an environment variable a year ago by someone who has since left, that is worth fixing before a customer asks.

Data residency is worth deciding explicitly rather than inheriting from whatever region you first deployed to.

Files

Almost every real product ends up accepting uploads, and uploads are where a surprising amount of risk concentrates. Files need size and type limits that are enforced by the server rather than the browser, storage that is not publicly readable by URL, scanning if the content comes from outside your organisation, and a deletion path that actually removes the object rather than hiding the row that pointed at it.

Deployment, backups, and the restore you have tested

Backups nobody has restored are not backups, they are a belief. The work here is small and boring: automated backups, an encrypted copy somewhere separate from the primary, and a restore rehearsed at least once so you know how long it takes and what breaks on the way.

Deployment belongs in the same paragraph. If shipping a fix requires a person to follow steps from memory, then the fix will be delayed exactly when it matters most.

Tests that catch regressions

Not test coverage as a number. Tests around the things that would be catastrophic or embarrassing: the isolation boundary, the permission checks, the money, and the handful of workflows your customers actually depend on. Enough that you can change something in the second year without a feeling of dread.

The runbooks

The last item is the one that determines whether you own the product or the product owns your supplier. Written operational documentation covers what to do when a job fails, how to add a customer, how to rotate a credential, what to check when someone reports it is slow, and who to ring. It is what lets someone who is not you keep it alive.

Why the order matters

None of this is exotic. Any competent team can build each item. The reason it accounts for most of the cost is that several of these decisions are structural: tenant isolation, the audit model and the permission model shape everything written after them, and changing them later means revisiting code that already works.

That is the actual argument for deciding them at the start. Not that a prototype is bad, but that a prototype is a specification, and the useful next step is to price the rest of the list before you build on top of it.

If you want that priced for your own product, tell us what you are building and we will give you a number.