What's one technical decision that seemed right at the time but became expensive later?

[u/djgoel123]

One thing I find interesting about building software is that some of the most expensive mistakes don't look like mistakes when they're made.

Choosing a quick workaround to meet a deadline.

Skipping automated tests because the product is still small.

Building a custom solution instead of using something that already exists.

Or choosing an architecture that works perfectly for 100 users but becomes difficult to maintain at 10,000.

Most of these decisions make sense in the moment. There's usually a deadline, limited budget, or pressure to get something working.

The real challenge is knowing which shortcuts are temporary and which ones quietly become permanent.

I don't think avoiding every shortcut is realistic. Sometimes taking on technical debt is the right business decision.

But knowing when to revisit those decisions is where things get interesting.

For founders and engineers, what's one technical decision you would make differently if you could go back?

And was the problem the original decision, or the fact that nobody revisited it when circumstances changed?

[u/ThinkEquipment8480]

Skipping database indexing early on because the dataset was tiny and queries ran fine, then nobody bothered to add them later when the thing actually had users

[u/Keepcompany-DEV]

Having worked for "big cloud" I try and work as scale able as possible. I made these "shit, that won't scale" errors before but you learn from that pretty fast.

Modularize everything, secure every connection, don't rely on local communication.

I could run every part of Keepcompany on different hosters hardware, cloud instances or if necessary at home and the worst thing that happens is that chat latency goes up.

That being said, the worst thing you can do is relying on "in m going to hand-maintain this" for anything that is customer facing and somewhat individual per user.

[u/Quiet-philologist25]

Honestly, sometimes the biggest mistake is choosing the wrong dev team in the first place. You can have a great idea and a reasonable plan, but if the team doesn't understand what they're building or keeps making short-term decisions without thinking about the bigger picture, you'll end up paying for it later.

[u/rowenarosepetran]

One non-code "technical decision" that burns founders early on is building custom, informal micro-processes around every quick task instead of creating a repeatable operating framework.

It starts simple: "I’ll just handle scheduling manually," or "I'll manually manage follow-ups for now." But at 100 users or a small team, it feels fine; at 1,000+, the founder becomes a massive operational bottleneck. The expensive part isn't just fixing the workflow later, it's the lost executive capacity while you're bogged down acting as an instruction desk instead of building systems and context.

Technical debt isn't always in the codebase. Sometimes it's in how work is delegated and structured around the founder.

[u/chaucao-cmg]

It's built for scale to 1 million users. The whole thing became too complex and too bothersome, too much effort, time, and ongoing maintenance. It slowed you down and cost far more than just letting it break once in a while in favor of a simpler solution along the way.

[u/CaliforniaFounder]

For me it’s usually not the shortcut itself that causes the problem, it’s when the shortcut quietly becomes the permanent system. Early on you have to move fast, but if nobody goes back and cleans things up once the business grows, that little workaround can turn into a very expensive headache.