Move fast and break things—Facebook made it famous, but do you really want to break your product? Or… be like Zuck?
On the other hand, if you test every tiny feature before releasing it, you might be moving at the speed of a snail on sedatives. Early-stage founders often only care about speed and rapid feature development, but at what cost should this come? What’s the right approach here?
At madewithlove, we see it plenty of times during our technical due diligence: startups that sprint too fast and trip over their own bugs. However, there are also teams that are striving for the perfect bug-free technical solution with the ability to scale indefinitely instead of actually shipping.
Let’s find the sweet spot between reckless speed and paralyzing perfectionism.
The Myth of 100% test coverage
(Spoiler: it’s a trap)
Imagine you’re opening a new restaurant. Before the first customer walks in, you could meticulously test every single dish with an army of taste testers, perfecting each spice level. Or… you could just open the doors, see what people love, and adjust as you go.
Building software and products works the same way.
If you’re in the early stages, your biggest risk isn’t bugs—it’s irrelevance. Your job is to find product-market fit, and spending months writing tests for a product no one wants is a recipe for failure.
Reality check: Not every feature needs a test before it ships. Some ideas will flop. Some will change. Why waste time writing tests for code that might get thrown out next week?
Backend? Test the heck out of it. Frontend? Be strategic.
Backend code is predictable—it takes in data and spits out results. That makes it much easier to test. You can say, “When I input X, I should always get Y,” and write automated tests to catch mistakes.
Frontend, though? It’s more challenging: tests tend to be a lot more brittle.
Users don’t always behave how you expect. Designs change. Features evolve. Writing tests for every single UI tweak can slow down your ability to iterate and improve. That’s why the smart move is to prioritize critical paths—the actions that matter most to your business.
Example: If you’re running a SaaS platform for payments, your checkout flow needs rock-solid tests. However, writing a test for a dialogue interaction that might become a page later might not be the most important thing to do.
Manual testing isn’t evil (It’s even better sometimes)
“But what if something breaks?!” Don’t worry, we’re not saying you should YOLO your way into production. You just don’t need a test for everything.
Some features can be tested quickly and effectively by a human. Instead of writing a full suite of tests for a new sign-up flow, clicking through it manually and fixing obvious issues might be faster.
The rule of thumb:
- If a bug would destroy your business (e.g., user payments, security), test it properly.
- If a bug would just be annoying but not fatal, consider a mix of manual and automated testing.
- If a feature is experimental, test it minimally and refine as needed.
Can quality assurance replace manual testing?
No, it can’t. Manual testing is a part of quality assurance (QA). QA is the umbrella term for all kinds of testing strategies including automated/manual testing.
If you plan on relying on testing, make sure to do it extremely well. This is where being an ‘asshole tester’ comes in. You need to test like your worst customer. What if someone uploads a 100MB image instead of a profile picture? What if they copy-paste garbage data into every field? What happens if they smash buttons randomly? If your product breaks under these scenarios, your users will break it for you in production.
So, should you ship fast or test more?
Both. But in the right order.
The best approach is an intentional one. Prioritize business-critical flows, automate where it adds confidence, and leave room for exploratory testing. Good engineers don’t just write code—they think ahead about how users (and let’s be honest, how bad users) will interact with a product.
1️⃣ Early stage? Ship fast. Your priority is feedback, not perfect tests. 2️⃣ Scaling up? Test what matters. Identify critical flows and automate those. 3️⃣ Enterprise level? Build confidence. Invest in robust testing to avoid embarrassing failures at scale.
The biggest mistake SaaS founders make is treating testing as an all-or-nothing decision. It’s not.
Testing is a lever—knowing when to pull it is key.
Final thought: Quality is a choice, make it a smart one
Every company must choose where to invest time: more features, more tests, or somewhere in between. The real secret isn’t testing everything but aligning your team on what really matters.
Testing everything might feel like a safe bet, but in reality, it can slow down product development, delay valuable user feedback, and lead to an over-engineered product that no one wants. On the flip side, shipping too fast without safeguards can erode trust, introduce hidden failures, and cost far more in customer frustration and firefighting later on.
Rather than aiming for a mythical perfect testing strategy, strive for one that is adaptive. Testing should evolve as your product does, growing in complexity when necessary but never becoming an unnecessary bottleneck or getting in the way of growing your product.
So next time your engineers say, “We need more tests before we ship this,” ask why. Are they protecting a crucial part of your product, or just adding friction to an experiment?
At madewithlove, we help SaaS companies build digital products without drowning in unnecessary process. If you need to find the right balance between speed and quality, let’s talk.
Member discussion