Guide
Running one software across two countries
When a business operates in two countries —say the U.S. and a market in Latin America or Spain— the temptation is to build "two of everything": two systems, two teams, two versions of the truth. It is the fastest way to double your costs and to make sure the numbers never match. There is a better way: one well-designed software that speaks two currencies, two languages and two time zones without splitting in two.
By Miguel Alejandro Hayes· Founder, Hayes Projects
The "two of everything" problem
Two parallel systems always drift apart. A price change, a promotion, an inventory adjustment: you do it twice, and sooner or later you forget one. The result is reports that do not match, customers who see different things depending on the country, and a team losing hours reconciling by hand.
The root problem is not operating in two countries —it is treating each country as a separate system instead of a variation of the same one.
What is shared and what is separated
You share the core: business logic, master data, consolidated reporting. You separate the market layer: currency and its conversion, product and support language, local taxes and rules, time zone. Done right, a single change in the core reflects in both countries and each market sees what belongs to it.
Reporting is the acid test: if you can see the business consolidated and country by country without exporting by hand and pasting into a sheet, the design is sound. If not, you have two systems wearing one costume.
How we build it
We start from the shared core and add the per-country layer as configuration, not duplicated code. That way opening a third market later is adding a configuration, not rebuilding. Multi-currency and multi-language are designed in from day one, not patched in afterward.
If you already run two countries on two systems, the best step is often not to throw it all out, but to unify the core and keep only the layer that genuinely has to differ. We scope it in a short validation phase before moving anything big.
Frequently asked
Can I handle two currencies without two systems?
+
Yes. Currency is a configuration layer on top of a shared core. The mistake is treating each country as a separate system instead of a variation of the same one.
What about consolidated reporting?
+
That is the acid test: a good design lets you see the business consolidated and country by country without exporting and pasting by hand. If you cannot, you have two systems in one costume.
I already have two separate systems. Do I rebuild everything?
+
Almost never. The usual move is to unify the core and keep only the layer that must differ. We assess it in a short phase before touching anything big.
About the author
Miguel Alejandro Hayes — Founder, Hayes Projects
Economist and essayist turned developer. He founded Hayes Projects, a Miami venture studio and custom software lab, to build software that ships, scales and solves real problems.
Meet the founder→Operating —or about to operate— in two countries? Book 20 minutes and we will tell you what to unify and what to separate.
Book 20 min — no pitch →Prefer email?
Leave your email and we'll reach out with an idea for your case.
No obligation. No spam — just one useful, concrete reply.