My Biggest Mistake As a Startup Founder Was Writing Tests

One year of potential revenue down the drain all because I was addicted to testing. For a bootstrapped startup that’s already running on lean funds, even an extra month without revenue could be terminal.

And like every addiction, you’d probably not realize it or, even worse, be in denial when confronted about it. In fact, if you’re reading this, you might already be addicted.

So, what exactly is testing addiction?

Break from the addiction that is testing.

Testing addiction is when you write just for the sake of it. It's when you write tests simply for due diligence without really considering whether it improves your project's quality.

It might result from blindly following software development methodologies without considering your unique use case or team or, in other cases, from trying to outperform a competitor.

In my case, it was both.

Before launching my edTech startup, Edubaloo, I worked in the blockchain industry, where testing wasn’t a negotiation. When you’re dealing with billions of dollars in assets, you better test that code.

Also, my startup had established competitors, and I wanted to one-up them with a better and more reliable product, so like every perfectionist, I tested everything.

The result? It delayed our revenue generation by almost an entire year!

I didn’t stop to consider the uniqueness of my team or the expectations of my customers. I should have asked, does my team have the bandwidth to write and maintain tests? Do my customers even need the product to be this reliable?

Without answering these questions when building a product, you also could slip into testing addiction.

Just like every human is unique, every team and project is also unique. After all, teams are made up of humans. So what works for one project or team might not work for another, even if both teams are trying to build the same product.

So, how do you determine what to test and what not to test? How do you avoid becoming addicted to testing?

My answer to the question is simple:

If it doesn’t make money, don’t test it

After burning through thousands of dollars without getting a dime back, I was forced to adopt a strategy I call “value-driven development” (The concept might already exist, chose not to find out; I’m taking credit; I deserve it).

The concept is simple: You don't test a feature if it doesn't have an impact on revenue or customer acquisition.

Here’s what I mean.

If you were building an exam preparation app, users might need to register to use the app and maybe bookmark questions they’d like to revise sometime later. Applying value-driven development means you test the registration feature and leave the bookmark feature untested.

Why? Because the registration feature impacts revenue. No registration means no new users or customers.

On the other hand, a user might not even use the bookmark feature until months after they've signed up. And it’s highly unlikely that users would abandon your product solely because they couldn’t bookmark a question right away.

Sure, it might be an inconvenience, but you could probably manage it with an apology and fix the issue when resources permit.

And if you’re thinking, isn’t this the same thing as critical path testing?

Maybe it is, maybe it isn’t. Either way, I’d stick with value-driven development. I can do it on the fly as I build. All I need is one one question: ”Does this impact our revenue?”.

I'll leave mapping out critical paths to testers in large companies.

But what happens when things break? What do you do?

Wrong question! The correct question is, do things have to break?

Prevent Bugs Before They Exist

As the adage goes, “Prevention is better than cure”. Testing wouldn't be necessary if bugs weren't a possibility in the first place.

To decrease the chances of bugs occurring in your product, these are development practices that I’ve found to work that you can start applying today.

1. Integrate Linting Into Your CI/CD Pipeline

   Depending on your development tool, you can integrate linting into your CI / CD pipeline, enforcing coding standards and catching potential errors before they get into production.

   For example, if you’re building with typescript, you can enforce a rule that prevents the use of the “any” type, forcing you to use more specific types.

   This reduces the risk of bugs resulting from runtime errors in production.

2. Optimize Code Review Processes

   Code reviews offer another opportunity to sniff out potential bugs. The problem is reviews can sometimes feel like a chore, especially when you’re pulled from your tasks to unblock another developer. There’s that temptation to just comment "LGTM", approve code changes and merge.

   We’ve all been there.

   If you’re in a managing position, though, you can streamline your review process by keeping pull requests small and encouraging developers to add comprehensive descriptions to their PRs.

   Descriptive pull requests add context for what to expect in the code, and keeping them small makes it easier to spot potential issues.

   Yes, developers aren’t known for their love of documentation, but with generative AI now easily accessible, creating descriptive pull requests should be a walk in the park.

3. Use Strongly Typed Languages

   I will never use vanilla javascript for a project I’d be shipping to paid users. In my experience, loosely typed languages like javascript are just an implicit type conversion away from a bug.

   I recommend using a strongly typed language, as it guards against type-related errors. Many issues would be caught at compile time rather than runtime, reducing the chances of crashes in production.

   You can do all of this and still get a broken feature in production. So, do you deal with those?

Dealing with broken features

Crash reports, seamless customer communication, logging and telemetry will become your best friends when you’re shipping fast.

By setting up robust logging and telemetry, you can be alerted as soon as a feature breaks, allowing you to make quick fixes even before a customer complains about it.

Monitoring crash reports is a must if you’re building a mobile app. By tracking your crash reports, you can identify what percentage of your users experience issues with your product and prioritize your bug fixes accordingly.

To prevent customers from coming to your home with pitchforks and torches, ensure that you have a medium of communicating with them. Your customers should be to report issues and receive prompt responses. Customers typically only become upset when they feel ignored.

By applying these strategies, you will build quickly without hurting revenue, handle broken features in production, and keep your users happy.

And to that, I say godspeed to you!