Simplicity Doesn't Sell (And I'm Tired of Being Called Lazy For It)

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 costs.

Experience looks a lot like laziness from the outside. A junior developer will eagerly build whatever architecture you describe. A senior one will ask “but why though?” about twenty times until you either convince them or realize you can’t.

What I Actually Want to Say to Clients

If I could be brutally honest for a moment. The kind of honest that probably loses me more work, but honestly I’m tired of not saying it.

Your project is not special. I don’t mean that as an insult. I mean that the problems you’re solving are probably not unique. Other people have built similar things. The patterns are known. The tools exist. The edge cases you’re worried about are either real and manageable or imaginary and you’re just anxious. Either way, adding more moving parts doesn’t help.

When I suggest a monolith, I’m not being lazy. I’m being strategic. I’m trying to get you to market before your runway evaporates. I’m trying to make sure that when something breaks at 3 PM on a Friday, one person can find the bug in one codebase instead of three teams pointing fingers at each other for four hours.

When I suggest SQLite, I’m not incompetent. I’m saving you from managing a database server for three people. I’m making your backups trivial. I’m making your deploys a single binary. I’m giving you fewer things that can break.

But saying all that out loud sounds defensive. And nobody wants to hire defensive. So I just write the proposal, suggest the simple thing, and wait to see if I get the “we’ve decided to go in a different direction” email.

If This Is You Right Now

Maybe you’re the one trying to sell simplicity and getting nowhere. Or maybe you’re the one on the other side, evaluating someone’s proposal and wondering if they’re cutting corners.

If you’re the seller, I don’t have a magic answer. I keep doing it because I can’t not do it. I’ve tried just going along with whatever architecture the client wants and cashing the check. I can’t. It feels dishonest. I’d rather lose the work than pretend I believe in something I know is going to fail.

If you’re the buyer, here’s my one request. Next time someone suggests the simple thing, ask yourself why it bothers you. Is it genuinely the wrong call for your project? Or is it just not impressive enough? Are you worried it won’t work, or are you worried about what other people will think when they see your architecture diagram?

Because one of those is engineering. The other is insecurity. And insecurity is way more expensive than any cloud bill you’ll ever pay.

I’m still thinking about that email from my former client. The one with the collapsed microservices project. I didn’t reply, like I said. But I thought about it. I thought about the proposal I sent that he rejected. I thought about the months of extra work and stress and money his team burned through.

I didn’t feel vindicated. I just felt tired.