u/NKFBF

Just shipped TourneyRadar after three months and I want to share some of the honest stuff about building it because most "I launched my side project" posts skip the parts that actually felt hard.

The idea was selfish.
I play chess. Finding a tournament to play in is annoying. Chess-Results.com has the data but you cannot search it like a normal person. So I built the thing I wanted: a world map of every upcoming tournament with filters for country, time control, and FIDE rating. The selfish-need filter is the best one for side projects because you know in advance if the thing is useful, because you are the user.

Three things that nearly killed it.

1. Scope creep, the silent killer.
   My original v1 had a map and a list. By week three I had convinced myself I also needed user accounts, a wishlist feature, an admin panel, push notifications, an organizer dashboard, an ICS export, and a Telegram bot. None of those were on the v1 spec. I lost a full month building accounts and a wishlist nobody asked for. Eventually I deleted the wishlist UI from the homepage entirely and shipped without it being a feature anyone sees. The lesson, which I have read 100 times and clearly did not internalize: the v1 is what gets you to launch, everything else is what you do after.

2. The data pipeline was harder than the app.
   I assumed scraping would be a weekend job. It took roughly six weeks of evening work to get to "scrape 140+ federations weekly without manual intervention." Things that ate time: language detection for tournament categories across 6 languages, geocoding venues that came in as just a city name, deduplicating tournaments that appear across multiple federation feeds, GitHub Actions timeouts on long Puppeteer runs, and Chromium binary caching to make CI fast enough to iterate on. If you are about to build a data product and you think the scraper is the easy part, double your estimate.

3. The "is this good enough to launch" cliff.
   Around month 2.5 the project worked but it had rough edges and I kept finding new ones. There is no end to that. What unblocked me was writing down five things that had to be true to launch (map renders cleanly on mobile, tournaments filter correctly, registration links open, /stats page does not crash, public API returns valid JSON), getting them green, and ignoring the rest. The 200-item polish list is still there. I will get to it. The site is up.

The stack.
Next.js 15, Supabase, Leaflet, Puppeteer, Vercel, GitHub Actions. All free tier except Google Maps geocoding which costs maybe two dollars a month at current scrape volume.

A few numbers.

- 140+ federation codes in scraper coverage
- 3 months from first commit to launch
- 4 regional matrix jobs running in parallel
- 7 minutes total scrape time
- 0 dollars in revenue, which is by design, it is free

What I would do differently next time.

- Write the v1 spec in a paragraph and physically not let myself add to it for the first month
- Build the data pipeline first, not last, because everything depends on it
- Pick a smaller initial scope for coverage (top 20 federations, not 140) and expand after launching
- Stop polishing earlier

Site: https://tourneyradar.com
OSS API for Devs: https://tourneyradar-api.vercel.app
Repo (MIT): https://github.com/AnayDhawan/tourneyradar

Would love to hear from anyone who has shipped a data-heavy side project. How did you handle the "scraper takes longer than the app" trap? Did you find users actually care about coverage or do they just want their region to work?