How we plan architecture for 10× growth

Most platforms are built for the users they have. That is reasonable on day one and expensive on day four hundred, when the company has doubled, opened a second country and added a language nobody planned for.

Planning for growth does not mean building for it all at once. It means making the few decisions that are hard to change later, early, and leaving everything else simple. Here is how we do it.

Start from the target, not today

Before choosing a stack, we write down the numbers the business is aiming for: users, regions, transactions, languages. Architecture decisions are then checked against that target, not against this quarter’s traffic.

Those numbers do not need to be precise. “Around ten companies in the group, three countries, French, English and Arabic, a few thousand employees” is enough to rule out some designs and confirm others. The questions we ask are simple:

• How many organisations will share the platform, and must their data be strictly separated?
• Which languages and writing directions will the interface need?
• Which countries’ rules (payroll, tax, data location) will apply?
• What happens to the business if the platform is down for an hour?

Scale is designed, not discovered.

Each answer turns into a constraint. A group with several companies needs multi-tenancy from the start, because adding it later means touching every table and every query. A product that will be used in Arabic needs right-to-left layouts in its foundations, because retrofitting them means redoing every screen.

Design the seams first

We identify where the system will need to split later, such as billing, search or notifications, and draw clean boundaries now, even if everything ships as one service at first.

A seam is an interface that the rest of the code depends on, instead of depending on the implementation behind it:

// a seam today, a service tomorrow
export interface Billing {
  charge(order: Order): Promise<Receipt>
}

On day one, the implementation is a few functions in the same codebase. When billing grows complicated enough to deserve its own team, its own database or its own release cycle, it can move behind the same interface without the rest of the platform noticing.

This is the difference between preparing for scale and overbuilding. We do not start with a dozen microservices, a message bus and three databases. We start with one well-structured application whose boundaries are already where the future services will be.

The same idea applies to integrations. Every external system, from an accounting package to an identity provider, sits behind an adapter. Replacing one supplier with another becomes a contained change rather than a migration.

Measure before you scale

Every platform we launch ships with monitoring from day one, so the decision to scale is based on data rather than guesswork.

That means three things are in place before the first real user signs in:

• Metrics on response times, error rates and the business actions that matter (requests approved, invoices issued).
• Logs that can be searched by organisation, user and request, so problems can be traced to their cause.
• Alerts that wake someone up when a threshold is crossed, before customers notice.

With that in place, scaling becomes a series of small, informed decisions: this query needs an index, that report should run in the background, this tenant needs its own database. Without it, scaling is a guess, and guesses tend to be expensive.

What this looks like in practice

For a typical business platform, the result is unremarkable on purpose: one application, multi-tenant from the first table, with single sign-on, a server-side audit trail, clear internal boundaries, automated tests and monitoring. Nothing exotic, and nothing that needs to be thrown away when the company grows.

The ambition is in the plan, not in the complexity. If you want us to look at your target and tell you which decisions matter now, book a call.