But will you make it better later?
Commit to flexible code and planned iteration to prevent costly technical debt
If you spend much time on LinkedIn, you've probably seen this meme: three progressively cleaner and more refined SpaceX Raptor engines set side by side, with the caption: "Just make it exist first. You can make it good later."
It's the tech version of Nike's Just Do It. The message is simple: stop waffling, stop waiting for the perfect moment, just start building.
As creative advice for the frequently stuck, this holds. Most successful things come from rolled-up sleeves: people who got to work, getting messy and taking wrong turns, until sooner or later the thing became the thing it was meant to be.
But software engineering? Not so much.
That’s because most software engineering teams aren’t usually experimenting and iterating deliberately—they’re just on fire with demands from management or customers or investors, moving as fast as they can to build a minimum viable product (MVP) to bring to market.
Often, that MVP ends up being a Potemkin village—a slick front end hiding an entanglement of sloppy, buggy, inflexible, and often unscalable Hail Mary code behind it.
To be clear, there’s nothing wrong with focusing on getting an MVP out the door. It shows progress to investors, and, at least theoretically, starts generating revenue to fund the next iteration.
But problems arise when a team uses the MVP rush as a reason to write rigid, brittle, “good enough for now” code. The profit is all up front: a marginal gain in short-term development speed that’s paid for by years of fighting with the codebase on subsequent iterations.
It’s not difficult (as it’s often assumed to be) to build an MVP both quickly and thoughtfully—writing flexible code using well-established architectural patterns that make future iterations faster and more resilient.
Management will sometimes levy a derogatory overengineering! at this suggestion during initial development, then return later irritated at the number of bugs the dev team is mired in when they should be building new features for 2.0.
The difference between the team that iterates successfully, improving its product with each round, and the team that gets stuck on its back foot, amassing out-of-control technical debt, is a simple three-legged stool.
Intention
Has your team agreed that flexible code architecture and planned iteration is a key component of good development, or do you have team members or management that waves this phase off as a “nice to have, but…?” Does your software development plan have iteration baked in as a well-defined step in the process, or is it incidental—only addressed when someone brings it up or something breaks?
Commitment
Even when faced with tough deadlines and a full pipeline, does your team hold the line on iteration, or waver and cut corners when the heat is on? Commitment looks like “if code standards are compromised, PRs are never accepted” or “no matter what, we focus only on code cleanup every Friday” vs. “we’ll get to this sometime later/if time allows.”
Execution
When it comes time for the iteration round you’ve defined and committed to, how does your team handle fixes and improvements? Using best practices, refactoring when necessary? Or as a box to check, a phase to get through as fast as possible with bandaids and paper clips and crossed fingers?
Coming back around to the Raptor meme, SpaceX built over 150 of its Raptor 1 engines, but never flew one on an orbital mission. They intentionally test to failure, never rushing an unfinished engine into a real-world flight and called it “good enough for now.”
They built something testable, and baked regimented iteration into the development process from day one.
So, like all memes that feel universal, the details matter. "Make it good later" only works if everyone knows and commits to when later is, and agrees on what the process of making it good really looks like in action.
Like financial debt, the compounding costs of technical debt won't wait for you to be “ready.”
Interest compounds on financial debt. Friction and fragility compound on technical debt. In both cases, the balance grows unchecked if you don't pay it down on a regular schedule. Or sufficiently.
Your team doesn’t have to be perfect. Every team takes shortcuts under tight deadlines, and in tech, we’re almost always on tight deadlines. But the teams that get stuck with ballooning technical debt are the ones who took out a risky loan on time and never returned to pay the balance.
When I say it’s easier to budget iteration time than it is to try to pay off that big debt balance in arrears, I’m speaking from experience. An all-too-common example:
A SaaS company's authentication logic is built fast under pressure. Normal at startup stage. The company gets the attention of enterprise customers, who then start demanding SSO.
Of course management wants it shipped right away, so the dev team builds it on top of the existing auth core, which has thin test coverage and a house-of-cards complexity. But hey, it works, so everyone's happy. Customers stop juggling separate logins, tickets slow down, the on-hold-for-SSO deals close. Traffic starts to climb.
Then suddenly, the growing traffic starts exposing edge cases nobody understood were now set like concrete into the auth layer. The same enterprise customers who just signed on get frustrated. Engineering ships a hotfix, then another, then a third. Each of those is a patch on the SSO layer instead of a fix to the actual problem underneath, because there's never time budgeted to do a true fix.
Things eventually calm down and customers are mostly satisfied. But trust in the product took a hit. That creates a restlessness in the customer roster that can’t (at least not yet) be tracked on a dashboard.
Management walks away thinking SSO shipped cheap and fast. Meanwhile, nobody adds up the real bill:
Support time absorbing the fallout
Engineering's context-switching and cognitive load—fracturing focus and slowing down planned feature development
Repeated short-term patches, creating a Jenga-like effect
Time spent on hotfixes surpasses time required to fix the auth layer
Account reps and managers pulled into firefighting instead of doing their own jobs
Damaged customer trust, and the drop in LTV (lifetime value) that follows
No one sees that list, so no one learns from it. The same pattern repeats on the next feature, and the one after that. And the twelve after that.
Sometimes the hard way is the easy way.
Notion's first version launched in 2015 with faulty architecture. It crashed constantly, lost user data, and confused pretty much everyone.
Rather than take the typical patch-and-pray approach most startups lean on, the founders fired the entire team and threw out just about all of the code. Then they holed up in a Kyoto apartment and spent a year rebuilding Notion from scratch.
That's the antithesis of "ship fast, fix later.” It's also in part why Notion rocketed forward to become a $10 billion dollar company in ten years instead of just another name on a very long list of startups that failed, sold themselves off in pieces, or are still limping along with high turnover and low adoption.
Good news: most companies don't need a Kyoto apartment or even a total rebuild. They only need that three-legged stool: intention, commitment, and execution.
If you're a founder or a decision-maker and something in the SSO story sounded familiar, it's worth asking yourself this question:
Do you know what your technical debt is actually costing you? I mean in support hours, in engineering time, in deals that stalled after a bad first impression? Or is it still an abstract anxiety you’ve been too afraid to put a number on?
Industry surveys, like these from Stripe and Sonar, have found that engineers spend anywhere from about 30% to a whopping 43% of their time dealing with the downstream effects of bad code and technical debt.
Is that “make it good later” tax included in your development budget?
"Make it exist first" is only good advice if “make it good later” comes with intention, commitment, and execution—not just hopes and dreams.
If you're not sure where your team stands with technical debt, it's worth a second set of eyes before the balance grows any bigger.