October 14, 2025

Software ArchitectureProduct StrategyScalable Business

The One-Codebase Trick

A system copied for every client, office or market makes you pay for every fix once per copy. One codebase configured per client pays once, provided you build for one client before you generalize.

Shopify runs t-shirt sellers and furniture makers on the same code, configured for each shop. One codebase, configured per client, means one fix per bug; a copy per client means one fix per copy.

The same arithmetic applies inside a firm. A system copied for each office, market or large client is several systems to maintain, and every fix, release and security patch is paid for once per copy.

What the Copies Cost

Copying a system for each new client feels like growth. Ten clients become ten codebases, ten deployments and ten bug lists. Then a bug appears: you fix it in client A’s copy, forget to carry it to client B, and client C never gets it. Six months later there are three versions of what was meant to be one product, each needing a developer who knows “the way things work here”, and every release is a risk taken once per copy.

One Codebase, Configured

Copies: 10 clients = 10 custom codebases

10 codebases, 10 deployments, 10 bug lists. Every fix applied by hand per client; every feature negotiated per contract. Illustrative: 200 hours a month of maintenance, and the team's time goes on keeping the past alive.

Platform: 10 clients = 1 codebase + 10 config files

1 codebase, 1 deployment pipeline, 1 bug list. Every fix and feature reaches every client at once. Illustrative: 20 hours a month of maintenance, and the team's time goes on what comes next.

The hours are illustrative; the point is that the work stops being repeated for every client.

What Configuration Means

Configuration is a design decision made in advance: which parts of the system are the same for every client, and which vary.

Same Core Engine

Intake, processing and output: identical for every client.

Industry Config

Terminology, categories, instructions and workflow rules for each industry.

Integration Config

Which systems each client connects: email, CRM, storage, calendar, accounting, ERP.

Branding Config

Logo, colour palette, tone of voice and domain, with no code changes.

Pricing Config

Features per pricing tier, usage limits, and the modules each plan switches on.

The core engine does not know which client it is serving. It knows only the configuration it was given at startup, and that separation is the whole trick.

Law firm: legal terminology, precedent search, case citations. It reads briefs, contracts and discovery files, and produces structured summaries with citations and flagged risk clauses.

Dental clinic: patient-friendly language and insurance terminology. It reads referral letters, treatment plans and claim forms, and produces plain-language summaries and pre-authorization drafts.

Accounting firm: financial terminology and invoice extraction. It reads statements, invoices and tax filings, and produces reconciliation reports and flagged discrepancies.

One pipeline and one deployment; to each client, a different product.

Adding a Connection Without a Rewrite

Configuration handles what varies per client; connectors handle what varies per data source. Every source (email, cloud storage, CRM, ERP) plugs in through the same interface of two methods, list_documents() and fetch_document(). Adding Google Drive means writing one connector and switching it on in the configuration of the clients who need it, with no change to the pipeline.

Illustrative durations, for a team that keeps the pattern.

First connector: about 2 weeks, because it also sets up the interface, error handling, retries, authentication and the test harness.

Second: about 3 days. The pattern exists; you implement it and write the tests.

Third: about a day. By the tenth: an afternoon, with a template, a checklist and tests that catch mistakes at once.

When Not to Do This

Building a platform before a product has its own trap: you design the configuration around imagined differences and under-deliver on what the first client needs.

Build for one client and make it work well. When a second client needs something different, look at what actually varies between the two and move that into configuration. Designed any earlier, the configuration makes stable things adjustable and hard-codes the things that vary.

The signal is the moment you are about to copy the codebase for a new client. Then, and not before, pull out the core, define the configuration, and build the second client on it instead of on a copy.

If your firm already runs several copies, folding them back into one is done piece by piece, starting with the core they share, while the copies keep running. Every fix after that is paid for once.

How many copies of the same system does your firm maintain?

Talk Platform Strategy