Find the public data nobody has cleaned, and sell it as a paid API

The data is free. The wrangling isn'tEvery developer who needs UK school holidays faces the same job: find each council's page, copy dates out of PDFs, notice Scotland does it differently, redo it every year, and hope nothing changed. An hour of a developer's time costs a business far more than £9. That's the whole pitch: you do the boring bit once, properly, and sell the result to everyone who'd otherwise do it badly themselves.

What developers actually pay for isn't the data. It's five things the raw files don't give them:

• One clean format. JSON, consistent names, the same shape every year.
• Reliability. It's there at 3am, it's fast, and it has a status page.
• Correctness they can trust. Checks, a changelog, and someone who fixes errors quickly.
• Docs. An OpenAPI page they can try in the browser and a quick-start that works first time.
• Continuity. It'll still exist next year. This is the one that makes or breaks you.

The worked example: ukcalUK bank holidays and working-day maths per nation, plus school holiday dates for 206 councils in Great Britain. Why that gap? GOV.UK's school term dates service ↗ only finds your council and sends you to its website. The free OpenHolidays API ↗ has school holidays for 36 countries but not the UK. And the cleanest national source turns out to be an energy dataset: NESO publishes a daily 0/1 school holiday flag per council, for forecasting electricity demand. Almost nobody outside energy knows it exists.

What it takes.

• Code is a third of the job. The code in this mission is an afternoon's build. Keeping the data correct and finding buyers is the ongoing work, every week, and it's what customers pay for.
• Free alternatives exist for half of it. Bank holidays are already free and accurate: GOV.UK publishes JSON, and Nager.Date ↗'s 2026 GB list matches GOV.UK's, including Scotland's one-off World Cup bank holiday. You can't charge for that bit alone. Your paid product has to be the part nobody serves well.
• Timeline. Plan for weeks of steady outreach before the first paying customer, and a few months before it covers more than your server. Small APIs grow steadily rather than overnight, and annual plans help when projects end.
• Accuracy is the product. If your API says a school is open and it isn't, someone's booking system is wrong, so the checks, the correction process and clear coverage notes in step 3 are part of the build.

The kitDownload the code (zip) and the kit (research checklist, dataset scorecard, licence checklist and re-use request, spec, pricing table, docs and changelog templates, messages, terms outline, ops checklist, routine, 30-day plan, prompts). Plus pricing-maths.csv, sources.csv, scoreboard.csv and the generated openapi.json.