DEV Community

Cover image for When Jeremy Clarkson Describes How My SaaS Dream Turned into a Circus of Despair
Hatem Zidi
Hatem Zidi

Posted on • Originally published at blog.hatemzidi.com

When Jeremy Clarkson Describes How My SaaS Dream Turned into a Circus of Despair

Imagine, if you will, that building a SaaS application is like constructing the perfect sports car. Sleek, powerful, a marvel of engineering.

I, of course, am Jeremy Clarkson in this scenario — the architect with the vision, the genius behind the wheel. My engineers? Well, they’re supposed to be the pit crew, precision-tuned experts ready to make my dream a reality.

But no. What I got instead felt more like a group of toddlers trying to assemble IKEA furniture after a bottle of tequila.

Jeremy Clarkson - Oh no!

The Stubborn Mechanic

We’re in the early stages, sketching out the blueprint. I say, "We need a modular architecture, scalable microservices, a clean API design."

What do I get? "Nah, monolith is better. Easier to debug. Why change what’s not broken?"

This guy would probably argue that a horse and cart is more reliable than a Bugatti because, “At least you can feed it hay.” Every suggestion, every adjustment, turned into a battle. It was like trying to convince a brick wall to embrace cloud-native. The wall refused.

Messy Workshop Culture

Then there was the team vibe — or lack thereof. Code reviews? Optional. Deadlines? More like suggestions. Testing? "Yeah, I clicked it, and it works, so we’re good."

It was like a garage where every spanner was lost, every engine part scattered across the floor, and someone thought a hammer was a perfectly acceptable tool for fine-tuning.

Hard Skills? Hard Pass.
Now, I’m no snob, but when your backend engineer says, "What’s Redis?" during a performance optimization meeting, alarm bells go off.

Imagine asking your mechanic about turbochargers, and they respond with, "Turbo... what now? Never heard of her." At that point, you realize you're not driving innovation — you're babysitting incompetence.

The Language Barrier

And let’s talk communication. I’d ask for asynchronous processing, and they’d come back with a while(true) loop in production. Asking for a RESTful API was apparently code for “build an RPC system no one asked for.”

It was like I was speaking Formula 1, and they were answering in caveman grunts.

Unclear Processes, Unclear Results

At one point, I said, "We need CI/CD pipelines." What I got was Jenkins running on a laptop under someone’s desk. No testing. No staging. Straight to production.

That’s not a pipeline. That’s a garden hose tied in knots.

Comfort Zone Enthusiasts

But the real kicker? Every time I suggested using a new framework or trying a more efficient method, the response was always the same: "This is how we’ve always done it."

This, dear reader, is like someone clinging to carburetors in an age of fuel injection, insisting it’s the only way because "real engines don’t need computers."

Diva in the Workshop

Then there was the Diva. You know the one. The “10x Engineer.” Every team has one — they swagger in, write cryptic code, and complain when anyone touches their sacred commits. When deadlines loomed, they were mysteriously “refactoring something critical”... like adding semicolons.

If the rest of the team was struggling to build a car, this guy was off in the corner building a unicycle because, "It’s more elegant."

How It Fell Apart

By the time we delivered the MVP, the only "V" was in "Very disappointing." The app ran slower than a caravan being towed uphill, half the features were missing, and the database schema looked like it had been designed by someone throwing darts at an ER diagram.

The trust was gone. So was my patience.

Lessons Learned

👉🏻 Soft skills > Hard skills: I can teach an engineer to code better, but I can’t teach them to stop being a pain in the exhaust pipe.

👉🏻 Processes matter: If your workshop is a mess, your car — or SaaS app — will be too.

👉🏻 Hire for the future: Comfort zones kill progress. If they can’t grow, they’ve got to go.

👉🏻 Kill the ego: This isn’t a solo race. It’s a team sport.

So now, when I start a new project, I don’t just look for engineers who can write code. I look for ones who can take feedback, work with others, and get excited about solving problems together. Because if you can’t build trust, you can’t build anything.

And that, dear reader, is how I learned to ditch divas and rebuild a proper team. Now, if you’ll excuse me, I’ve got a SaaS supercar to design. 🏎️

Top comments (0)