Data Residency: Architecture as a Market-Entry Decision
A workforce scheduling SaaS, successful in one market, had signed a customer in a second country contingent on in-country data residency, with three more regulated markets in the plan. Engineering’s answer — deploy the whole stack per country — would have taken infrastructure and operations from ~11% to a projected 26% of revenue. Envion classified every data element against the five markets’ regulations and found that 12% of the data carried 100% of the compliance obligation. The answer was a cell-based architecture: uniform stateless application, regional data plane, global control plane, with residency enforced in the type system. Eighteen months on, four markets live: infrastructure ~€31K/month versus ~€76K modelled for full copies, 13% of revenue, and a new market launches in 9 days.
The challenge
The client was successful in a single market and had signed a letter of intent with a customer in a second country contingent on in-country data residency. Two more markets were in the commercial plan for the following year, one with public-sector customers carrying stricter sovereignty requirements.
Engineering's initial answer was to deploy the whole stack per country. Simple, obviously compliant, and — when the numbers were run with their finance team — it would have taken infrastructure and operational cost from roughly 11% of revenue to a projected 26% at five markets, plus five separate deployment targets for a team of thirty.
The CEO's question was framed commercially: at what point does market expansion stop being profitable because of this architecture?
Decision path
Data residency is not a binary property of a system. It's a property of specific data, under specific regulations, in specific jurisdictions. The first task was to stop treating "the platform" as the unit and find out what actually had to stay in-country.
Every data element was classified against the regulatory requirements of the five target markets. Must reside in-country: employee personal data, scheduling records containing identifiable shift patterns, payroll-adjacent data — roughly 12% of total data volume, and 100% of the compliance obligation. Must reside in-region (EU): aggregate analytics and audit logs containing user identifiers. Can reside anywhere: the product itself, configuration templates, feature flags, the rating rules engine, ML models, the entire frontend, and all operational tooling.
That classification converted the problem. They didn't need five copies of the platform. They needed five copies of about an eighth of their data, and one platform that could be deployed close to it.
Envion contribution
A cell-based model: the application is uniform and stateless across cells, the data plane is regional, and the control plane is global.
Cells — one per residency boundary, each running the full application stack against in-country data storage. Identical, deployed from the same artifact, with no cell-specific code. That constraint is the whole design; the moment cells diverge you have five products.
Global control plane — deployment orchestration, feature flags, configuration, licensing, aggregate telemetry with data scrubbed at the cell boundary before it leaves.
Cell router — customers routed to their cell at authentication.
Data classification enforced in code — a typed boundary that makes it a build-time error to write residency-classified data to a global store. Compliance implemented as engineering discipline degrades; compliance implemented as a compiler error does not.
The trade-offs, made explicit: every cell runs the same version within a narrow window — giving up per-market release timing to avoid the per-market fork that has killed more international SaaS expansions than any other failure mode. Cross-cell analytics become a deliberate pipeline rather than a query — accepted, because the alternative is the compliance obligation itself. Higher fixed cost per market than a shared deployment, much lower than a full copy — roughly €4.2K/month incremental per cell versus €19K. And the one non-negotiable: cell provisioning fully automated before market two, not after — a manually provisioned second cell is survivable, a manually provisioned fifth is a permanent operational tax.
Delivery
The first two cells were stood up with the automation built first, exactly so that markets three and four would be routine. Each new market launch exercised the same pipeline — provision cell, route, verify classification at the boundary — with no per-market code.
Outcome and evidence
Eighteen months on, four markets live: infrastructure runs at about €31K/month against ~€76K modelled for the full-copy approach, infrastructure plus operations sits at 13% of revenue instead of a projected 26%, a new market launches in 9 days instead of ~14 weeks, there is one deployment artifact across four cells, zero codebase forks, version skew capped at one release, and expansion required +2 engineers instead of an estimated +6.
The nine-day market launch is the number their commercial team cares about. It changed how they evaluate market entry — a country that would have needed a €400K commitment now needs a two-week decision, so they can test markets rather than bet on them.
| Metric | Full-copy approach (modelled) | Cell architecture (actual) |
|---|---|---|
| Infrastructure cost at 4 markets | ~€76K/mo | ~€31K/mo |
| Infra + ops as % of revenue | ~26% projected | 13% |
| Time to launch a new market | ~14 weeks | 9 days |
| Deployment targets | 4 divergent | 1 artifact, 4 cells |
| Codebase forks | Likely 2+ | 0 |
| Version skew across markets | — | Max 1 release |
| Engineering headcount for expansion | +6 estimated | +2 |
Client feedback
What the client says about this engagement
“We were about to build five copies of our product and call it international expansion. Oleg's classification exercise found that twelve percent of our data carried a hundred percent of our compliance obligation, and everything after that followed from it.
The insistence I'm most grateful for is the automated cell provisioning before market two — it felt like premature optimization at the time and I pushed back. We now stand up a new country in nine days, and our board treats geographic expansion as a test rather than an investment case. That's an architecture decision that changed our commercial strategy, which I didn't expect to be able to say.”
From the engagement lead
What I’d tell anyone considering this
“If regulation is shaping your architecture, classify the data before you design anything. The obligation almost always attaches to a small fraction of what you store, and teams routinely apply the strictest constraint to the entire system because nobody has done the classification. That's the difference between an expensive architecture and a manageable one.
Enforce the classification in the type system or the schema, not in a policy document. Anything that depends on every engineer remembering a rule will fail within a year of hiring.
And build the automation for the second instance before you have a second instance. The point at which it's obviously necessary is the point at which it's expensive and disruptive to add.”
Evidence gate. This page publishes only what Envion's project records and client disclosure permissions support. Outcomes are added once verified against a baseline, a measurement period, and an approved source.
FAQ
Questions about this case
Facing a similar challenge?
Expanding into regulated markets? Classify the data before you design anything — Envion turns residency from a cost wall into a nine-day market launch.
Discuss a Similar ChallengeKeep exploring
Similar case studies
Executive Technology Leadership
Support for high-stakes product and AI decisions
Bring senior technology leadership into the business when the roadmap is unclear, delivery is at risk, an AI initiative needs stronger ownership, or the company needs an experienced technical voice before hiring a permanent CTO.
Discuss Interim CTO SupportCore responsibilities
- Align product and technology priorities with business goals and measurable outcomes.
- Review architecture, delivery risks, data foundations, security needs, and AI readiness.
- Lead internal teams and external partners through a practical execution plan.
- Clarify team structure, ownership, decision rights, and delivery cadence.
- Support investor, board, partner, and due-diligence conversations with credible technical judgment.
New experience
Prompt-to-Page — try it right here
Describe the landing page you want, in your own words. We turn it into a finished page and email you a private link in 5–10 minutes — no briefs, no calls, $0 to see the result.
- Describe what you want to create.
- We structure, write, and compose the page.
- You receive a private link when it is ready.
Start with a sentence — the interactive builder takes it from there.
Generate My PageSafe, respectful content only. No obligation.