Market Fork Carry Cost

A payments team could be live in a second country in 11 weeks by forking the checkout service, or in 26 weeks by making the one service market-aware. The fork was approved in a meeting that discussed the 15 weeks and never discussed what happens afterwards. Eighteen months later two teams were shipping the same fraud rule twice, the fork had drifted on refund handling, and nobody could say what re-merging would cost.

The carry cost is the monthly bill for that decision, and it is the number the approval conversation is missing. It is not the cost of making the copy, which is nearly zero. It is the cost of keeping two copies of logic that the business believes is one thing.

Why it matters

Forking to hit a date is a legitimate move and it is made constantly. What makes it dangerous is that the saving is visible on a plan and the cost is invisible in a ledger: it is absorbed as slightly slower delivery across both teams, month after month, attributed to nothing.

Pricing it changes two behaviours. It makes the trade explicit at approval time, and it gives the fork an expiry: a decision with a monthly cost attached eventually gets revisited, where a decision with no number attached never does.

Implementation patterns

• Estimate from the shared change rate, not the line count. Take merged changes a week, multiply by the share that touches logic both markets need, multiply by the average change effort, multiply by a port factor of roughly 0.3 to 0.6. A team merging 14 changes a week with 30% shared logic lands around half an engineer of pure port tax.
• Add the operational twin. A second pipeline, a second on-call surface, duplicated dependency and certificate upgrades, and — where the code is in scope for a standard such as PCI DSS — a second code path to evidence rather than one. This typically takes the figure to 0.7 to 0.9 of an engineer.
• Track skipped ports as the leading indicator. Every skipped port is permanent divergence. Report the count monthly next to delivery metrics.
• Attach three things to the approval: an expiry date, a named merge owner, and the monthly figure. Without all three the fork is a second product that nobody has budgeted.
• Prefer configuration over copying when the difference is data. Per-market rules as versioned configuration behind one code path avoid the carry entirely, at the price of a slower first launch.
• Re-estimate at six months. The port factor rises as the copies diverge, so an estimate made at fork time understates the second year.

Industry example

Vendor platforms show the same arithmetic from the other side. SAP's published clean core guidance, updated in 2024, pushes customers to build extensions against released interfaces rather than modifying the standard core, with the stated aim that an upgrade stops being an event for custom code. The underlying economics are identical: a modification is a private fork of vendor logic, and its cost is paid at every upgrade, by whoever happens to own the system then.

Failure scenarios

• The expiry passes and nothing happens, because the original sponsor has moved on and the cost sits in two teams' velocity rather than in any budget line.
• Divergence on a correctness-critical path. The two copies disagree on refund or fraud behaviour, so re-merging becomes a rewrite with a proof obligation attached.
• The fork is used as the template for a third market. The carry cost is no longer linear and the re-merge is now a programme.
• Silent regulatory drift, where a control is updated in one copy only and an auditor finds the other.
• The merge is funded but not sequenced, so it competes with features every quarter and loses every time.

Trade-offs

A fork buys a date, and dates are sometimes worth a great deal: a licence window, an anchor partner, a seasonal peak that will not come round again for a year. Against that it costs continuous effort, a rising re-merge price, and an optionality loss that is rarely named — while the fork exists, any change to shared logic is twice as expensive, so the team quietly stops making them.

The useful comparison is total, not monthly. Fifteen weeks saved at a nine-person team is roughly eight engineer-months brought forward. At 0.8 of an engineer carried, the fork overtakes that saving somewhere around month ten to twelve.

When not to use it

Do not bother measuring when the shared change rate is under about one change a week; the carry is noise and the fork is simply the cheaper structure. Do not use the metric at all when the divergence is permanent and structural — a different regulator, a different settlement rail, a different licensed entity. That is not a fork awaiting a merge, it is two products, and they should be designed as two with a shared library rather than managed as a debt that will never be repaid.

Interview question

Q: A sponsor wants to approve a fork of your core service today to hit a market launch 15 weeks earlier. What do you put in front of them, and what would make you argue for the fork yourself?

What a strong answer covers: deriving the monthly carry from shared change rate and port factor; naming the skip rate as the dominant risk; insisting on an expiry date and a merge owner as approval conditions; comparing total carry against engineer-months brought forward; and acknowledging that the fork is right when the date decides whether the market exists at all, or when the divergence is structural and the honest answer is two products.

Quick check

Quiz: A team merges 14 changes a week, 30% touch shared logic, an average change is 1.5 engineer-days and porting costs 0.4 of the original. What is the port tax? About 2.5 engineer-days a week, roughly half an engineer, before duplicated pipelines and on-call.

Flashcard: What dominates the error in a fork's carry-cost estimate? — The skip rate, not the port cost. A skipped port is permanent divergence, and once the copies disagree on business rules the re-merge becomes a rewrite rather than a port.