I've been building this solo for about 14 months and just went live last week.
What it is
StaticCreation is an API marketplace for UK public sector data. Instead of scraping Companies House, DVSA, Land Registry, EPC, and a dozen other sources separately, you get one API key that works across everything.
The problem I kept hitting
Every time I built something that needed UK data, I'd spend weeks writing scrapers, handling rate limits, parsing inconsistent formats, and maintaining pipelines that break every time a government site changes. I figured other devs were doing the same thing.
What's in there
- 1.2 billion records across 16 datasets
- Property: EPC certificates, Land Registry transactions, planning applications
- Vehicles: DVLA data, full MOT history (832m test records), MIB insurance checks
- Business: Companies House profiles, officers, charges, filings
- Plus: energy data, school/Ofsted ratings, crime stats, food data, fuel prices, trademarks, and more
How pricing works
Buy tokens once (starts at £1.50 for 100), spend them per call. No subscriptions, no separate plans per dataset. One balance works across every endpoint.
Combined intelligence endpoints
This is what I'm most proud of. Instead of calling 5 APIs yourself and joining the data, one call to Property Intelligence returns EPC + crime + schools + energy + price history for any UK address. Same idea for vehicles and companies.
The stack
FastAPI backend, PostgreSQL, self-hosted on dedicated hardware in the UK. All data runs through my own ETL pipelines — no reselling third-party APIs. 15 GB cloud storage included for every paying customer.
What I'd love feedback on
- Is the pricing model clear enough?
- Are there UK datasets you'd want that I'm missing?
- Would you actually use something like this?
Happy to answer any questions about the build, the data partnerships, or the tech behind it.
Top comments (7)
How do you normalize addresses and entities across different datasets?
Good question!
Each source gets normalised into a consistent schema before it's queryable.
For addresses, I've built a dedicated addresses layer that merges EPC, Land Registry, Companies House, and ONSPD data into one clean structure, cross-referenced by UPRN where available, and matched on postcode plus building identifiers where it isn't. The result is a single address record with full UPRN, coordinates, and metadata regardless of which source it originally came from.
For companies and vehicles it's simpler since Companies House gives every company a stable company number, and vehicles are keyed by registration number, so those stay consistent across every dataset that touches them.
On top of that, the combined intelligence endpoints do real-time entity matching across schemas. So when you query Property Intelligence for an address, it's pulling matched records from EPC, Land Registry, crime, and schools data and returning them as one joined response instead of five separate lookups.
Also worth mentioning, the platform includes a route optimiser that takes a list of stops, reorders them for the most efficient route, and if you pass in a vehicle registration it calculates fuel consumption and cost using live prices from over 8,000 UK stations, even auto-inserting a fuel stop if you're running low. Built entirely on top of the same normalised address and vehicle data.
If you want to see the address normalisation in action without signing up, head to the registration page and type any UK postcode into the address field. That autocomplete is hitting the exact same normalised data source the API serves.
That's a really clean approach. I imagine one of the biggest challenges is keeping all those ETL pipelines reliable as upstream schemas change. How are you handling schema evolution and monitoring? Is everything automated with validation and alerting, or do you still have some manual intervention?
Good question, and this is something I've put real thought into.
Everything runs automated through ETL pipelines under formal data agreements with each source. The data arrives clean and trusted, since these are official government and licensed partnerships, not scraped or best-effort feeds. Cadence varies by source, some refresh daily, some twice a day, and Companies House is kept near real-time so changes reflect in my database within minutes rather than waiting for a batch cycle.
If a provider changes their data structure, that's typically communicated in advance as part of the agreement, so I'm rarely caught off guard. On top of that, every pipeline has validation checks built in, expected field presence, row count sanity checks, format validation, before anything touches the database. If the structure doesn't match what's expected, or a pipeline fails outright, I get an instant alert and can investigate immediately.
End of the day, malformed data never reaches the database. It either passes validation or the pipeline halts before insertion.
That's a solid approach. Having validation gates before anything reaches the database is definitely the right way to handle large ingestion pipelines, especially when you're aggregating data from multiple providers.
I've worked on backend systems with FastAPI, PostgreSQL, ETL processes, and third-party integrations, and one thing I've learned is that keeping ingestion pipelines reliable is often more challenging than building the API itself. Validation, monitoring, and quick failure detection make a huge difference as systems grow.
It looks like you've put a lot of thought into the platform. If you ever decide to bring on another backend engineer, I'd be interested in contributing. The kind of problems you're solving are exactly the type of work I enjoy.
Appreciate that, genuinely. Let's see how things go, who knows what the future holds. I'll keep your interest in mind. Good luck with what you're building too.
Thanks, I appreciate that. It was really interesting hearing about the architecture and the work that's gone into it. Wishing you the best with the launch—I hope it gains the traction it deserves. If you ever want to bounce ideas around or need an extra pair of hands on the backend, feel free to reach out.