The Rule of Least Power: Why the Boring Technology Choice Usually Wins

TL;DR: When you’re picking a tool, a database, or a way of solving a problem, the option with the most features and the most flexibility isn’t automatically the right choice. The Rule of Least Power says: pick the least powerful tool that still gets the job done, because less powerful tools are easier to predict, debug, and hand off to the next person. Save the powerful, flexible tools for the rare cases that actually need them.

How it’s often done

Picture a mid-size product team building an internal admin dashboard. Support agents need to look up a customer, see their orders, and check which features they have access to. That’s it. A handful of screens, a handful of lookups.

The team kicks off a design meeting, and someone suggests: “What if we use GraphQL so the frontend can query exactly the fields it needs? And since some of this data is relational — customers, orders, feature flags — let’s put it in a graph database so we can traverse those relationships naturally.” Everyone nods. It sounds modern. It sounds like the kind of stack a “serious” engineering team would choose.

Six weeks later, they have: a GraphQL gateway, a resolver layer to map GraphQL types to underlying data, a graph database that nobody on the team had used in production before, a cache layer to paper over the graph database’s slower reads, and an auth service bolted on to handle field-level permissions. Here’s roughly what a single request has to travel through:

The request path for a simple admin dashboard, after “let’s use the powerful stack.”

For a dashboard that mostly needs “show me this customer and their last five orders,” that’s a lot of machinery.

Why the powerful choice backfires

None of these tools are bad. GraphQL is a genuinely good fit when you have many different clients (a mobile app, a web app, a partner API) that each need different slices of data, and you want to avoid over-fetching. Graph databases are great when your core problem really is “how are these things connected” — think fraud detection or social networks. The problem isn’t the tools. It’s that the team picked them for a problem that didn’t need that much power.

Here’s what “power” costs you, even when it works:

• Fewer people can debug it. When something breaks at 2am, whoever’s on call needs to understand GraphQL resolvers, graph query behavior, and a custom cache layer — not just “read a row from a table.”
• It’s harder to predict what a query will do. A flexible query language lets callers ask for almost anything, which means you can’t always tell in advance how expensive or slow a given request will be.
• Onboarding gets slower. A new hire who knows SQL can be useful on day two. A new hire needs real ramp-up time before they’re confident touching a graph database’s query language.
• You inherit complexity you didn’t need yet. Multiple new pieces of infrastructure, each with its own failure modes, for a problem that a single well-indexed table would have solved.

This is the trap: powerful tools feel like they’re buying you future flexibility. Often they’re just buying you today’s complexity, in exchange for flexibility you may never use.

A better way: the Rule of Least Power

The Rule of Least Power is an old idea from the early web standards world. The original version, from the W3C, was about web pages: use plain HTML if HTML can express what you need, use CSS if you need styling, and only reach for JavaScript when you genuinely need behavior that nothing simpler can provide. The reasoning was that less powerful languages are easier for other programs (like search engines and screen readers) to analyze and predict. A browser can look at a plain HTML link and know exactly what it does. It can’t do that with a chunk of arbitrary JavaScript.

That same logic applies far beyond web pages. When you’re choosing between two ways to solve a problem, the less “powerful” (less flexible, less expressive) option is usually easier for a human — or another piece of software — to reason about. A plain SQL query is easier to predict than a general-purpose scripting language bolted onto your data layer. A config file is easier to reason about than a plugin system that lets you write arbitrary code. A cron job is easier to operate than a distributed workflow engine, if a cron job can actually do what you need.

You can think of it as a trade-off between how much a tool can express and how predictable it stays while doing it:

The sweet spot isn’t “as powerful as possible” — it’s “just enough power, with predictability to spare.”

Back to the dashboard example: the better version of that project uses a REST endpoint (or even a couple of specific endpoints per screen) backed by Postgres, with normal indexed queries. No resolver layer. No graph traversal. No separate cache layer, because Postgres can serve these simple lookups fast enough on its own. It’s less flexible in the abstract — you can’t ask it arbitrary questions the way you can with GraphQL — but it does exactly what the dashboard needs, and any backend engineer on the team can read the code and understand it in five minutes.

The heuristic to apply when you’re picking a tool: ask “what’s the least powerful option that still solves this problem?” instead of “what’s the most capable option I could use?” Start there. Only move up in power when you hit a wall the simpler tool genuinely can’t get past.

When NOT to switch to the boring option

This isn’t a rule that says “always pick the simplest possible thing, full stop.” There are real situations where the more powerful tool is the right call, and forcing yourself into the boring option just relocates the pain instead of removing it.

Reach for the more powerful tool when:

• You have multiple, genuinely different consumers of the same data. If a mobile app, a web app, and a partner integration each need different slices of the same data, GraphQL’s flexibility starts paying for itself instead of costing you.
• The core problem really is the relationships. If your product’s central feature is “find connections between things” — fraud rings, recommendation networks, org charts several layers deep — a graph database isn’t overkill, it’s the right shape for the problem.
• You’ve already hit the wall. If your team has outgrown the simple tool and can point to specific, recurring pain it’s causing (not hypothetical future pain), that’s a real signal, not a guess.

The comparison between the two approaches usually isn’t “simple wins on every axis.” It’s a genuine trade-off:

The powerful stack wins on flexibility. The boring stack wins almost everywhere else — which is exactly why it should be the default, not the exception.

Notice that the powerful option does win somewhere: flexibility. That’s real, and for the right problem it matters more than anything else on the chart. The mistake isn’t using powerful tools. It’s reaching for them by default, before you’ve confirmed the problem actually needs that much power.

The takeaway

Next time you’re picking between a simple option and a flexible, powerful one, don’t ask “which one could handle more in theory.” Ask “which one is the least powerful tool that still solves the actual problem in front of me.” Boring, predictable, and easy to debug isn’t a compromise — for most problems, most of the time, it’s the win.