Lean Stacks: Why We Pick Boring, Purpose-Built Tools Over Frameworks

There’s a moment in almost every project kickoff where someone proposes the framework. The big one. The one with the conference, the certification track, the "enterprise" tier, and the slide that promises it does everything. And almost every time, choosing it is the first quiet mistake of the project.

After more than a decade of shipping enterprise software, we’ve developed a strong bias at Simplico: we reach for the smallest, most boring, most purpose-built tool that solves the actual problem in front of us. Not the most powerful. Not the most popular. The one with the least surface area we’ll have to defend in two years.

This isn’t minimalism for its own sake. It’s a position we’ve arrived at by living with the alternative.

What "boring" actually means

When we say boring, we don’t mean old or unfashionable. We mean predictable. A boring tool does roughly what its name says, fails in ways you can reason about, and doesn’t surprise you at 2 a.m. PostgreSQL is boring. A message queue you can explain on a napkin is boring. A 300-line FastAPI service that does one thing is boring.

Boring tools share a few traits. Their failure modes are well-documented because thousands of teams have hit them before you. Their abstractions are shallow enough that you can read the source when you need to. And critically, the knowledge you build operating them transfers — a Postgres index behaves the same whether it’s backing an ERP or a vector search.

Exciting tools invert all three. The failure modes are novel (congratulations, you’re the first to file the issue). The abstractions are deep, so debugging means peeling back layers you didn’t write. And the expertise is non-transferable — it evaporates the day you stop using the tool.

Frameworks solve the average problem. You don’t have an average problem.

A large framework is a bet that your problem looks like the problem its authors imagined. When it does, the framework is magic — you get auth, admin, ORM, migrations, and a dozen other things for the cost of a config file.

The trouble is that real client work rarely sits at the center of that bet. It sits at the edges. And at the edges, every convenience the framework gave you becomes a constraint you now have to fight. The escape hatches are awkward. The "right way" stops mapping to your way. You spend your innovation budget learning how to convince the framework to let you do the thing your client is paying for.

We’ve watched teams spend more time fighting their framework’s opinion about background jobs, or its assumptions about request lifecycle, than they would have spent writing the boring thing themselves. The framework didn’t save them work. It deferred the work and charged interest.

This is the heart of our preference. A purpose-built tool makes fewer assumptions about your problem, which means fewer of them are wrong.

Where we actually draw the line

The honest version of this philosophy includes admitting when the big tool wins — because sometimes it clearly does. Here’s how we actually decide.

FastAPI over Django — most of the time, not always. A great deal of our work is lean services: AI middleware, integration layers, internal APIs. For these, FastAPI’s small surface area is exactly right. Our soc-integrator middleware — the piece that connects Wazuh to DFIR-IRIS to a SOAR platform to paging — is a focused FastAPI service precisely because it does one job and needs to be easy to reason about under incident pressure. But we’ll happily reach for Django when a project genuinely wants what Django is good at: the admin out of the box, mature ORM migrations, a content-heavy app with real users and sessions. The mistake isn’t using Django. The mistake is using it reflexively, then never touching half of it.

ERPNext over SAP for SME factories. When a manufacturing client needs an ERP, the instinct in the room is often to name the largest vendor. But for a small-to-mid factory, a heavyweight enterprise suite is mostly licensing cost and consultant dependency for capability they will never use. An open-source ERP they can host, customize, and actually own usually delivers more working software per baht. The total cost of ownership story — implementation, hosting, training, year-two support — almost always favors the leaner choice at this scale.

pgvector over a dedicated vector database. Retrieval-augmented systems have a fashionable answer: stand up a specialized vector store. For most of what we build, that’s a second piece of infrastructure to operate, secure, back up, and keep in sync — to solve a problem the database we already run can handle. Storing embeddings in Postgres next to the rest of the data, and combining semantic search with lexical search in one engine, means one system to reason about instead of two. We reach for the specialized store only when scale genuinely demands it, which is far less often than the hype implies.

Open-source security tooling over enterprise SIEM. Building a SOC stack on Wazuh and OpenSearch instead of a six-figure commercial SIEM isn’t a budget compromise. It’s the same principle: tools we can inspect, version, and shape to the client’s actual detection needs, without a per-gigabyte licensing meter changing our architecture decisions for us.

Notice the pattern. In each case the question isn’t "what’s the most capable tool?" It’s "what’s the smallest tool whose capabilities match this problem, that we can fully own?"

The compounding cost of surface area

Every tool you adopt is a liability you carry for the life of the system. It needs patching. It has CVEs. It has a learning curve for the next engineer. It has an upgrade path that will eventually break. It has opinions that will eventually collide with a requirement.

A small stack isn’t just easier to build — it’s dramatically cheaper to keep alive. Three years in, the project with four well-understood components is healthy and the project with fourteen is a maintenance tax that nobody wants to own. We optimize for that third year, because for our clients, that third year is where the software either earns its keep or quietly becomes the thing everyone’s afraid to touch.

There’s also a hiring dimension. A lean stack of widely-known tools means the next engineer — ours or the client’s — is productive in days, not months. Esoteric frameworks create esoteric dependencies on the specific people who understand them. Boring tools keep the bus factor healthy.

When we don’t do this

This philosophy has a failure mode, and we’d be selling you something if we pretended otherwise.

Taken too far, "lean" becomes reinventing wheels. If we wrote our own auth, our own ORM, our own migration system, and our own admin every time, we’d be building a worse framework one custom line at a time — and paying the surface-area cost we claimed to be avoiding, just privately. The whole point of a framework is that some problems genuinely are average, and for those, the shared, battle-tested solution is the lean choice.

So the rule isn’t "small tools always." It’s "match the tool to the problem, and be honest about which problems are actually standard." A login system is a standard problem; use the proven thing. A bespoke integration between a client’s legacy machine controller and a modern ERP is not a standard problem; no framework is going to hand you that, and pretending one will just adds a layer between you and the work.

The discipline is in telling the two apart — and in being willing to delete a tool when the assumption that justified it stops being true.

The takeaway

Boring, purpose-built tools aren’t a constraint we tolerate. They’re a competitive advantage we’ve chosen on purpose. They make systems we can reason about, ship faster, hand off cleanly, and keep alive cheaply for years.

The next time someone in a kickoff proposes the big framework, the right question isn’t "can it do this?" Almost anything can do almost anything. The right question is "what will it cost us to live with this for the next three years?" More often than you’d think, the answer is: more than the boring tool would have.

That’s the bet we keep making. So far, the third year keeps proving us right.