Building an architecture that doesn't have to be rebuilt at every stage

Most organisations don't build one information system: they build three or four in a row, discarding the previous one each time. Once at incorporation, with whatever free tools are at hand. Again at the first hire, because nothing was shareable. A third time at ten people, because nobody knows where the truth lives any more. Each rebuild costs more than the last, and each was avoidable.

What triggers the rebuild

Almost never technology. The absence of three things:

• A list of capabilities — what the organisation must be able to do (sell, deliver, invoice, hire, evidence compliance) independently of the tools doing it today. Without that list you buy tools, then find that an essential capability is carried by none of them, or by three at once.
• One authoritative place per data item. The question is not "which software do we use" but "where does the customer record live, and who may change it". Data existing in two places without an arbitration rule will diverge, and divergence is paid for in rework.
• Traced decisions. Three to five choices commit an organisation for two years: where data lives, what is outsourced, what you refuse to automate, what must stay reversible. Unwritten, they are replayed at every arrival and contradicted unnoticed.

Capabilities first, tools second

A young company's capability map fits on one page: eight to twelve capabilities, each with the level expected in twelve months and the tool carrying it today — including "a spreadsheet" or "the founder's head", which are valid answers at this stage as long as they are deliberate. That page is enough to see what is missing, what is duplicated, and what deserves no investment this year.

The symmetric mistake is over-architecting. A three-person organisation needs neither an urbanisation repository nor an architecture board. It needs one capability page, three written decisions, and a build order.

The three decisions that prevent rework

1. Who owns the digital assets. Domain, accounts, data: in the organisation's name, never a provider's or an individual's. The least technical and most structural decision: it determines whether changing supplier is a formality or a crisis.
2. What must stay reversible. Every choice has an exit cost. Writing it down when you choose — not when you leave — is what separates a deliberate dependency from an endured one.
3. What you will not do this year. A roadmap without exclusions is not a roadmap, it is a wish list. Exclusions are what protect execution capacity.

The ten-person threshold

The moment everything gets rebuilt is nearly always the same: the organisation outgrows the size where one person knows the whole. Symptoms precede the break by months — information looked up twice, a decision re-taken because nobody remembers the rationale, a customer handled differently depending on who answers. Those are architecture signals, not growth signals.

The order that holds

Decide what to build, build it, then allocate execution. Concretely: capability map and decisions first; then the technical foundation — domain, email, access, backup, management tooling; then the split between founder, automation and agents; and, if the business touches the physical world, field data, only once you know which decision it must inform. For a small structure, the minimal version of this loop is described in TEAF Light: one process, one loop, one measurable objective.

That sequence is exactly the one followed by the 5 Founders programme: five companies being created, twelve weeks, free of charge for the selected company. Applications are open until 11 December 2026.