luisgomez
← Back to Thoughts

Overthinking vs. Shipping: When to Sweat the Details

· 3 min read ·
Career Opinion Process

We lost a big one.

Enterprise deal. Months of work. Then: “We went with someone else.”

The feedback? They needed features we could have built in two weeks. But we were still polishing our architecture diagram.

That was a wake-up call.

The Velocity Lesson

Speed matters. Sometimes more than quality.

At my company, we learned this the hard way. We had a process. We had standards. We had code reviews that took three rounds minimum.

We were building things “right.” But we weren’t building things fast.

And in the market we play in? Fast wins.

So we changed. Started shipping faster. First version, then iterate. Get it working, then make it better.

The results? We closed deals we would have lost before. Not because our code was better. Because we were there.

The Other Side

But here’s where it gets complicated.

Sometimes you need to over-engineer. Sometimes the polish is the product.

Building a UI component library? That needs attention to detail. Every state, every edge case, every accessibility consideration.

Building infrastructure that other devs will depend on? Yeah, you better think about that API design.

Building something that needs to scale? Architecture matters.

The question isn’t “always ship fast” or “always build perfect.”

It’s: What are you building, and what does it need?

My Framework

I think about it like this:

Ship fast, refine later when:

  • It’s a proof of concept or MVP
  • The client/stakeholder needs to see something working
  • The core functionality is still being validated
  • You can iterate without breaking existing users

Sweat the details when:

  • You’re building something others will depend on
  • The code will be maintained for years
  • Performance/scalability are actual requirements, not guesses
  • You’re creating public APIs or interfaces
  • Accessibility, security, or compliance matter

The Real Skill

Knowing which mode you’re in.

A junior dev thinks everything needs to be perfect. Every function, every abstraction, every edge case handled.

A senior dev asks: “What does this actually need? What’s the risk if it’s not perfect? Can we iterate?”

Sometimes the answer is: build it fast, ship it, fix it.

Sometimes the answer is: slow down, this needs to be right.

The judgment call is the skill.

What I Learned

  • Perfect is the enemy of shipped. If it’s not out there, it doesn’t matter how clean your code is.
  • But sloppy is the enemy of sustainable. If you can’t maintain it, you’ll pay later.
  • Context decides. A marketing site? Ship it. A payment system? Be careful.

The best developers I’ve worked with have this in common: they’re comfortable with “good enough for now” when the situation calls for it, and they’re obsessive about quality when it matters.

They’re not ideologues about process. They’re pragmatic about outcomes.

The Takeaway

Don’t ship garbage. But don’t let perfect be the enemy of done either.

Know when to iterate. Know when to polish. Know when to move fast.

And when you lose a deal because you were too slow? Remember that feeling.

Use it.

What’s your take on the speed vs. quality tradeoff? I’d love to hear how your team handles this. Drop me a message.