When I started building INIDETO Wash, I made myself a promise. Before I ever asked a real customer to trust us with their car, I would try to break the platform myself, over and over, until I ran out of ways to do it.
So far, that number sits at 1,789 tests.
It Broke in the First 100
I won't pretend this was smooth. Under normal, predictable conditions, everything looked fine. It was the moment I started testing real-world pressure, timing, bad network conditions, multiple things happening at once, that cracks started showing up. Not in the first ten tests. Not in the first fifty. By the time I hit 100, I had a growing list of ways the system could quietly fail a real customer.
That's the part I want to be honest about. A platform that "just works" from day one usually means nobody has tested it hard enough yet. Ours works today because we found the cracks before our customers did, not because there weren't any.
What 1,789 Tests Actually Means
This wasn't me clicking around the site. It was a deliberate process, repeated across every part of the platform:
- Timing and concurrency. What happens when two things try to happen at the exact same moment. Systems that look fine one at a time often fall apart under simultaneous load.
- Payment integrity. Every payment path tested for what happens when something interrupts the normal flow, not just when everything goes right.
- Geographic coverage. Every zone, every combination of available and unavailable washers, tested for what a customer actually experiences when the ideal case doesn't hold.
- Real-time state. Whether what a customer sees on their screen actually matches what's true in the system, at every stage of a booking.
- Failure visibility. Whether problems get caught and flagged automatically, or whether they'd sit silently until a customer noticed first.
Each of these categories got tested, broken, rebuilt, and tested again. Some of them took a handful of tries to get right. Others took dozens of iterations before I was confident they'd hold up.
Why I'm Not Sharing the Specifics
I thought about writing this post with a detailed list of exactly what broke and exactly how we fixed it. I decided against it. The honest reason is that the more specific I get about the mechanics of past weaknesses, the more of a map I hand to anyone looking for new ones. That's not a risk I'm willing to take with customer data or payment flows just to make a blog post more impressive.
What I can tell you is that nothing here was cosmetic. These were structural fixes, the kind that change how the system behaves at its foundation, not just how it looks on the surface.
Why I'm Telling You Any of This
There's a version of this post that just says "our platform is reliable, trust us." I don't think that means much on its own. What I'd rather you know is that reliability here didn't come from getting it right the first time. It came from a habit: try to break it, watch closely when it breaks, understand the actual cause, fix that cause, then go try to break it again.
1,789 tests is not a finish line. It's just where the count is today.
I'll keep running them, because the day I stop looking for what's broken is the day something breaks that I don't catch first.
If you've booked with us and things went smoothly, that's not an accident. If you haven't booked with us yet, this is what's running underneath when you do.
INIDETO Wash. Built in Abuja, tested relentlessly, one broken thing at a time.