Skip to main content

LambdaLynx: Architect Clarity. Build Momentum

Multi-Tenant Architecture: The Rewrite You Never Have to Do

A founder told me her product was built for dentists, but she was already getting emails from veterinarians asking if it worked for them too. She wanted to say yes. She was afraid that saying yes meant rebuilding everything.

That fear is usually well-founded. Most products get built for exactly one type of customer, and the assumption that there will only ever be one type gets baked deep into the database. Then a second market shows up, the “quick expansion” turns into a six-month rewrite nobody budgeted for, and the founder is stuck choosing between the opportunity and the runway.

On a recent project, I designed the data model to be multi-tenant from the first commit. Every table that held customer data carried a tenant ID, and the application resolved which tenant a request belonged to and scoped every read and write to it automatically, so no query could accidentally reach across from one customer’s data into another’s. We also kept the vocabulary generic on purpose. We used “subject” instead of “specialty,” “domain” instead of “profession,” so nothing in the schema quietly assumed the business would only ever serve one kind of user.

None of that was expensive up front. It was a handful of decisions made early, when they cost almost nothing. The costly version is the retrofit: bolting tenancy onto a system that was built assuming it would never need it. That work touches every table, every query, and every piece of security-sensitive code, and you do it while paying customers are already live on the old design.

When a second market did eventually show up, expanding meant adding a configuration row, not writing a new codebase.

The cheapest rewrite is the one you never have to do. If there’s any real chance you’ll serve a second type of customer someday, ask whoever’s building your product whether that someday is a config change or a rewrite. The answer tells you how much of your future they actually designed for.

#FractionalCTO #StartupTech #SoftwareArchitecture



Leave a Reply