“Why on earth did we build it this way?”
Every growing business eventually asks this. A new hire, an investor’s technical adviser or a contractor looks at the systems and wants to know why you chose that database, that hosting provider, that particular way of handling customer data.
Often nobody can remember. The person who made the call has moved on, or the reasoning was lost in a meeting two years ago. So the team faces an uncomfortable choice: leave it alone without understanding it, or change it and risk breaking something that was done that way for a very good reason.
Many of the topics I write about here, from spreadsheets and integrations to security, legacy systems, AI, data protection and resilience, trace back to the same root. The problems began with decisions, usually sensible ones, that were made quickly and never written down.
Not just technical choices
It’s tempting to leave technology decisions to whoever is most technical. But the choices that shape the systems shape the business just as much:
- Cost. Choosing a platform commits you to its licensing, hosting and support costs for years.
- Speed. Some designs make it easy to launch new products or channels; others make every change slow and expensive.
- Risk. Decisions about security, data and resilience determine how exposed you are when something goes wrong.
- Flexibility. Deep dependence on one vendor can limit your options and your negotiating power.
- Value. Investors and acquirers examine these decisions closely, and well-reasoned, documented choices make a business more attractive.
That’s why leadership should be involved in the decisions that matter. Not in the technical detail, but in the trade-offs being made on the business’s behalf.
What gets lost when nothing is written down
Most businesses record what their systems do, if they record anything at all. Far fewer record why.
Yet the why is the part that matters most. It captures the constraints at the time, the options considered, the trade-offs accepted and the conditions under which you’d decide differently. Without it:
- The same debates happen again and again, because nobody remembers how they were settled.
- Good decisions get undone by people who don’t know the reason behind them.
- Bad decisions are never revisited, because nobody realises the original assumptions no longer hold.
- Knowledge walks out of the door with the people who leave, which is key-person risk by another name.
- Due diligence becomes painful, as leaders try to reconstruct years of reasoning from memory.
The fix is surprisingly simple.
Architecture Decision Records, explained
Architects use a lightweight tool called an Architecture Decision Record, or ADR. It’s simply a short note, often less than a page, written each time a significant decision is made. A simple template covers everything that matters:
| Section | What it captures | Example |
|---|---|---|
| Title and date | A short name for the decision | Use a SaaS CRM instead of building our own (March 2026) |
| Context | The situation and constraints at the time | Sales team of four, no in-house developers, need to launch in six weeks |
| Options considered | The realistic alternatives | Build bespoke, extend the order system, adopt a SaaS CRM |
| Decision | What was chosen | Adopt a SaaS CRM on a monthly plan |
| Consequences | The trade-offs accepted | Faster launch and lower cost; less customisation; some vendor dependency |
| Review trigger | When to revisit it | If the team exceeds 20 users or needs deep integration with ordering |
ADRs are written once and rarely edited. When a decision changes, a new record supersedes the old one, so you build up a history of how the systems evolved and why. Keep them somewhere everyone can find: a shared folder, a wiki, or alongside the code.
A lightweight way to make better decisions
Writing decisions down also makes them better, because it forces the right questions. A simple routine works for most teams:
- Recognise the decisions that matter. Anything expensive to reverse, affecting several teams, involving customer data or committing you to a supplier for more than a year deserves a record.
- Frame the problem in business terms. Start with the outcome you need and the constraints you face, not the technology you’d like to use.
- Consider at least two real options. If only one option was ever on the table, the decision hasn’t really been made.
- Make the trade-offs explicit. Every choice gives something up. Naming it means the business accepts it knowingly.
- Agree it with the right people. Technical leads own the detail; leadership owns the trade-offs that affect cost, risk and strategy.
- Set a review trigger. Decide in advance what would make you revisit the choice, so it doesn’t quietly outlive its usefulness.
It takes perhaps half an hour per decision. Compared with the cost of unpicking a poor one, it’s one of the best investments a growing business can make.
Good architecture starts with good decisions
If there’s one thread running through everything I write about, it’s this: most technology problems in growing businesses aren’t caused by bad technology. They’re caused by decisions made in a hurry, without the full picture, and never revisited.
