I’m a head chef running a busy kitchen by day, and an indie builder working on LocalPatron by night.
Instead of building features based on assumptions, I decided to use a real, high-volume local pizzeria (4.8/5 rating) as a live technical laboratory for LocalPatron.
Testing under real-world constraints forced me to solve technical problems that sandbox environments simply don't show:
Performance (100/100 PSI): Local business owners don't care about tech stacks—they care about instant load times on mobile. Optimizing for direct dynamic rendering brought PageSpeed Insights to 100 on both mobile and desktop.
Google API Quirk Handling: Automating hyper-local updates meant wrestling with undocumented edge cases in Google’s Business Profile API, including OAuth consent audit blocks and state parameter truncations.
Zero-Friction UX: Non-technical owners won't spend hours on complex dashboards. If value isn't obvious within 10 seconds of automated baseline setup, they abandon the tool.
Building in a high-stakes, real-world environment keeps the feedback loop ultra-tight.
For other solo makers: How are you validating your early-stage B2B technical assumptions before launching broadly?
This is exactly why I think testing against real workflows is more valuable than just checking whether the feature works.
The interesting failures usually happen around the edges: unexpected API states, repeated requests, authorization assumptions, missing tenant context, etc.
I've started treating “can this be made to behave incorrectly?” as a separate test category from “does the happy path work?”