Nobody sets out to make a £40,000 mistake.
The decision that costs £40,000 looks, at the time it's made, like a reasonable call under time pressure. An engineer with solid instincts and not quite enough context picks the familiar option. The system goes to production. It works. Life moves on.
Six months later, something changes. A compliance requirement surfaces. Traffic grows past a threshold nobody modelled. An enterprise prospect asks a question about your database architecture that reveals a problem you didn't know you had.
And then the bill arrives, not on an invoice, but in engineering weeks, in delayed deals, in the quiet compounding of a problem that was preventable.
Three decisions that look small and aren't
The first is database choice at the wrong stage.
A team chooses a managed PostgreSQL instance because it's what they know. It works well. The application ships. Eighteen months later, the transaction volume has grown to a point where connection pooling is becoming a problem, Lambda functions spawning hundreds of simultaneous connections against a database with a hard ceiling.
The fix is not technically complex. But it requires introducing RDS Proxy, revisiting connection management across multiple services, and scheduling the migration carefully enough not to cause downtime. Four to six weeks of senior engineering time. On a team where senior engineers cost £700–900/day fully loaded, the arithmetic is straightforward.
The original decision wasn't wrong. It was made without visibility of what it would mean at scale. That visibility was available it just wasn't in the room.
The second is observability as an afterthought.
A team ships without centralised structured logging because it's not needed yet and there's a product milestone to hit. They use CloudWatch Logs with no consistent format, no correlation IDs, no service boundaries in the log output.
It's fine for months. Then a production incident happens. The payment service failed, something upstream triggered it, and tracing the failure requires manually correlating log entries across four services by timestamp.
The incident takes four hours to resolve. A post-mortem identifies that the logging architecture makes distributed tracing effectively impossible. The fix, standardising log structure, introducing correlation IDs, rebuilding the observability stack takes three to four weeks.
Three weeks of engineering time to fix something that would have taken three days to build correctly the first time. The cost isn't the three days. It's the three weeks of rework, the four-hour incident, and the two or three incidents that will happen again before the fix is complete.
The third is multi-tenancy designed incorrectly for a B2B product.
A SaaS team builds a product where all customers share a database. It's the simplest approach and it works fine for the first dozen customers. Then an enterprise prospect asks whether their data is logically isolated from other tenants, and the answer is "it's in separate rows with a customer ID column."
That answer ends some deals. For the deals it doesn't end, it creates a compliance gap that resurfaces at every security review. The re-architecture required row-level security, schema-per-tenant, or account-per-tenant depending on the requirements is significant. It touches every query in the application.
The original decision made sense for the stage the company was at when it was made. It didn't account for what enterprise sales would require twelve months later. That's not a failure of engineering it's a failure of having someone in the room who had seen this pattern play out before.
What these decisions have in common
None of them were made carelessly. All of them were made by engineers who were trying to ship something and working with the information they had.
The missing ingredient in each case isn't better engineers. It's someone with enough context across the full picture, compliance requirements, scaling patterns, the enterprise sales process, the AWS service trade-offs at different load profiles to flag the second-order consequence at the moment the decision is being made.
That's a specific kind of expertise. It's not deep specialisation in any one area it's the cross-cutting architectural judgment that comes from having seen enough systems at enough stages to know which decisions are genuinely reversible and which ones will cost you six months of engineering time to undo.
Most engineering teams at the seed-to-Series B stage don't have that person. They have talented specialists who are very good at their domains and a CTO who is too stretched to be in every decision. The expensive mistakes fall into that gap.
The compounding that nobody models
The individual cost of each of these decisions is significant. The compounding cost is larger.
A team making three or four decisions like this per year, each costing four to eight weeks of senior engineering time to undo, is effectively running at 80% of its potential output. Twenty percent of engineering capacity is absorbed by rework that was preventable.
On a team of ten engineers at £120,000 average fully-loaded cost, that's roughly £240,000 per year in engineering output that isn't going into product, features, or customer value.
That number doesn't appear on any dashboard. It shows up as a roadmap that's always slightly behind, as technical debt that never quite gets paid down, as engineers who are quietly frustrated that so much of their time goes to fixing things that shouldn't have needed fixing.
It's the most expensive cost in most scaling engineering organisations. And it's one of the most preventable.
Architectural decisions made without full visibility of their consequences are the most common source of engineering waste in scaling teams. SyncYourCloud membership gives your team async access to architectural review before decisions get built into production a structured recommendation with the reasoning your team can learn from. From £2,950/month. See the membership tiers →
