The Same Technology Choice Is Cheap at a Startup and Expensive at a Scale-up

According to Dan McKinley, every company has roughly three innovation tokens. He laid this out in 2015 in his essay Choose Boring Technology. A team that picks a new database or language spends one of its tokens, and once the tokens are gone, every new tool adds another layer of operational load.

The essay is mostly read as advice for startups. I think it earns its keep somewhere else. It shows that the same decision arrives at a different price at a different scale. A technology choice is a question about risk, and the shape of that risk shifts with the stage of the company.

When the Product Is Uncertain, Speed Wins. When It Settles, Maintenance Does

In the first months of a company, nobody knows who the product will be useful for. At this stage, picking the wrong framework means a few hundred lines of code in the bin. The codebase is small, the users are few, and tearing it out costs a few weeks. The expensive thing is learning about the market late. A team that ships a week earlier with a boring tool it already knows has learned a week’s worth more than the others.

Once the product settles and the teams multiply, the uncertainty moves out of the market and into the organization. In a company with forty engineers, six product teams and two years of shared code, a new choice usually means a library, a monitoring setup and a hiring plan. One team’s choice gets written into the calendars of the other five. Reversing it is no longer a weekend job. It becomes a migration period in which the old and new systems live side by side. The person who made the decision may be the same, but the number of people who pay for it multiplies.

In Amazon’s 2015 shareholder letter, Jeff Bezos describes this difference with two kinds of doors: decisions that are easy to reverse and one-way doors. The same technology decision usually falls into the first group at a startup and into the second at a scale-up. Before you look at the decision, ask which door it sits behind.

Five Risks Carry Weight at Once, and Their Weights Shift with the Stage

You can’t measure whether a choice is safe with a single question. Splitting the risk into five parts makes visible what the context changes.

Reversal cost comes first. At a startup you can rip out a wrong choice in three months, so this risk stays light. At a scale-up, the same choice has dozens of services and years of accumulated data sitting on top of it. Migration, the dual-maintenance period and the cost of relearning each go on the bill separately.

Team and hiring risk runs the other way. If three people know the same stack, the talent pool doesn’t matter for a while, because you’re hiring so few people anyway. In a company that has to hire five engineers a month, if few people know that technology, hiring takes longer and onboarding takes longer too.

Ecosystem risk means leaning on a single company’s roadmap or a single open source maintainer. A startup usually takes this on knowingly, since a ready-made platform saves it weeks. At a scale-up, if that platform changes its pricing or withdraws support, the budget takes a direct hit. I covered this in a separate piece on how the software you depend on has an owner.

Performance risk depends on what the product does. At a startup it is mostly invisible, because nobody is putting load on the system yet. At a scale-up, a small regression in load time repeats across a huge number of sessions every day and shows up in revenue.

Organizational risk is the last one to be noticed. In a single team, a stack preference is a matter of taste. If six teams pick six different stacks, you can’t write a shared library, monitoring fragments, and an engineer moving from one team to another has to learn everything from scratch. This cost doesn’t show up in the code. It builds up in teams being unable to help each other.

You can take these five headings into a decision meeting with these questions:

• Which risk weighs most at this stage?
• Which assumptions does the choice rest on? For example, “the team stays at five people” or “one cloud provider is enough”.
• If which assumption changes, do we look at the choice again?
• If we have to go back, what is the total cost?

Segment Went to Microservices and Came Back

One of the best-known “we moved from X to Y” stories is Segment’s. In 2018, the company published a post on its engineering blog titled Goodbye Microservices. According to the post, the team had split the destinations that customer data is sent to into separate services one by one, and later folded those services back into a single one. The reason they published was that a change to a shared library had to be rolled out to dozens of services separately, which slowed the team down.

It would be wrong to read this as “microservices are bad.” Segment made the first split for a reason too. The product grew, the team grew, the context changed, and the risk reading was updated. We can’t see the internal meetings, the budget pressure or which team objected to what. From the outside, we only know the reason they published.

If hundreds of engineers write a company’s code, it has a shared platform, and it can staff a separate team for the migration, the same choice lands on an entirely different risk structure at that scale. A five-person team has none of those things. If you copy a decision without knowing its reasoning, you carry a verdict that was made for someone else’s scale over to your own.

The Written Decision Also Carries the Condition for Giving It Up

If the answers to those questions stay in the meeting room, they will be forgotten within a few months. A decision record doesn’t need a big process. The format in Michael Nygard’s 2011 post Documenting Architecture Decisions fits on one page and has five parts: title, status, context, decision and consequences. I add one more question, because it’s the one most records leave out. Under what condition do we revisit this choice?

The most useful part is the assumptions. “The team is six people and all of them know this language” is an assumption. When the team grows to forty, that sentence quietly stops being true, and since nobody wrote anything down, nobody notices.

The exit criterion has to be measurable. “If performance falls short” is not a criterion, because nobody can say when it has fallen short. “If load time stays above target for two quarters in a row” or “if the open position in this area passes four months” is a criterion. I made these numbers up, and you should derive yours from the limits of your own product. The number has to be written at decision time. A threshold set afterwards only serves to defend a decision that has already been made.

If you decide to change the choice, the bill has three items. Migration covers moving the existing code and rebuilding the test and deployment pipeline. The dual-maintenance period is the time the old and new systems live together, and it usually runs longer than planned. Learning is the time it takes for the team to get back to its old speed on the new tool. Deciding without adding these up means deciding on half a bill. The cost of staying also has to be written down, or the old choice will look cheap by default.

Every record needs an owner. A team or an architecture board isn’t enough, you need one person with a name. On the review date in the calendar, the owner checks the criteria and writes “valid” or “reopened” on the record. You can put that date in the calendar every six months, and if a criterion triggers, you meet without waiting for the date. When a record is reopened, the risk reading has been updated, and the trace of that stays in the document.

A choice with no exit condition either never changes or changes because of a news headline. The second is more dangerous, because at that point you aren’t making the decision. Another company’s conference talk is.

The next time you read a “we moved from X to Y” post, open your own decision record first and look at which of its assumptions that post touches. If you don’t have a record, open a one-page one today for the single most critical choice you have.