FindCamp: built in one day, because the clock was the point
It was International Women's Day 2026. Lovable was running a 24-hour hackathon called SheBuilds. I had one day and no real plan going in.
The problem I kept thinking about was one I'd watched play out every spring in my mom groups. Parents scrambling for summer camp spots. The good ones fill in February. By March, people are panicking in Facebook threads, asking strangers for recommendations, copy-pasting email templates to half a dozen camps. The information is out there. The timing is just brutal, and the whole thing is scattered across a hundred different websites.
So I built FindCamp. You type in your postal code, your kid's age, and what type of camp you're looking for. It finds options near you, sends results to your inbox with ready-to-send enquiry emails, and attaches calendar reminders for when registration opens. I built the whole thing in one day.
Google tells you about camps. FindCamp tells you when to show up.
Where the design came from
I didn't write a spec. Before I wrote a single line of code, I started talking through the problem with Claude, and the first conversation wasn't really about the product at all. It was about what the actual problem was. Is it finding camps, or is it registering before spots close? Those are not the same problem. Finding camps is a search problem. Registering in time is a timing and reminder problem. I kept coming back to this because if I picked the wrong one to solve, the whole thing would feel slightly off even if it worked. I decided FindCamp needed to do both or it wasn't actually solving anything.
The calendar attachment wasn't my idea, it was Claude's. I was thinking about reminder emails. Claude pointed out that a calendar file drops directly into someone's phone calendar, so the reminder is already there with one tap. That's just better than an email they have to do something with. So I changed the design.
What I cut, and what I protected
I had one day, which meant saying no to most things. I cut user accounts entirely because sign-in was friction I couldn't afford. Email is the session. You search, you get results, you're done. I cut every camp-side feature: listing management, claim-your-camp flows, operator analytics. The only users that mattered on day one were parents trying to find something.
The one feature I protected was the reminders, because that was the thing that made FindCamp different from Googling.
The rate limiting was non-negotiable too. Claude's web search tool is expensive at scale, so I capped it at three searches per IP and fifty per day. During the demo period a few people shared the link and I got a small burst of searches, and the cap held. Without it I would have had a real API bill to explain, and there is no graceful way to explain that.
The trade-offs I made
The AI layer is the Claude API with the web search tool. I considered building a scraper instead, but scraping camp websites is brittle and expensive to maintain, while Claude with web search does the research in real time and formats it. The backend is FastAPI on Railway because I knew FastAPI and Railway has one-click deploys. Email is Resend, and the calendar attachments worked out of the box. The frontend is React with TypeScript, because I wanted the project to look like something I'd put in front of a hiring manager, not just a proof of concept.
The biggest trade-off across the whole project was depth versus breadth, and I went broad. Real app, real domain, real email delivery, real calendar attachments. The cost was that none of it is production-hardened. SQLite can't scale, Railway costs money, and Claude's web search occasionally misses things. But it shipped, it's live, and it was built in a day.
What I learnt
The calendar attachment got the most positive feedback from the parents who tried it. One person said it was exactly what they'd been looking for. Another shared it in their parent group. That told me the reminder feature was the right one to protect.
What I underestimated was data quality. Claude's search is good, but it was surfacing 2025 camp data for a 2026 season, so registration dates and costs were estimates at best. I added a disclaimer to the results email, but it's a real limitation, and solving it properly means either getting camps to verify their own listings or building a refresh pipeline. Neither of those is a one-day job.
Coming back to monetization: the path was always weak and I knew it. Getting camps as customers is a completely different motion from getting parents as users, and the signal wasn't there. FindCamp stays alive as an AI showcase, not a business, and I'm okay with that.
The thing I'd actually show in an interview isn't the product. It's the process. A real problem, a working tool, real AI at the core, cost controls built in from the start, and real users who tried it. That's the part that matters.