Scaling a 3-person team to a global organisation operating in 4 regulatory regions

The challenge: enterprise scrutiny before enterprise scale

Early-stage companies typically defer infrastructure quality in favour of delivery speed, accepting rework later. A company selling to security-conscious enterprises, and holding itself to the same standard, does not have that latitude.

When we started building the company's technology stack, the entire organisation was three people at pre-seed. There were no cloud accounts, no pipelines, no environments. The commercial reality, however, was already fixed: the customers would be large enterprises whose procurement teams inspect a vendor's infrastructure before signing anything, meaning the stack would be subject to direct examination by customers. Expansion to buyers across APAC, the US, and EU — each jurisdiction with its own data residency expectations — was an explicit part of the commercial plan from the outset.

This effort also came with three constraints that shaped every subsequent decision:

1. Lean platform team. Every operational burden we created would need to be based on a shared responsibility model where product engineers would partially operate what they built with guardrails in place.
2. Infrastructure work was delivered with a product delivery mindset. A small team operating in a highly volatile business environment doesn't have the luxury of handovers or proper specifications.
3. Trust is the primary capital we needed to build. Given the customers the organisation served, an incident would carry reputational cost far beyond its technical severity.

The standard playbooks were both unsuitable. "Move fast and rebuild later" fails under enterprise scrutiny. "Build it properly like a big company" fails with a three-person team. What was needed was a third approach: a small set of disciplines, chosen deliberately to withstand constantly changing contexts, while knowing which parts needed a "proper" implementation to avoid expensive retrofitting later.

The approach: five decisions that made expansion cheap

1. Everything as code, from the very first resource

Every piece of infrastructure was defined as code from the first deployed resource — no console-created resources and no undocumented manual steps. We leveraged Terraform and a central repository of infrastructure tooling scripts that all engineers had access to.

This is the single highest-leverage decision an early-stage company can make about infrastructure. It costs almost nothing at inception and becomes prohibitively expensive to retrofit. It paid off twice: expansion into a new region became largely a matter of re-applying tested definitions with new parameters, and compliance audits could evidence infrastructure state directly from version control history.

2. Design region-agnostic before a second region exists

The platform launched in one region, but no service was permitted to assume it would only ever operate in one. No hard-coded regional endpoints, configuration-driven regional parameters based on an agreed-upon convention, data stores designed so tenant data would be pinned to a jurisdiction and would never have to leave it.

The premise: region-agnostic design is a modest tax when paid upfront, while removing regional assumptions from a live system later amounts to a rewrite.

3. Choose boring technology, deliberately

Component selection favoured mature, widely operated technology over novel technology. Microsoft was chosen as the identity provider over more fancy tools like JumpCloud since compliance was in-built into all their services. AWS was chosen over GCP and Azure based on its prevalence in modern companies and the ecosystem that could support the organisation.

A small team cannot afford to be the first to discover a component's failure modes. Novelty was budgeted: it was permitted only where it created direct product advantage, and excluded from the substrate.

4. Build compliance-aware before compliance-driven

ISO 27001 and SOC 2 Type 2 requirements would come at about the same time as the organisation's first customer. The baseline posture therefore included what auditors and enterprise due diligence teams would eventually ask for: centralised identity and access management, audit logging by default, environment separation, encryption in transit and at rest. Built-in and set to be the default for all services.

As a result, certification became an exercise in documenting existing practice, with little remediation required. Automation was also implemented in the form of Drata to speed things up resulting in in-person audit meetings only requiring a few days at most. Enterprise security questionnaires — often a sales blocker for startups — could be answered from controls that already existed, and from a Trust Center that was established for customers to self-serve.

5. Automate what recurs; document what cannot yet be automated

Nothing was permitted to depend on one person's memory. Recurring tasks were automated and put into scripts in a central repository; tasks that could not yet be automated became written procedures that could be searchable throughout the entire organisation. This discipline substituted for a fleshed-out Platform Engineering team.

The execution: what we actually built

Foundation — Cloud accounts and environment structure, identity and access management, network topology, CI/CD, observability, secrets management. The deliberate first investment was the deployment pipeline, ahead of breadth in any other area — every future engineering hour would flow through it, so its quality compounded.

Software architecture — We worked on the platform's architecture in parallel. Two decisions mattered most for what came later:

• Separating the control plane from customer data-processing planes. This later let tooling deployments share a network while customer data was isolated according to data jurisdiction.
• Cloud-managed solutions chosen as often as responsibly possible. This resulted in lower operational toil when scaling requirements came in. Upsizing a database became a single-line code change, backups were built-in by default.
• Queue-based decoupling of heavy asynchronous processing workloads. This let compute be scaled and placed independently of the serving tier.

Engineering process. Organisational scaling depends as much on process as on infrastructure. We worked with the engineering team to streamline the path to production: standardised environment variables across all projects, standardised naming conventions that included regional annotations, standardised deployment workflow, and standardised ways of organising files within each repository.

The measures adopted were lead time and confidence: how quickly a change went from written to safely running in production, and whether the team deployed without ceremony.

This ultimately resulted in a system where developers could release multiple times a day, even hour, limited only by the duration it took for delivery pipelines to complete test runs. At the start, this was around 10 minutes, and at Series A level, this was a respectable 20-30 minutes.

Given the nature of the business, there was also a requirement to possibly bypass the standard delivery pipeline when critical issues were found. We entrusted this to the Platform Engineering role in the form of a manual workflow that could ensure a build could be deployed in less than 5 minutes when the need arose.

The expansion: Singapore to APAC, the US, and then EU

Why expand regions at all?

For a vendor selling to security-conscious enterprises, data residency frequently operates as a procurement precondition. Several enterprise deals could not proceed without contractual commitments about where customer data would be processed and stored. Regional presence was, in practice, a commercial requirement.

How do you deploy to a new region with a small team?

Each region followed the same repeatable pattern: re-apply the existing infrastructure-as-code with regional parameters, stand up regional data stores, connect to the shared control plane, validate, cut over. The marginal effort declined with each region: Infrastructure for a new region took roughly a week after all necessary resources were procured and approved by management, and the second and third region took only a day's worth of work for a single Platform Engineering role.

The causal links, stated as precisely as a single case allows:

• Infrastructure-as-code → expansion speed. New regions were instantiated from existing, tested definitions.
• Region-agnostic design → no architectural rework. No service required structural modification to run multi-region; the changes required were [configuration, data-layer parameterisation].
• Compliance-aware posture → shorter enterprise sales cycles. Regional data-handling questions in customer due diligence were answered from documented, existing controls.

What did not go smoothly

Cloud provider policies. There were policy changes in how certain resources were resolved which came unexpectedly. While this was ultimately resolved by re-architecting how we managed these resources in code, this ended up extending the duration required for expansion to a different region.

Multi-timezone operations. With a lean Platform Engineering team, operational support across timezones quickly became an issue. We resolved this by convincing the management team to adopt a follow-the-sun model which eased operational toil in the Singapore region during US operational hours.

The results

• From 3 people at pre-seed to a 70+ person Series A company, with the technology foundations laid in this engagement still in production
• Production operations in four regulatory regions across APAC, the US, and the EU, operated by a 2-person Platform Engineering team during the build and scale-out
• The entire system infrastructure was manageable by a one-person platform team, demonstrating that the bulk of operational toil was carried by automation and documented procedure
• ISO 27001 and SOC 2 Type 2 achieved on top of the existing control environment, plus repeated enterprise customer due diligence passed

What this means if you're running a startup or SME

The moment to design for your third region is before you deploy your first.

None of the five decisions above required a large team, a large budget, or exotic technology. They required someone in the room with the experience to know which inexpensive decisions become expensive later, and the authority to insist on them under delivery pressure. This is a common gap in founder-led companies: the technology functions, but no one with sufficient seniority is examining the decisions whose costs arrive years later.

This is the work we now do at Aijutsu, the founder-led, coaching-informed, AI-leveraged technology practice serving Singapore founders and SMEs: senior technical advisory, cloud, platform engineering, software architecture, and the compliance wall (ISO 27001 / SOC 2) that stands between startups and enterprise customers.

If enterprise customers, multi-region requirements, or security due diligence are on your horizon, the cheapest time to prepare is now. Book a diagnostic conversation with us: [email protected]

Frequently Asked Questions

How long does it take to expand a SaaS platform into a new region?

With infrastructure-as-code and region-agnostic service design in place from the start, the company in this case deployed additional regions in 2-3 weeks each after accounting for code-level changes in workflows. Without those foundations, regional expansion typically requires re-architecture measured in months, or a partial rewrite.

Do you need a platform team to run multi-region infrastructure?

Not necessarily. A startup that grew from 3 people at pre-seed to a 70+ person Series A company operated four regulatory regions with mainly product engineers only, by substituting automation and documented procedure for headcount. The substitution only works if it is designed in from day one; retrofitting automation onto manual operations is far harder, and letting go of hired personnel after automation implementation without a sound justification can have legal implications.

When should a startup start preparing for ISO 27001 or SOC 2?

Before it is asked for. Building a compliance-aware posture (centralised IAM, audit logging, environment separation, encryption by default) from the beginning means certification later is documentation work with little remediation — and enterprise security questionnaires stop blocking deals.

Why do enterprise customers require data residency?

Regulatory and internal policy obligations in jurisdictions like the EU, Australia, and Hong Kong often require customer data to be processed and stored in-region. For vendors, this makes regional presence a procurement precondition: deals cannot close without it.

What is the biggest mistake startups make with early infrastructure?

Creating resources manually and deferring codification. Infrastructure-as-code costs almost nothing on day one and is prohibitively expensive to retrofit; it is the single decision that most determines the later cost of scaling, compliance, and regional expansion.

---