Work TSUKI
Three markets, one commerce backend
Tax, payment and fulfilment rules for Taipei, Tokyo and Singapore collapsed into a single configurable rules engine.
- Industry
- Retail
- Year
- 2025
- Stack
- Workers · Durable Objects · Stripe · Multi-currency
3
markets, one system
The problem
Tax, payment and fulfilment differed across three markets, maintained as three separate systems by three separate teams. One price change meant three back offices, and one of the three was regularly forgotten.
The constraint
Three sets of regulations will not converge to suit an architecture. Tax-inclusive display in Japan, government-issued invoices in Taiwan, the GST registration threshold in Singapore — none of that abstracts away. It can only be expressed well.
The approach
We modelled the differences as configuration rather than branching code. Tax, payment and fulfilment each became a set of configurable rules, and a market is one combination of them. Opening a market is filling in a form.
One decision
The rules engine is deliberately not general. It supports only the shapes of rule these three markets actually need, and it states in writing what it will not express. An engine that can express any rule eventually becomes a second programming language that nobody on the team can read.
The trade-off
That means a fourth market with a genuinely different rule shape still requires code. We costed it: such a market sat seventh or lower on their expansion list, and paying for generality now was not worth it.
The outcome
One backend across three markets. Evaluating a fourth went from six weeks to two days.
Since then
They opened a fourth market in early 2026. The rule shapes did fall inside what the engine supports, and no code changed — the bet paid.