Software·43,989 discussions

What’s one tech decision you regret & what would you do differently now?

Tags: Google, Software, Web development

We have all made choices in tech that felt right at the time… until they didn’t.

Maybe it was picking the wrong framework, going with a vendor that underdelivered or even sticking with outdated tools for too long.

what’s one tech decision you’d take back if you could?

And more importantly, what did you learn from it that others should know?

Topic

Learned long ago.

In reply to What’s one tech decision you regret & what would you do differently now?

Don’t bother trying to “future proof” your PC or apps.

Once you get past that, you can save time and money.

future-proofing

In reply to Learned long ago.

Future-proofing sound great in theory, but in practice? It often overpaying today for features you may never fully use. tech changes so fast that trying to stay ahead can sometimes feel like running on a road that never stops.

Do you think there is a middle ground? maybe not full-on future-proofing but making decisions that are more adaptable? (like building systems that can grow with your needs rather than trying to predict them all upfront)

Was there a specific tech decision where trying to future-proof really backfired for you? Or was it more of a mind shift over time?

2 examples.

In reply to future-proofing

1. A company example: On a vehicle tracking system the system was scaled to handle about 1,000 times the actual client needs. Result: Costly product. Still sold but made it too easy for competitors to offer cheaper systems.
2. A private example: Bought the latest PC tech. It was outdated in a year as the market and technology accelerated. Lesson? Don’t chase the leader of the pack.

That’s a really valuable perspective

In reply to 2 examples.

Thanks for sharing both examples!

So true, overengineering can be just as risky as under-preparing. That vehicle tracking story hits home, sometimes scaling just in case creates an opening for leaner, smarter competitors. & that shiny-new-PC scenario? A classic trap (tech)! We think we are buying time but we are really buying into the hype curve.

Stands out here is the lesson beneath it all, chasing the best can cost more than it saves not just in money, but in flexibility.

In your experience, how do you now decide what is enough without going overboard? Do you use any specific principles or questions when evaluating whether to scale or upgrade?

Sorry.

In reply to That’s a really valuable perspective

But this is the “lessons learned” first hand. You learn such and then decide what to do next time.

“The Microservices Mirage: When Scaling Too Soon Slows You Down”

In reply to What’s one tech decision you regret & what would you do differently now?

One tech decision I’d take back involves over-engineering a system early on by embracing microservices architecture far too soon for a startup-scale project.

❌ The Decision
I helped design a backend system split into multiple microservices (auth, notifications, user profiles, analytics, etc.) before we had product-market fit or even five developers on the team.

At the time, it felt right—modular, scalable, future-proof. All the blog posts and conference talks were singing the praises of microservices. But in practice:

We spent more time managing inter-service communication, deployments, and failure points than building actual features.

Debugging was a nightmare—issues crossed service boundaries constantly.

Dev velocity tanked because even small changes required coordination across multiple services and repos.

✅ The Lesson
Premature optimization is not just about speed—it’s also about complexity.

Start simple. Monoliths aren’t bad when you’re still validating your product or have a small team. You can always refactor later, and it’s far easier to split a well-structured monolith than it is to untangle a web of services that were rushed into place.

[Author]

Replies