Choosing to Wield the Hammer
When you have a hammer, every problem looks like a nail. As aphorisms go, I hear this one constantly. I have never heard it used in a positive context. Misusing tools evokes images of beating a screw into your deck with a hammer or sawing a bolt out of your motorcycle subframe. Inefficient, embarrassing, and dangerous. The three killers of careers and consultants. Over the last decade in software, I think we’ve elevated the wrong advice. We’ve been taught that reaching for the same hammer makes us lazy. But sometimes the right move is choosing your hammer deliberately and wielding it with mastery.
No Agent is an Island
At this point ‘premature optimization’ has reached low-effort meme status. Don’t create 20 Go microservices for your new startup, don’t manage your own Kubernetes cluster, don’t Terraform yourself into a corner. We all nod along. But here’s what we’ve missed: the new enemy isn’t premature optimization, it’s context loss. And there’s no faster way to lose context than distributing your systems. When you’re one person (or a small team), every additional service is another mental model to hold, another deployment to remember, another place where things can break silently. This holds even more true in the realm of agentic AI. When Claude or Cursor is helping you code, it needs context, and lots of it! A monolith means you can feed it one codebase, one set of patterns. Microservices? Now you’re explaining service boundaries, API contracts, and inter-service communication before you even get to the actual problem you’re solving.
Early in my career, I consulted for a small shop in Wisconsin, which gave me access to the inner workings of tech companies across healthcare, fitness, and print industries. But my greatest lesson came from a single engineer who rented a private office from us.
He built and ran waiting system software for major hospital systems—entirely solo, entirely in Grails. Occasionally he’d pay for a few of my hours when he needed help. I didn’t even know Groovy, but because everything lived in one coherent codebase, I could hold the entire system in my head. In just a few days, I implemented timed texts, sign-in links, and several other substantial features.
He was, by far, the most profitable solo developer I’ve ever encountered. One person, one framework, one mental model.
This was 2014. Today, a developer in his position would be tempted by serverless, vercel, and fixing whatever breaking change has been introduced in Next.js or React. Back then, the siren songs were different but equally distracting. He ignored all of it. He’d chosen his hammer and mastered it.
That engineer taught me something the industry blogs never mention: boring technology is a competitive advantage when you’re small.
For any new web project, I reach for Rails. Convention over configuration. Monolithic architecture. Ship fast, iterate faster. The framework gets out of my way and lets me focus on solving actual business problems instead of wiring together infrastructure.
Boring is powerful when you’re starting from zero. Running Rails’ built-in generators `rails generate scaffold, rails generate model` is faster than asking Claude to write equivalent code. You get a working CRUD app with database migrations, views, and routes in seconds. No prompt engineering required. You get the entire force of a community behind you and 20 years of AI training data. When you ask Claude or Cursor for help with Rails, it’s drawing from millions of Rails codebases, Stack Overflow threads, and blog posts spanning two decades. Compare that to the JavaScript ecosystem, where the ‘right way’ to handle routing changes every few years and half the training data points to deprecated patterns. You get 80% of the way with 20% of the effort. This leaves you with time and energy for what actually matters: understanding the business problem, modeling the domain correctly, and shipping features that solve real needs.
Handing Over the Keys to the Honda
The thing about consulting work that product engineers often miss: you’re not just building for yourself. You’re building for the team that takes over after you leave.
When I meet a new client or start a new project, I’m thinking about the handoff from day one. Can they hire Rails developers in their market? Will the next engineer understand the codebase in six months? Can a non-technical founder grasp what the system does without getting lost in microservices diagrams?
This is where boring technology becomes a business advantage. A Rails monolith with straightforward documentation is something a client can actually maintain. They can hire locally. They can onboard new developers quickly. They can understand the system well enough to make informed decisions about future development. If they’re feeling daring, they could even attempt to vibe code it.
Compare that to the handoff conversation when you’ve built a distributed system: “So you’ll need to maintain these seven microservices, understand their API contracts, monitor the message queue, manage the service mesh, reconfigure the hoozymcflozzy...” You’ve just guaranteed they’ll be calling you back at premium emergency rates. Not exactly a strong selling point.
As a one-person technical team, you can’t hide behind complexity. Your value is speed (shipping features fast) and clarity (making sure everyone understands what you built and why).
Speed comes from keeping your entire system in your head (and in your AI’s context window). When everything lives in one Rails app, I can trace a request from browser to database and back in seconds. More importantly, when I’m pair programming with Claude or Cursor, I can feed it the entire relevant codebase. One repo. One set of patterns. One mental model.
Every additional service fragments your attention and fragments your AI assistant’s understanding. Want to add user authentication? In a monolith, Claude sees the User model, the sessions controller, and the authentication logic all in one place. In a microservices setup, worst case you’re working across packages and system boundaries, best case, you’re working in a monorepo with so many files you’ll blow straight out of the context window.
You Get Some Clarity, and You Get Some Clarity, Everyone Gets Clarity
Clarity works both ways. A monolith is clear for me: one codebase, one mental model, one place where everything happens. It’s clear for stakeholders who need to understand what they’re paying for. And crucially, it’s clear for AI coding assistants that amplify my productivity.
When a client asks “where does the user registration flow happen?”, I can point to one file. When I ask Claude to add email verification, it can see the mailer setup, the User model validations, and the registration controller in a single session. No explaining service boundaries. No managing API contracts across repos. Just: “Here’s the codebase, here’s what I changed. Review plz, luv u.”
Every architectural decision is really a decision about where to spend your attention. Microservices distribute your computing across services. But more importantly, they distribute your mind across codebases, deployment pipelines, API contracts, and debugging sessions. When you’re one person, your attention is your scarcest resource. A monolith isn’t a compromise—it’s a deliberate choice to keep your cognitive load manageable and your AI assistance effective.
Choosing Your Hammer
DHH has made the architectural case for monoliths. I’m making the cognitive and pragmatic case. When you deliberately choose your hammer and master it, you’re not being lazy—you’re being strategic about the one resource you can’t scale: your attention (and trust me, I, along with the entire biohacking subreddit have tried).
Look, there’s a time for novelty. If you’re in the fundraising game, the right buzzwords can open doors. But once those doors close and you actually need to build something that works, makes money, and doesn’t page you when you’re skiing? Mastery wins. Every single time.
I’m not arguing monoliths work for everyone. Far from it. If you’re coordinating hundreds of engineers across dozens of teams, you need to work with your organization to map out your architecture. When your organization is so large that independent deployment cycles and team autonomy become more valuable than system coherence, split things up.
But here’s the thing: you’ll know when you hit that point. You won’t need an article to tell you. Your deploys will be taking hours. Your merge conflicts will be constant. Your team leads will get shifty and start weird skunkworks initiatives to break things up.
Most companies never reach that scale. And the ones that do often started with a monolith. GitHub ran on Rails for years before introducing microservices. Shopify still runs one of the largest Rails monoliths in existence. Basecamp (DHH’s company) serves millions of users on a monolith.
The real advantage isn’t that boring technology can’t scale, it’s that boring technology lets you scale with a smaller team. You don’t need a platform engineering group, a DevOps department, and a site reliability team when you’re running one well-architected Rails app.
So the next time someone warns you that when you have a hammer, every problem looks like a nail, you can smile and say: ‘Exactly. And I’ve gotten really good at driving nails.’