Spots4kids

About Spots4Kids

Spots4Kids helps parents find the good spots — the ones worth the drive on a Saturday morning. Playgrounds, forest trails, splash zones, cosy indoor hideouts for the rainy days: all mapped, reviewed, and rated by parents who have actually been there. It is not limited to Flanders, or even Belgium — the platform covers spots across Europe, so whether you are staying local for the weekend or taking the kids abroad, there is something nearby worth checking out.

The founder came to us with a working app already in hand. Using AI-assisted vibe coding tools — built largely with Google Gemini and Antigravity — he had gone from idea to a functioning React and Supabase app entirely on his own, without writing code by hand. He had designed the database, wired up the features, and had something real to show people.

But he had also hit a wall — the same wall almost every non-technical builder eventually hits with these tools.

Where vibe coding stops and engineering starts

AI coding tools are remarkably good at getting you to a working demo. They are far less good at the things that do not show up when you are clicking around an app yourself: what happens when ten thousand people use it instead of ten, what happens when two users edit the same review at once, what happens to the codebase after the fortieth feature gets bolted onto the first ten.

That was exactly the gap the founder had run into. The app worked — it was genuinely impressive for what one person had built without a dev background — but it was not stable. It was the kind of app that is great in a demo and unpredictable in the wild: edge cases the AI tooling had not been told to think about, growing harder to extend without something breaking elsewhere, no real safety net to catch problems before users did.

This is the part of the story we think is worth telling honestly, because it is becoming a familiar one. AI tools have genuinely closed a lot of the distance between an idea and a working app. But there is still a gap on the other side — between an app that works for you today in a demo, and one that works for everyone, reliably, indefinitely. That gap is structural and architectural, and it is exactly where we came in.

Bringing structure to AI-generated code

Rather than throwing out what existed, we kept the foundation the founder had already chosen — React and Supabase — and went through the codebase to give it the structure it was missing. In practice, that meant:

• Guidelines and guardrails for the AI itself. Instead of letting the tooling generate code however it saw fit, we defined clear conventions for data access, component structure, and state management so further AI-assisted changes would follow the architecture instead of working around it.
• Closing the gaps the demo never exposed. We went through the app scenario by scenario, hunting for inconsistencies and edge cases that only show up once real users start behaving unpredictably.
• A real safety net. Automated testing with Playwright, running through GitHub Actions on every change, so regressions get caught before they reach users.
• A proper deployment pipeline. Changes move through GitHub Actions into Railway — chosen deliberately over more expensive alternatives like Vercel to keep running costs sane for an independent founder.

None of this replaced the product the founder had designed. It made the difference between an app that demos well and one that is actually ready to carry real traffic, real reviews, and real families depending on it every weekend.