Fast doesn't mean flimsy: on security and architecture

The most common worry we hear about 30-day delivery is the obvious one: if you're going this fast, what are you cutting? The implied answer is always the same two things — security and architecture.

It's a fair question, because the cheap version of fast delivery really does cut both. You've probably seen it. The demo is slick. The UI is lovely. Then you look under the hood and find one admin password shared in a Slack channel, a database with no backups, and a server that falls over the first time someone real uses it. That isn't a production app. It's a prototype with good branding.

The honest version of fast delivery cuts neither. It cuts scope.

Those two things sound similar but they're completely different. Cutting scope means deciding, together, which features *don't* ship in the first version — the ones that aren't load-bearing for the problem you're solving. Cutting corners means shipping the features but skimping on the foundations they rest on. The first is a design decision. The second is a time bomb.

The foundations that have to hold, even on a tight timeline, are surprisingly short. Authentication has to be real — no shared credentials, no "we'll add SSO later" if your users need it today. Secrets have to live somewhere that isn't a git repo. The data model has to be something you can add to without migrations turning into surgery. Backups have to exist, and they have to be tested. Monitoring has to tell you when things break before your users do. Access controls have to match the way your organisation actually works.

None of that is glamorous, and none of it takes long if you know what you're doing. The reason it gets skipped isn't that it's expensive — it's that it isn't demoable. It doesn't show up in a screenshot. The pressure to cut it is always there, and the discipline not to cut it is what separates a production system from a demo that happens to be live.

On a 30-day build, those decisions have to be made on Day 1, not Day 29. The stack is chosen with "what are we going to regret in a year" as the main question. Auth is wired up before the first feature is even sketched. Deployment and observability are set up before there's anything to observe. It's boring work, and it's the reason the end of the month doesn't feel like a cliff.

Fast delivery and serious engineering aren't opposites. The problem with most fast projects isn't that they were fast — it's that nobody spent the first few hours on the things that were actually going to matter.