Most engineering teams build software the same way. The first commit is a hello-world handler that reads from a database and returns a JSON response. The second commit adds a second endpoint. By the time security comes up — usually somewhere between the seed round and the first enterprise prospect — the system has fifty endpoints, three databases, an authentication library nobody owns, and a deployment pipeline that nobody fully understands.
The bolt-on then takes six months. We have done this work. The arithmetic is honest and unflattering.
What the bolt-on actually costs
Adding identity, secrets management, audit trails, and explicit trust boundaries to a working system is not a refactor. It is an archaeology project. Every endpoint has to be classified — what data does it touch, who can call it, what does an attacker get if it breaks. Every secret has to be tracked from the codebase backwards through every environment it ever leaked into. Every database query has to be re-evaluated against an access model that did not exist when it was written.
A team of three engineers can build a new system to a high security bar in three to four months. The same team retrofitting the same bar onto a system already in production takes nine to twelve months and is wrong in subtle ways for another year. The ratio is roughly ten to one, and the ten side gets paid in customer trust, not just calendar time.
What "first commit" discipline means
This is not a call for security theatre. It is four specific decisions that have to be made on day one and never undone:
Identity is a header, not a query. Every request entering the system carries an identity proven at the edge. No internal code constructs identity by reading the database. The trust boundary is at the front door.
Secrets live in one place. A secrets store the application reaches at startup, not a `.env` file that gets committed by accident in month four. The discipline is decided once, by one person, in the first week.
Audit is a write-once log. Every action that touches sensitive data writes an immutable audit entry. Adding this later means re-instrumenting every code path; adding it on day one means wrapping a single handler.
Trust boundaries are explicit. Every service boundary, every database connection, every external API call is named, threat-modelled in one paragraph, and either trusted or sanitised. The paragraph is committed alongside the code.
Four decisions. None of them slow the team meaningfully. All of them make the difference between a system that holds up to enterprise diligence and one that does not.
What this is not
It is not "shift left." It is not a checklist or a tool. It is not a pre-launch audit.
It is the recognition that the architecture decided in the first commit is the architecture you are still arguing with three years later. Every retrofit team we have advised has wished, in retrospect, that the system had started where the work eventually had to end up.
Build it correctly the first time. The work is the same. The order is what matters.