A payments company can be live in a second country in 11 weeks by forking the checkout service, or in 26 weeks by making the existing service market-aware. The fork wins the date and the sponsor wants it approved today. Roughly what does the fork cost per month afterwards, and what must the approval record say?

The assumptions, stated

Write them down before arguing, because the argument is always about the assumptions and never about the arithmetic.

• Nine engineers across two squads merge roughly 14 changes a week into checkout today.
• About 30% of those changes are logic both markets need: pricing rules, fraud signals, retry and idempotency behaviour, anything inside the card-data path that an auditor will look at.
• Porting a change by hand into a forked codebase costs roughly 0.3 to 0.6 of the original, because the code is re-reviewed, re-tested and run against different fixtures. Take 0.4.
• An average change is about 1.5 engineer-days.

The arithmetic

14 changes a week × 30% shared ≈ 4.2 shared changes a week. Each costs 0.4 × 1.5 days ≈ 0.6 days to port, so the port tax alone is about 2.5 engineer-days a week, call it 0.5 of an engineer. Add a second release pipeline, a second on-call surface, duplicated dependency and certificate upgrades, and a second card-data code path to evidence rather than one, and 0.7 to 0.9 FTE of continuous carry is the honest range.

Over 18 months that is roughly 11 to 16 engineer-months. The fork saved 15 weeks of elapsed time, which at this team size is about 8 engineer-months of work brought forward. The carry cost overtakes the saving somewhere around month twelve, and it keeps running after that.

Which assumption dominates the error

Not the port cost. The skip rate. Under deadline pressure ports get deferred, and a deferred port is permanent divergence, because the next change lands on a file that no longer matches. Once the two codebases disagree about the fraud rules, re-merging is not a port, it is a rewrite with a correctness proof attached, and the estimate moves from engineer-months to a funded project. A skip rate of 1 in 5 for six months is enough to do this.

What the number rules in and out

Approve a fork only with a written expiry date, a named merge owner and a monthly port-debt figure reported alongside delivery. Without those three, the fork is not a shortcut, it is a second product nobody costed.

The decision flips in two directions. If the shared change rate is under about one a week, the carry is noise and the fork is simply cheaper. If the divergence is structural rather than temporary, different regulator, different settlement rail, different licence holder, then it was never a fork: build two services deliberately and share a library, which costs less than pretending one codebase is coming back.

When this is the wrong answer

When the 15 weeks decides whether a licence window, an anchor partner or a seasonal peak is caught at all. A fork that unlocks a market worth seven figures a year is cheap at 16 engineer-months. The error is not forking; the error is forking without pricing the carry and without a date on which someone must answer for it.