A shared codebase can preserve runway until different market requirements force separate product decisions. At that point, treating one market as a configuration of the other creates slower releases, hidden compliance risk, and a team that cannot say which customer it is building for.
Consider Kwame, an invented composite founder running a fintech team between Accra and Berlin. At 9:17 on Tuesday morning, he was holding a cooling mug of coffee while two release messages sat open on his screen. The Accra team needed to change the onboarding flow before a pilot review. The Berlin team needed the same engineers to finish a consent and account-recovery change.
Both requests touched the same service. Neither could wait comfortably.
If Kwame approved the Ghana release, the European pilot could miss its review window. If he held Ghana back, a prospective partner there would see the same unresolved onboarding problem for another week. The architecture had been chosen to keep six people shipping one product. It had quietly turned every local decision into a negotiation between two products.
The shared codebase hid a product decision
The original choice made financial sense. One backend, one onboarding flow, one release process. The team could enter a second market without hiring another engineering group or maintaining two systems.
That calculation treated the visible screens as the product. The harder differences lived underneath.
A customer in Ghana entered through one commercial relationship, used a particular payment path, and expected support to understand the local failure modes. A customer in Germany entered through another relationship and brought different expectations around consent, records, and recovery. Even when both customers tapped a button labelled “Continue,” the promise behind that button was different.
The team handled each new difference with another condition in the code. If market A, show this step. If market B, store that record. If this partner, route the request there.
Each condition looked cheaper than a split. Together, they made ownership unclear. An engineer could change a shared component for Berlin and discover during testing that Accra depended on an older sequence. Product decisions travelled through code paths nobody could explain in one meeting.
This resembles the problem behind what happens when one payment record multiplies across your systems. Duplication can be visible and therefore manageable. Hidden coupling feels cheaper until one change reaches several places at once.
Neither market agreed to be the branch
At 9:31, Kwame asked a question that changed the meeting: “Which market owns the default flow?”
Nobody answered.
The product manager in Berlin had been writing requirements as though the European flow was the base product, with Ghanaian needs added as exceptions. The Accra commercial lead believed the opposite because the earliest customers, operational knowledge, and partner conversations had started there.
This was more than team friction. Defaults reveal hierarchy. The market represented by the clean path receives faster decisions and fewer regressions. The other market accumulates flags, workarounds, and explanations.
Customers eventually feel that hierarchy. A partner does not care that an awkward onboarding step came from a shared architecture decision made eighteen months earlier. They see a product that appears to understand another customer better.
The danger was no longer a delayed Tuesday release. Kwame could lose trust in both pilots while still telling himself the company had one efficient product.
Preserving runway required a clearer boundary
Splitting the company into two engineering teams would have consumed runway the business had not earned. Keeping every layer shared would preserve cash on paper while increasing the cost of each decision.
Kwame needed a narrower split.
The team paused both release requests long enough to draw three boundaries. The ledger and core transaction rules would remain shared. Market-specific onboarding, consent, payment routing, and recovery flows would receive explicit owners. Shared components would need a named reason to remain shared, rather than staying shared because nobody had decided otherwise.
Then they separated release approval. A change for one market could proceed when its owner had tested the affected local flow and confirmed that the shared core remained intact. The other market no longer held an automatic veto, but any change touching the core still required both owners.
This did not produce a perfect architecture. It produced an honest one.
The approach also exposed a commercial constraint. Every request to “support one more market” now carried a visible cost: local product ownership, testing, operations, and ongoing decisions. Market expansion could no longer hide inside a country field and a few conditional statements.
The next release started with one sentence
Late that afternoon, Kwame reopened the two release messages. The Ghana onboarding fix went to its local owner. The German consent and recovery change followed a separate review path. One shared service still needed careful testing, so neither release moved immediately.
The risk remained real, but it had a name and an owner.
Before the next planning session, Kwame added one sentence above the roadmap: “We share infrastructure where the customer promise is the same.”
That sentence gave the team a test. When the promise differed, they could stop arguing about whether a request was an exception and decide what boundary the product required. When the promise matched, they could keep the shared layer and protect runway.
On Wednesday morning, the roadmap still contained both markets. Neither appeared in a footnote beneath the other.
Comments
No comments yet.