Every decision in this post is one a competent engineer would make, for good reasons, on an ordinary afternoon. None of them is a mistake in any sense that would survive a code review.
That's what makes them worth writing about. The engineering decisions that hurt a business are almost never the incompetent ones — those get caught. They're the reasonable ones whose cost arrives eighteen months later, in a different department, attributed to something else entirely.
The structure they share
Two properties, and both have to be present for the pattern to hold.
First, a long delay between the choice and the consequence. Long enough that the people involved have moved teams, and long enough that nobody would think to connect the two even if they remembered.
Second, an attribution failure. The damage surfaces as a lost deal, a headcount request, or a margin that won't expand — all of which are owned by someone who has no visibility into a two-year-old design review. Cook's seventh observation applies here as cleanly as it does to outages: the harm has several contributors, none sufficient alone, so picking one to blame reflects a social need rather than an understanding of what happened. If engineering decisions that quietly hurt growth needs to survive contact with a marketing team, XenGrowth has the operational side.
The cost is real, it is large, and there is no mechanism anywhere in a normal company that would route it back to the decision that caused it.
The specific ones
Decision | Why it's reasonable | What it closes | Delay |
|---|---|---|---|
Single currency, hard-coded | You have one market and no plans | International expansion, until funded as a project | 1–3 years |
Two roles: admin and user | You have twelve customers who all trust each other | Every enterprise deal requiring granular access | 12–24 months |
Human-touch onboarding | Talking to customers is how you learn | Growth beyond hiring rate; CAC payback stops improving | 9–18 months |
Money as floating point | It works and nothing complains | Trust, via reconciliation discrepancies | Whenever someone reconciles |
Single-tenant isolation | It answers the security questionnaire | Gross margin ceiling; the low end of the market | 18 months–3 years |
Timestamps without timezones | Everyone is in one office | Correctness for every customer elsewhere | First international customer |
No audit log | Nobody asked for one | Regulated industries entirely | At the first compliance review |
Two rows deserve more than a table cell, because they're the expensive ones and the ones most often decided by whoever happened to be free that week.
Money as floating point
Worth including because it is the one that damages something no dashboard measures. Binary floating point cannot represent most decimal fractions exactly, so sums of currency amounts drift by fractions of a cent, and the drift accumulates differently depending on the order operations happen in. Two code paths that should agree produce totals that differ in the last place.
Nothing crashes. No alert fires. What happens is that a customer's finance team reconciles your invoice against your usage report, finds they disagree, and asks. The engineering cost of the fix is moderate. The commercial cost is that a vendor whose numbers do not add up has a credibility problem, and credibility is not recoverable by improving uptime. This is the clearest case in the whole list of an engineering defect converting straight into churn without ever appearing as an incident.
Permissions
Shipping with admin and user is right at twelve customers who all know each other. The cost is that adding granularity later means re-deriving authorisation for every endpoint written since — and by then permission checks are scattered through the whole codebase, some of them implicit, several of them load-bearing in ways nobody documented. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
Worse, it isn't purely an engineering problem by then. Changing the model risks altering behaviour for existing customers, which turns a refactor into a migration with a communications plan attached. And enterprise buyers don't negotiate on granular access, because their own compliance obligations don't bend — so this arrives as deals you cannot close rather than as feedback you can act on.
Human-touch onboarding
The subtlest of the lot, because it starts as a genuinely correct decision. Early on, personally onboarding every customer is the highest-value research available — you learn what confuses people, what they actually wanted, which feature they ignore. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
Nobody notices the moment it stops being research and becomes a bottleneck. It doesn't announce itself; growth just stops accelerating, and the diagnosis is usually 'we need more people in customer success'. Commercially it shows up as a CAC payback period that won't improve no matter what marketing does — Benchmarkit's 2026 median is 16 months, top quartile at 6, and self-serve activation is the main lever separating those two groups.
Why 'we'll fix it later' is usually false
Every decision in the table above is made with an implicit promise attached: this is fine for now, and we will revisit it when it matters. The promise is sincere and it is almost never kept, for a reason that has nothing to do with discipline.
The moment the constraint starts to bind is the worst possible moment to address it. A permission model becomes urgent during a live enterprise deal, with a deadline set by someone else's procurement calendar. Tenancy becomes urgent when margin comes under scrutiny, which is usually during a fundraise or a cost-cutting exercise — precisely when nobody wants to fund a year-long migration. Currency handling becomes urgent when a deal in another market is already signed. In every case the work is now blocking revenue, so it is done in a hurry, badly, by people under pressure, and it produces its own second generation of shortcuts.
There is a second reason, which is that the cost of the fix grows with exactly the thing that makes the fix necessary. You need granular permissions because you now have many customers and many endpoints; the number of customers and endpoints is what makes the retrofit expensive. Growth is simultaneously the trigger and the multiplier, so the work is never cheaper than it is today and never more clearly worth doing than it is tomorrow. That combination is the reason these items sit on backlogs for years.
Which is not an argument for building everything up front. Most of these constraints never bind, and a company that pre-solves all of them ships nothing. It is an argument for knowing which one you are carrying, telling somebody commercial that you are carrying it, and accepting that 'later' means 'under duress' rather than 'when convenient'.
What actually prevents this
Not more diligence. All of these were made diligently. What's missing is one question, asked at the moment the decision is cheap.
"What does this make impossible or expensive later, and who would have to pay for it?"
That's it. It takes thirty seconds, most of the time the answer is nothing, and the occasions when the answer is "the enterprise segment" or "our margin ceiling" are exactly the ones worth a longer conversation. The point isn't to make the cautious choice every time — often the fast decision is correct and the constraint never binds. The point is that the constraint should be a known, accepted cost rather than a discovery. XenGrowth on AI search, GEO and discovery covers the AI search, GEO and discovery side of this.
Write the constraint down when you accept it. A one-line decision record saying 'single currency, revisit before any non-domestic customer' converts a future surprise into a scheduled decision, and costs nothing
Name the trigger, not the date. 'Before the first enterprise deal', 'before the first customer outside this timezone', 'above 500 tenants'. Dates get missed; triggers are noticed by whoever hits them
Tell someone commercial. The person selling should know that granular permissions do not exist yet, because otherwise they will promise them, and the gap between those two facts is where the worst quarters come from
Sort by reversal cost, not by how likely the constraint is to bind. Permissions and tenancy are the two that cost a year to undo, which is why they deserve more thought than their probability alone suggests
Revisit the list quarterly. Most items will still be fine. The value is entirely in the one that has quietly become urgent while nobody was looking at it
Symptom the business reports | Decision it probably traces to |
|---|---|
"We keep losing enterprise deals late in the cycle" | Permission model, audit logging, or single sign-on |
"Our CAC payback won't come down" | A human step in activation |
"Gross margin isn't improving as we grow" | Per-tenant floor costs, or per-tenant scheduled work |
"Finance keeps finding discrepancies" | Floating-point money, or timezone handling |
"We can't sell into that region" | Hard-coded currency, tax, or address assumptions |
"Support headcount grows with customers" | Product friction, which is an engineering cost recorded elsewhere |
That table is the useful artifact here. If you hear something in the left column, there is a decision in the right column somewhere behind it — and being the engineer who makes that connection out loud is worth more than most of what you will ship this quarter.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's revenue operations work writes for the teams who have to run engineering decisions that quietly hurt growth day to day.
And if you are the one who inherited these rather than the one who made them, the same table is your argument for funding the repair — stated as a door that is currently closed, with the revenue behind it, rather than as a complaint about the code.
Five scenarios, each a decision a competent engineer would make on a Tuesday. The question is which commercial door each one closes, and how long before anyone notices.
