---
title: My Biggest Mistake As a Startup Founder Was Writing Tests
description: 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..
image: https://blog.magicpod.com/hubfs/Blog%20Banner%20for%20Website%20Content%20(1)-1.png
---
[Skip to content](https://blog.magicpod.com/my-biggest-mistake-as-a-startup-founder-was-writing-tests#main-content)
[](https://testingpod-draft-43945886.hubspotpagebuilder.com/testingpoddraft)
This is a search field with an auto-suggest feature attached.
- There are no suggestions because the search field is empty.
[Visit MagicPod](https://magicpod.com/en/)
July 12, 2024
# My Biggest Mistake As a Startup Founder Was Writing Tests
Share: [linkedin-in icon](http://www.linkedin.com/shareArticle?mini=true&url=https://blog.magicpod.com/my-biggest-mistake-as-a-startup-founder-was-writing-tests) [Twitter icon](https://twitter.com/intent/tweet?url=https://blog.magicpod.com/my-biggest-mistake-as-a-startup-founder-was-writing-tests)
-1.png)
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!
---
[MagicPod](https://magicpod.com/en/) is a no-code AI-driven test automation platform for testing mobile and web applications designed to speed up release cycles. Unlike traditional "record & playback" tools, MagicPod uses an AI self-healing mechanism. This means your test scripts are automatically updated when the application's UI changes, significantly reducing maintenance overhead and helping teams focus on development.
---
#### Written by [Jahdunsin Osho](https://www.linkedin.com/in/jahdunsin-osho/)
Founder and Tech Lead at Edubaloo, is passionate about providing affordable quality education for students across Africa. Prior to this, he worked at several startups, building scalable backend systems, developing consumer blockchain applications and core blockchain infrastructures. Impact-driven, Jahdunsin leverages his non-technical skills in SEO, copywriting, and paid advertising to ensure that the products he builds reach the target audience.
## Related posts
[.png?height=200&name=Testing%20Pod%20-%20Blog%20Header%20(23).png)](https://blog.magicpod.com/shift-left-testing-stop-bugs-from-reaching-production)
[Agile Testing](https://blog.magicpod.com/tag/agile-testing), [TDD](https://blog.magicpod.com/tag/tdd), [Testing Methodology](https://blog.magicpod.com/tag/testing-methodology)
## [Shift Left Testing: Stop 3x More Bugs From Reaching Production](https://blog.magicpod.com/shift-left-testing-stop-bugs-from-reaching-production)
February 19, 2025
[](https://blog.magicpod.com/manual-vs-automation-testing-strategy-for-stable-releases)
[Test Automation](https://blog.magicpod.com/tag/test-automation), [Manual Testing](https://blog.magicpod.com/tag/manual-testing), [thought piece](https://blog.magicpod.com/tag/thought-piece)
## [Manual vs Automated Testing: Our Strategy for Stable Bi-Weekly Releases](https://blog.magicpod.com/manual-vs-automation-testing-strategy-for-stable-releases)
October 18, 2024
[.png?height=200&name=Testing%20Pod%20-%20Blog%20Header%20(20).png)](https://blog.magicpod.com/places-add-ai-ci-cd-pipeline-ship-faster)
[AI](https://blog.magicpod.com/tag/ai), [CI/CD](https://blog.magicpod.com/tag/ci-cd)
## [4 Places to Add AI in Your CI/CD Pipeline to Ship Faster](https://blog.magicpod.com/places-add-ai-ci-cd-pipeline-ship-faster)
January 15, 2025
## Popular posts
### [.png) Facing 2025: How to future-proof your QA career in an AI-driven world](https://blog.magicpod.com/future-proof-qa-career-ai-driven-world)
December 31, 2024
### [-3.png) Automating Accessibility Testing in Your CI/CD Pipelines with Axe](https://blog.magicpod.com/automating-accessibility-testing-in-your-ci/cd-pipelines-with-axe)
October 29, 2024
### [ 5 Java libraries to 10X your Test Data Management](https://blog.magicpod.com/5-java-libraries-to-10x-your-test-data-management)
July 03, 2024
### [ Crafting a Comprehensive User Acceptance Test (UAT) Report](https://blog.magicpod.com/crafting-a-comprehensive-user-acceptance-test-uat-report)
February 12, 2024
### [ 7 Key Playwright Techniques to Eliminate Test Flakiness and Boost Reliability](https://blog.magicpod.com/7-key-playwright-techniques-to-eliminate-test-flakiness-and-boost-reliability)
September 25, 2024
### [ Context-Aware Test Automation with LLMs: Keeping Regression Tests Aligned with Requirement Changes](https://blog.magicpod.com/context-aware-test-automation-with-llms-keeping-regression-tests-aligned-with-requirement-changes)
October 03, 2025
### Subscribe to stay updated!
### Follow for updates
[linkedin-in icon](https://www.linkedin.com/showcase/testingpod/) [X Twitter icon](https://twitter.com/testing_pod)
[](https://blog.magicpod.com/)
Brought to you by AI test automation platform MagicPod.
[Visit MagicPod](https://magicpod.com/en/)
© MagicPod Inc.
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Jahdunsin Osho",
"url" : "https://blog.magicpod.com/author/jahdunsin-osho"
},
"dateModified" : "2024-08-23T22:25:54.926Z",
"datePublished" : "2024-07-12T14:08:47.000Z",
"headline" : "My Biggest Mistake As a Startup Founder Was Writing Tests",
"image" : [ "https://blog.magicpod.com/hubfs/Blog%20Banner%20for%20Website%20Content%20(1)-1.png" ],
"mainEntityOfPage" : {
"@id" : "https://blog.magicpod.com/my-biggest-mistake-as-a-startup-founder-was-writing-tests",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject"
},
"name" : "MagicPod Inc."
}
}
```