Simplicity Doesn't Sell (And I'm Tired of Being Called Lazy For It) | Josh Karamuth<br>Last month I got an email from a former client. You know the kind, the one that lands in your inbox and you just stare at it for a solid minute before opening it. This was the guy who, eighteen months ago, told me I was “taking the easy way out” and “not thinking at an enterprise scale.”

He wanted to know if I was available. Their microservices project had collapsed. Six figures down the drain. The team had scattered. And somewhere in that mess, my “lazy” monolithic proposal was sitting in an archived Slack channel like a ghost at a funeral.

I didn’t reply.

The Day I Got Fired for Suggesting SQLite

Let me tell you about the other one. The one that still makes me laugh, but not in a funny way.

A startup reached out. They needed an internal tool for their operations team. Total users: three. Not thirty. Not three hundred. Three human beings, all sitting in the same office, all doing roughly the same thing. A CRUD app with a couple of reports.

I suggested SQLite.

Zero configuration. Zero server processes. Backups are literally copying a file. It ships with Python. It’s been battle tested since before some of these microservices kids were born.

The email I got back was polite, I’ll give them that. “We’ve done our research and we feel PostgreSQL would be more appropriate for our scale. We don’t think you’re the right fit for this project.”

They did their research. On what, exactly? A Hacker News thread from 2017? Some Medium article with architecture diagrams that look like a circuit board exploded? Because anyone who’s actually built things knows SQLite could run that workload on a Raspberry Pi collecting dust in a drawer.

But here’s the thing. It wasn’t about the database.

Nobody Wants to Hear That Their Baby Is Ugly

When you sell simplicity, you’re not really selling a technical decision. You’re selling something much harder.

You’re telling someone their grand vision might be slightly ridiculous. That the architecture diagram they’ve been doodling on napkins for three months is overkill. That all those conference talks they watched about event sourcing and CQRS don’t actually apply to their CRUD app with four endpoints.

And people hate hearing that. I mean, I get it. It’s not fun. Nobody wants to be the person who builds the “simple” thing. They want to be the person who builds the “scalable” thing, even if scalable means scaling from zero users to still zero users but with more YAML files.

The client who called me lazy? He wasn’t making a technical decision. He was protecting an identity. He’d already sold his team on microservices. He’d already put it in pitch decks. He’d already told his investors they were using the same architecture as Netflix. Walking into a room and saying “actually, we’re gonna do a monolith” would have felt like failure.

So instead, he called me lazy. It’s easier to question someone’s work ethic than to question your own judgment.

What Simple Actually Costs

Here’s what I’ve learned after fifteen years of this. Simple is hard. Genuinely, truly, deeply hard.

Simple means making decisions. It means saying no to things. It means knowing which problems you’re actually going to have and which ones you’re just cosplaying. Anyone can spin up a Kubernetes cluster and deploy twelve services that talk to each other through a message queue. That’s just following tutorials. But staring at a problem until you can solve it with a single server and a database file? That takes real understanding.

The tragedy is that simplicity has a marketing problem. Complexity looks like competence. A giant architecture diagram with forty seven boxes and arrows looks impressive in a slide deck. A single box with “Django monolith” written on it does not. One of these gets you funded. The other gets you ghosted.

And when things go wrong, complexity has a built in excuse. “Of course it took eighteen months and still doesn’t work, we’re building something really sophisticated.” Meanwhile, the simple thing that would have shipped in six weeks never gets built because nobody had the courage to suggest it. Or they did suggest it, and they got called lazy.

The Part That Actually Hurts

I’m not just venting here. This genuinely bothers me because I’ve seen the pattern too many times to count.

Someone hires me for my experience. They pay good money for my opinion. And then when my opinion is “you don’t need all that,” they decide my experience must have expired. Like I hit some cognitive shelf life and now I’m just the old guy who doesn’t understand modern development.

The wild part is I do understand modern development. I’ve built microservices. I’ve deployed Kubernetes. I’ve debugged distributed tracing issues at 2 AM while questioning every life choice that led me there. That’s exactly why I’m suggesting the simpler thing. Not because I don’t know how to do the complex thing, but because I know exactly what it...