"The Mechanic's Car Won't Start"
I just spent weeks building something nobody wants.
Not because I can’t code. Not because AI led me astray. Because I ignored my own methodology.
Let me back up.
We build tools at PivotReady to help founders validate before they build.
SPARK walks you through structured validation — surveys, competitive analysis, market sizing. It’s designed to catch the “I think this is brilliant” trap before you waste months on it.
We use these tools with our clients. We watch them discover hard truths about their ideas. These tools are explicitly designed to save founders from dead ends.
So naturally, when I had my own “quick build” idea, I decided I didn’t need any of that.
The numbers looked promising.
I ran it through SPARK’s initial analysis. Market seemed viable. Problem seemed real. The surveys were queued up and ready to send.
But I was impatient (NOT a shock to anyone who knows me). I had AI tools. I knew how to code. This would be fast.
“I don’t need survey data,” I told myself. “I already know my customers.” “I want this product so I KNOW everyone else will – I AM THE CUSTOMER….”
Famous last words from every founder who’s ever built the wrong thing.
Three weeks later, I had a working product.
Clean code. Solid architecture. Fully tested and ready to GO!
Sales? Zero.
Not “slow adoption.” Not “needs more marketing.” Actual zero. Nobody cared.
Turns out, I didn’t know my customers. I didn’t know where to find them. I didn’t know if the problem I was solving actually mattered to them in the way I thought it did.
All the things the survey data would have told me.
Ever heard the joke about the mechanic whose car kept breaking down?
That’s me. I’m the mechanic.
I spent decades in tech leadership building products for companies. I know how requirements work. I know why validation matters. Aaron and I built PivotReady specifically to help founders avoid this exact mistake.
And I made it anyway.
Side note —- it seems I vaguely remember Aaron saying something like “I just kinda assume you engineer types are always working on some side project”. THAT too was ignored; but Aaron knows what we both do – sometimes all you can do is give the right advice and step back.
Here’s what I learned — again, the expensive way:
Speed is seductive when you have AI tools. You can build so fast now that it feels like you’re making progress just by shipping code. But fast in the wrong direction is worse than slow in the right direction.
Validation isn’t about pessimism. It’s about confidence. When you have real data, you build with conviction. When you skip it, you build with hope. If I had a dollar for every time I said — “hope is NOT a plan”.
Your own advice is the hardest to follow. We see clearly for others. We get foggy for ourselves. This is why methodologies exist — they work even when our judgment fails.
The real kicker?
I knew all of this. I preach it. I’ve watched founders nod along when I explain it.
But when it was my idea, my excitement, my “this will be fast” moment — I convinced myself I was different.
I wasn’t.
So here’s what I’m doing differently now:
Running my own ideas through the full process. No shortcuts. No “I already know” exceptions.
Validation
Competition Analysis
Customer Persona
ICE SCORING
Surveys
Feature prioritization based on DATA
Differentiation and Risks
Product Requirements
Marketing Requirements
Prototype to get hands on feedback
Treating survey data as required, not optional. If I’m not willing to validate it properly, I’m not willing to build it.
Remembering that methodology exists precisely for moments when we’re too close to see clearly.
The app I built? Still sitting there in GitHub. Perfectly functional. Completely useless.
It’s now my expensive reminder:
validation isn’t a nice-to-have. It’s the difference between building something people want and building something that just exists.
We’re builders at PivotReady. We use our own tools. We eat our own dog food.
And sometimes, we learn our own lessons the hard way.
Just like the founders we serve.