The Mental Budget Principle: Boring Tech Was Never Meant to Be a Personality
Somewhere along the line, “boring technology” stopped being a strategy and became a flex.
You know the type. The engineer who opens every design review with “we just use Postgres and a monolith” the way someone might announce they don’t own a television. It’s not a technical position anymore, it’s a signal of virtue. A way of saying “I’m smarter than you because I resist novelty.”
But here’s the thing Dan McKinley actually argued in his original essay: boring technology was never supposed to be an excuse to stop thinking. It was a framework for spending your mental budget wisely.
Somewhere in the last decade, that nuance got lost.
How “Boring Tech” Became a Thought-Skipping Technique
McKinley’s original premise was genuinely useful. His point was that every technology you adopt carries a cost beyond the license fee: you pay for it in attention, learning curve, operational complexity, and cognitive overhead. When you’ve already got fifteen tools in your stack, adding a sixteenth, no matter how shiny, spreads your team’s finite attention thinner.
That’s a real insight. Most teams genuinely do have a mental budget problem. The average platform team juggles Kubernetes, Terraform, CI/CD pipelines, observability stacks, and a dozen internal services. Every new tool competes for the same limited pool of mental energy that should be going toward understanding the actual product.
The SRE Platform Engineer job posting at Audiense actually gets this right. The role explicitly mentions “reducing the cognitive load of KTLO (Keeping The Lights On) by automating manual, human-run steps.” That’s the correct application of the mental budget principle: actively reclaiming cognitive resources so they can be spent where they matter.
But somewhere along the line, the principle got weaponized.
A Reddit thread in r/softwarearchitecture captured the frustration perfectly. One engineer described proposing a notification system with multiple specialized workers and Redis as coordinator, only to be told “just use Postgres + monolith” because the user count was still low. The counter-argument wasn’t about trade-offs, it was about identity. “We just use Postgres and a monolith” had become the architectural equivalent of a personality trait.
Reversibility Is the Real Metric
Here’s what both sides of that argument miss: the actual deciding factor isn’t whether your choice is “boring” or “exciting.” It’s whether it’s reversible.
One commenter in that same thread nailed it: “His decision is easy to revert while yours is not. It’s much harder to glue ten services together than it is to break one out. You have zero data to justify your decision, therefore we judge by the cost of changing our minds.”
That’s the mental budget principle applied correctly. The reason to start simple isn’t that simple is morally superior, it’s that simple decisions cost less to undo. A monolith with a clean modular structure can be extracted into services later. Ten microservices glued together with brittle contracts can’t be easily un-glued.
This is why cost-effectiveness matters. Using an in-memory table in an existing Postgres instance instead of paying for a Redis server isn’t being boring for its own sake, it’s acknowledging that infrastructure costs compound with complexity. One commenter pointed out that a Java monolith running with Postgres was handling over 300,000 requests per second at 10% CPU. The technology wasn’t the bottleneck.
The Cognitive Load Argument Has a Blind Spot
Here’s where the “boring tech” crowd gets it wrong. The mental budget argument cuts both ways.
Yes, adopting new technologies costs cognitive load. But so does not adopting them. When you force your team to work around the limitations of outdated tooling, you’re spending cognitive energy on workarounds instead of building. When your notification system uses a database as a queue because you refused to consider a purpose-built tool, you’re paying an ongoing tax in debugging time and performance headroom.
The framing shouldn’t be “boring vs. exciting.” It should be “where are we spending attention, and is it yielding returns?”
This is particularly relevant to the current AI agent landscape. The AI agent development cost guide from Primocys breaks down AI agent pricing by what the agent actually has to know, decide, and do, a workflow complexity ladder that maps directly onto the mental budget concept. A focused single-workflow agent might cost $8K, $18K, while a complex multi-agent system can exceed $60K. The difference isn’t the model API, it’s the surrounding software: state management, tool integration, permissions, evaluation.
The same logic applies internally. A simple architecture you understand completely beats a complex architecture you half-understand. But a complex architecture that genuinely solves a real problem beats a simple one that forces your team to work around its limitations every day.
The Smugness Trap: Risk Aversion Disguised as Wisdom
The most corrosive aspect of the boring-tech-as-personality phenomenon is how it polices thought itself.
When “just use Postgres and a monolith” becomes a reflexive response to any architectural proposal, you’re not making a decision, you’re avoiding one. You’re stating a preference and calling it analysis. And crucially, you’re shutting down the kind of intentional trade-off conversation the mental budget principle was meant to enable.
One commenter in that Reddit thread observed that in two decades of engineering, they’d encountered the “boring tech zealot” maybe once. Far more common is the opposite problem: teams that chase novelty for its own sake, abandoning solid choices for questionable alternatives because something is new. The irony is that both behaviors stem from the same failure, not actually thinking through trade-offs.
The boring tech zealot and the novelty chaser are mirror images. Neither is making a decision based on evidence, reversibility, or actual requirements. Both are substituting identity for analysis.
What Intentional Technology Selection Actually Looks Like
The mental budget principle, properly understood, is a decision-making framework, not a fashion statement. It asks three questions:
- What is this technology actually buying us? Not in theory, but for this specific system, with these specific requirements and constraints.
- What is it costing us? Including the cognitive load of operation, the learning curve for the team, the integration complexity with existing systems.
- Can we reverse this decision later? What’s the cost of changing our minds if things don’t work out?
The answers to these questions might lead you to Postgres and a monolith. Or they might lead you to Redis and multiple workers. The point is that you got there through analysis, not through reflex or rebellion.
This is where AI-assisted architecture review gets interesting. Instead of asking an AI to design a system for you (which tends to produce a Kafka cluster here, a Redis cache there), some teams are experimenting with using AI to challenge design assumptions and reduce cognitive overhead, treating the model as a Socratic interrogator rather than an architect. That’s the mental budget principle applied to tooling: offload the cognitive cost of second-guessing yourself to something that can grind through the options systematically.
Similarly, alternative inference paradigms are forcing AI engineers to reconsider assumptions about model architecture and cognitive load in their own systems. The question isn’t “what’s the most powerful model?” but “what’s the cheapest way to get acceptable performance without blowing up our operational complexity?”
Mental Budgeting in Practice: Concrete Moves
So how do you actually apply the mental budget principle without falling into the boredom-as-virtue trap?
Start with the constraint, not the technology. Define what you’re actually optimizing for, latency? Cost? Team velocity? Operational simplicity? The technology choice follows from the constraint, not the other way around.
Make the cost of changing your mind explicit. If you’re choosing a monolith, what’s the extraction plan? If you’re choosing microservices, what’s the contract design that keeps future changes cheap? The decision isn’t just what you build, it’s how hard it will be to rebuild.
Audit your team’s actual cognitive load. Where is your team spending mental energy that isn’t producing value? If it’s fighting tooling limitations, that’s a technology problem worth solving. If it’s drowning in unnecessary complexity, that’s a simplification problem. The fix isn’t the same in both cases.
Automate the boring parts. The Audiense job posting again: reducing KTLO cognitive load by automating manual steps. That’s spending automation budget to reclaim human attention. The same logic applies to AI-assisted development, autonomous agents that offload routine tasks effectively buy back cognitive budget for more valuable work.
Reject both orthodoxies. The “boring tech” crowd and the “shiny new thing” crowd are both wrong when they refuse to engage with actual requirements. The correct position is uncomfortable: you might end up choosing boring tech for exciting reasons, or novel tech for conservative reasons. What matters is that the reasoning is visible and defensible.
The Principle Survives the Misuse
The mental budget principle is too useful to let a bunch of smug design-review performances ruin it. The answer to “boring tech” being weaponized as thought-skipping isn’t to abandon the concept, it’s to reclaim it.
Use boring tech when it genuinely frees up mental budget for more important problems. Use novel tech when it genuinely solves a problem that boring tech can’t. And in all cases, make the reasoning explicit, document the trade-offs, and keep the cost of changing your mind visible.
The alternative, whether it’s reflexive conservatism or reflexive novelty, isn’t engineering. It’s cosplay.
This is the mental budget principle done right: allocating attention as deliberately as you allocate money, and refusing to let either fear or fashion make your architectural decisions for you.




