One codebase, two storefronts

Name

one-codebase — One codebase, two storefronts

Synopsis

one-codebase --client "subscription ecommerce, Shopify" --role "Planning, audit and implementation" --when 2026 – present

--stack Vue 3, TypeScript, Vite, Vitest, Shopify

Description

Leading the merge of two storefronts that had forked from the same app into one shared codebase, where each feature is written once.

Context

The client runs two storefronts that started as one app and then forked. Over time the copies drifted: most new features were written twice, a little differently each time, and the gap grew every month.

My role

I planned the merge, estimated it, and am carrying it out alongside regular feature work.

What I did

• Measured the drift. A small script lists every shared file that still differs, so progress is a number, not a feeling.
• One typed configuration. A build-time setting picks the storefront. Everything that really differs (copy, currency, links, legal pages) lives in one typed module, so shared components never need to know which site they are on.
• An audit before the switch. I listed everything that would block moving the second site onto the shared app and turned it into a plan of small pull requests, each reviewable and shippable on its own.
• Stopped the drift growing. Until the switch, any feature for both sites is one pull request with the same code in both places.
• Fixed what turned up. The audit surfaced a handful of live bugs along the way, such as a deadline check that used the wrong timezone, which were fixed as they came up.

Trade-offs

A big-bang merge looks faster on paper, but the business ships changes to both sites every week. Small, incremental pull requests let both sites keep shipping while the merge goes on.

I chose build-time configuration over runtime detection: each site only ships its own settings, nothing can leak from one to the other, and the type checker enforces it.

Outcome

• The shared app already builds both sites in CI, with type checks and the full test suite passing for each.
• The shared configuration and the first shared components are merged; the switch-over is next.

What I’d do differently

Add the drift check to CI on the first day of a fork, so it shows up on every pull request instead of in an audit later.

See also

experiments(1), faster-funnel(1), tiago(1)