Modularity and Scalability: Architecting Systems You Can Change Later

I'm Tom Lang — I've built and scaled engineering organizations for three decades, through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

"Future-proof" is one of my least favorite words in technology. I've been building and scaling systems for three decades, and I have never once seen an architecture the future couldn't surprise. New models show up weekly, data volumes explode, and the requirements you're certain about today get rewritten by the market next quarter.

So I don't try to future-proof anything. I try to do something more useful and more honest: build systems where changing my mind is cheap. That's what modularity and scalability are actually for — not predicting the future, but staying able to respond to it without a rewrite or a rescue.

This matters whether you're a founder architecting something for the first time or you're running an established system you're afraid to touch. I'll speak to both, because the principles are the same even when the starting points aren't.

What modularity is really for

Modularity usually gets explained as microservices and containers, and we'll get there. But strip the vocabulary away and it's one idea: clean seams. If your system is built so any one piece can be replaced without disturbing the others, you can adopt a better model, swap a data engine, or rip out a bad decision without the whole thing coming down with it.

Here's the part most "best practices" posts skip: you can have too much of this, too early. If you're a founder, one of the worst moves you can make is standing up a swarm of microservices before you have the traffic, the team, or the clarity to justify them. You'll burn your runway on operational overhead instead of product. Early on, a well-structured monolith with clean internal boundaries — clear modules, clear interfaces — gives you almost all the modularity that matters and none of the distributed-systems tax. Modularity lives in the seams, not the server count. Draw the seams first; split across the network only when something real forces you to.

You don't have to rewrite the monolith

The most useful modularity lesson I've learned came from the opposite situation — a system that was already enormous.

Years ago I built an agent-commission platform for a life-and-annuity company. Two decades and three changes of ownership later, they brought me back to help modernize it. By then the feature set was vast — the product of twenty years of real-world business rules — and the plan everyone kept reaching for was the obvious one: rewrite it on a modern stack, then cut over.

That plan was impossible, and it's worth being clear about why, because teams talk themselves into it constantly. When a system encodes twenty years of hard-won business logic, a big-bang rewrite-then-migrate isn't just risky — you will never catch up to a moving target while also reproducing every rule you've forgotten you have. Every month you spend rebuilding, the old system keeps evolving underneath you.

So we didn't rewrite the monolith. Instead I designed a new architecture that could talk to the old one — the two could call each other's services, in both directions. That single decision changed everything. It meant we could implement any given feature in the legacy stack, in the new stack, or as a hybrid that used both, and choose per feature based on what was actually smart. Modernization stopped being a cliff you had to leap and became a path you could walk — feature by feature, business running the whole way, migrating toward the new architecture as it made sense instead of all at once.

That's the real payoff of modularity: you don't have to rewrite the monolith to modernize it. You have to build a seam between old and new — a way for them to interoperate — and then you get to move at the pace the business can actually absorb. The industry has a name for this now, but I'd been doing it for years before I heard the term. The mindset matters more than the label: build the new alongside the old, let them work together, and retire the legacy piece by piece.

Scalability without the handcuffs

Scalability is the other half, and here I'll lean on the other end of my career. At Videology I built the engineering organization from two people to more than 150, and the platform to more than three billion transactions and four terabytes of data a day. We moved to AWS early — early enough that the only way to deploy to production was a command line. So I have real scars here, and one strong opinion.

Lean into managed cloud services for the speed, but keep your core logic portable enough that you can still change your mind. That's the balance. Managed services — databases, queues, serverless, the managed ML platforms — are a genuine gift; they let a small team punch far above its weight and hand the undifferentiated heavy lifting to a provider who does scalability for a living. Use them. But don't marry your core business logic to a proprietary service you could never leave. Containerize what's yours, keep your interfaces clean, and treat deep vendor lock-in as a cost you take on deliberately, eyes open — not one you back into because a tutorial made it easy. The goal, again, is staying cheap to change. (The data-platform-specific version of this — designing data architecture that scales with the business instead of trapping it — is its own deep-dive: designing data platforms that scale.)

Make change safe

None of this works if you can't change things safely. Two practices earn their keep here more than any others:

• Infrastructure as code. If your environment lives in Terraform or CloudFormation instead of in someone's head, you can reproduce it, review it, and roll it back. Change stops being scary.
• Real observability and automated delivery. You can only move fast when you can see what's happening and ship without holding your breath. Solid logging, metrics, and a CI/CD pipeline aren't luxuries — they're what make the incremental change everything above depends on actually possible.

I keep these deliberately unglamorous. They're the plumbing that lets you exercise all that modularity without breaking things.

The honest goal

So, no — I won't sell you a future-proof architecture, because there's no such thing. What I'll tell you to build instead is a system you can change your mind about cheaply: clean seams so you can replace pieces, a way for new and old to coexist so you're never forced into a big-bang rewrite, managed scale without the handcuffs, and the automation to make change safe. Do that, and the future doesn't have to be predicted. It just has to be survivable — one affordable change at a time.

If you're staring down a modernization you're afraid to start, or you're architecting something now and want to avoid painting yourself into a corner, that's exactly the kind of problem I help with. Book a call and let's get a clear read on where you stand.