Today’s app release windows are crazy. Most products have 1-4 updates a month. Heck, some SaaS companies release every week.
The problem is, this endless-update cycle has popularized the idea that code is cheap and replaceable.
Worse, it’s fed the idea that you can build your initial product on the cheapest code possible and replace it later. And I totally disagree.
I call this the “we’ll rebuild it later” fallacy.
Think of a digital product like a house. You wouldn’t lay a foundation at the start of your build with the intention of replacing it once the rest of the house is finished, would you? No, that’s absolutely ridiculous. The same goes for building a product on cheap, low-quality code then replacing it later.
The point is, “build and replace” isn’t a viable option. It must be build, review, evolve. Because moden products are always evolving to meet their customers’ needs. Without foundation code that’s equipped to grow or pivot with your business, you’re setting yourself up to fail.
Bad code’s deadly long tail
Say you build a car. But instead of using nuts and bolts to attach the wheels, you weld every wheel to the axle.
So every time you need to replace a tyre, you need to break an entire piece off and weld it back on.
So, not only do you have to damage your car to replace a wheel, but it also takes longer and makes you late.
By the time you get around to replacing the tyre for the fourth or fifth time, the axle is in such bad shape that it’s faster, cheaper, and simpler just to tear the whole thing out and buy a new one.
It’s the same principle for bad product code. Once you’ve launched, and have paying customers, feature requests will flood in. And if you don‘t deliver, customers will find another product that can. The pressure is on.
But as you add more to your product, the more time you have to spend reworking your existing code.
Shitty day-one code means you amass technical debt that bites you in the arse down the line by…
…slowing every future update you push out.
…complicating every future product decision.
…limiting what your product can be.
…creating unexpected issues.
Inevitably, the problems will keep adding up until they’re unmanageable.
And when you’re a startup that might need to pivot on a dime, it’s the last thing you want to happen. Because agility is often your biggest advantage over the established companies you’re up against.
This isn’t just theoretical, I’ve seen it first hand…
At dazlab, we’ve inherited several cheap and nasty products and every single one has been painful for us and the founder.
Just imagine product code with no documentation, no structure, no unit tests, no code repository history, no code reviews info, no spec document, no design documents.
The products all work but the code is all over the place so we can’t support it. Adding new features is slow, complex, and expensive. Even minor changes are painful.
The founders feared that without a constant stream of promised features, customers would leave for a better product.
In most cases, to get the product up to scratch requires entirely new code.
And that’s a huge hit to take because founders have to pay for the entirely new code and it sets the release date for those new features back even further.
And I see the decision to build with bad code happen for two reasons:
- It’s a money decision. People think it’s best to build cheaply, then fix later when they have a working product.
- They don’t understand what they actually need. It’s a confusing market with diverging advice.
On the bright side, all of these products are now built on code that makes adapting and expanding so much easier.
Now, not every subpar product is so bad it needs a rebuild (even if some vendors will tell otherwise). As long as there’s the right documentation and structure most product code is, at least, salvageable.
But what’s better is to avoid bad code entirely by building your product on solid foundational code the first time. Here’s how.
The 2020 model for successful first-time product code
Successful product code in today’s product landscape needs to be wired for continuous improvement and adaptation.
1. Build for adaptability. Everything you build should be for the long term. Don’t look at anything as short term. If you don’t have a solid base to work from, you can’t build new products or features. Coding fundamentals that allow you to change and adapt must be thought about from the start of your build.
2. Be integration-ready. There are so many suppliers out there that you don’t need to build everything yourself — as long as you have the knowledge and code to integrate. 30% of your product might turn out to be integrations with platforms that can do something better than what you can develop — think of support products like Zendesk or data platforms like Google Analytics.
3. Build for testing and metrics. The only way you’ll know if your product is resonating with your audience is if you measure its effectiveness. And that means baking metrics into your product from the outset.
Build lasting products
If you take one thing away from this blog, take this: building any digital product with a long-term mindset will always serve you better. You’ll hit fewer roadblocks, adapt faster, and win more customers over. Long-term is the smartest way to build.
