You've heard it. "Just go with X for now." "We'll improve it in the future." "Good enough for now." Sometimes it's because of deadlines. Sometimes requirements are fuzzy. Sometimes the team is small and you have to ship. Fair enough. You make a call, you ship, you move on.
The problem is when "we'll fix it later" becomes a line we say every quarter and never mean. At some point you have to ask: even with time pressure, what can we compromise on, and what can we not?
Some things you can compromise on
You can compromise on polish. The UI doesn't have to be perfect. The code doesn't have to be the cleanest version you can imagine. You can pick a library or a pattern that's "good enough" and get something out the door. You can defer refactoring if the current code works and the refactor isn't blocking anyone.
You can compromise on scope. You don't have to build for every edge case on day one. You can launch with a subset of features and learn. You can say "we're not supporting that use case yet" and see if it actually matters.
You can compromise on the ideal architecture. Maybe the dream is event-driven microservices, but right now a monolith or a few big services gets you there faster. You can live with that for a while as long as you're not painting yourself into a corner.
These are real tradeoffs. Time and context matter. "Good for now" is a valid answer when the alternative is not shipping or burning the team out.
Some things you shouldn't
You can't compromise on safety and security. If the system handles critical things that can cause real damage when it's wrong, "we'll fix it later" is not an excuse for skipping checks or ignoring known bugs. Some corners you don't cut.
You can't compromise on the kind of debt that never gets paid back. There's debt you take on knowingly — we're doing it this way now, we'll refactor when we have time. And there's debt that compounds: no tests, no way to deploy without fear, no ownership, no docs so that only one person knows how it works. The first kind is a tradeoff. The second kind is a time bomb. Once you're in that hole, "we'll improve it later" rarely happens because nobody wants to touch it.
You can't compromise on actually deciding. You still have to choose what matters for this project, this quarter, this team. Saying "we'll figure it out later" and then not making a call is just avoiding the work.
So what do you do?
You get clear on what's negotiable and what isn't. You name the tradeoff. "We're going with X for now because of Y. We're not doing Z yet. Here's what we're giving up and here's what we're protecting." When you say "good enough for now," you know what "for now" means — a quarter, a year, until we hit scale, whatever. And you actually put "improve this" on the list instead of pretending it'll happen by itself.
When someone asks "why don't we do it right?" the answer shouldn't be a shrug. The answer should be "we're trading X for Y because of Z, and here's when we'd revisit." That's a decision. Get that wrong, and "good enough for now" becomes "we never fixed it."