Small, Composable, and Boring: A Better Architecture for Enterprise Software

A few months ago, a few of us on the architecture team were in a fairly ordinary meeting, comparing notes on why our internal tooling roadmap kept getting derailed by the "next big platform migration." Somewhere in that conversation, someone said out loud what most of us had been quietly thinking for years: the giant, do-everything products we keep buying are part of the problem, not the solution. That offhand comment is the seed of this post. What follows isn't a rant born from a bad afternoon — it's a case, built over years of watching the same pattern repeat, for why smaller, focused, API-connected systems consistently outperform monolithic platforms in real organizations.

The problem: how products become monsters

Almost every category of enterprise software — CRM, ERP, HR, ITSM, collaboration suites — follows the same lifecycle. A product launches solving one problem well. It gains traction. Then the roadmap shifts from "solve this problem better" to "solve every adjacent problem too." A CRM platform starts adding marketing automation, then customer support ticketing, then e-commerce, then analytics dashboards, then a workflow builder, then an AI assistant layered on top of all of it.

This isn't accidental. It's a rational response to market pressure. Vendors compete not just on quality but on breadth, because breadth creates switching costs and justifies premium pricing tiers. Every new module is also an upsell opportunity — a reason to move a customer from "Standard" to "Enterprise" to "Enterprise Plus." And because enterprise sales cycles reward checkbox-matching against RFPs, vendors are incentivized to build features that look good in a comparison matrix, whether or not any given customer will ever use them.

The result, release after release, is a product trying to be everything to everyone. Nobody sets out to build a bloated system. It accumulates one reasonable-sounding feature at a time until the core value proposition is buried under a dozen half-used modules.

The cost of bloat

The costs of this accumulation are rarely visible in a single line item, which is exactly why they persist. They show up as:

• Licensing costs that scale with capability you don't use. Enterprise tiers routinely bundle features your team will never touch, and pricing is structured so there's no "unbundled" option.
• A steeper learning curve for every new hire. Onboarding someone onto a platform with 40 modules takes far longer than onboarding them onto a tool that does one thing.
• A larger attack surface. Every module is more code, more integrations, more permissions to misconfigure, and more vendors in your supply chain to vet.
• Vendor lock-in. The more of your workflow lives inside one platform, the more painful and expensive it becomes to leave, which weakens your negotiating position at renewal time.
• Slower performance and harder upgrades. Monolithic platforms accumulate technical debt just like monolithic codebases do, and a platform-wide upgrade can break workflows in modules you don't even use.

None of this means these products are badly built. It means their incentives point toward breadth over focus, and customers absorb the resulting complexity whether they asked for it or not.

The alternative: composable small products

The alternative we've gravitated toward — and that I'd argue more engineering organizations should seriously consider — is deliberately unglamorous: instead of adopting or building one all-encompassing platform, build three to five smaller, purpose-built internal products, each owning a narrow, well-understood domain.

One product handles customer records and interaction history. Another handles internal HR workflows. Another handles resource or asset tracking. Each is small enough that a handful of engineers can understand the entire system, small enough to test thoroughly, and small enough to replace without a multi-year migration project.

This isn't a rejection of integration — it's a rejection of the idea that integration has to come pre-bundled at the cost of flexibility.

Why APIs make this work

The reason this approach doesn't just recreate the monolith's problems in a different shape is the API layer. If each small product exposes a clean, well-documented API, the products can talk to each other exactly as much as they need to — no more, no less. You get the coordination benefits of an integrated system without paying for a single vendor's version of "integrated."

This gives you three architectural properties that monolithic platforms structurally can't:

Loose coupling. Each system can change internally without breaking its neighbors, as long as the API contract holds.

Single responsibility. Each product has one job, which makes it easier to reason about, secure, and optimize.

Swappability. If one component becomes outdated or a better internal tool emerges, you replace that one piece behind its API — you don't rip out the whole system.

Trade-offs and honest caveats

This approach is not free. You trade platform bloat for integration overhead: someone has to own the API contracts, version them responsibly, and monitor more moving services instead of one. It demands more architectural discipline — clear service boundaries, ownership, and documentation — and it assumes your team has the maturity to operate several small systems rather than one big one. For very small teams or genuinely low-complexity needs, a single off-the-shelf platform can still be the pragmatic choice; not every organization needs — or can afford — the operational overhead of a composable architecture.

What we've actually seen

We've lived this transition in practice, not just in theory. We replaced a large, all-in-one CRM platform with a smaller internal tool scoped tightly to how our sales and account teams actually work, and immediately cut both licensing cost and onboarding time. We built an internal HR system rather than adopting a sprawling HR platform, because our actual HR workflows used a fraction of what those platforms offered. And we moved away from a monolithic ERP-style product toward a simpler internal tool connected via API to our finance and operations systems. In each case, the lesson was the same: the smaller tool did less, and that was the point.

Practical takeaway

You don't need to rebuild your entire stack to start. Pick one "monster" product in your environment and identify the two or three features your team relies on most heavily. Sketch out what a standalone service for just those features would look like, with a clean API. Build that first, run it alongside the existing platform, and let it prove itself before you touch anything else. Composable architecture isn't an all-or-nothing rewrite — it's a discipline you can start applying to one overloaded feature this quarter.

Rethinking a monolithic platform? Talk to us about scoping a composable, API-connected architecture around what your team actually uses. Start a conversation.