Know what's being built next door

The idea

Every city publishes its planning applications and building permits, and almost nobody reads them. The data sits in a portal with a search form, a date range, and no way to say "tell me when anything happens within 300 metres of my house." This is a service where you enter an address, draw or accept a radius, and get an email when a new application lands inside it — with the applicant, the description, the documents, and the deadline for public comment.

The hard part isn't the alerting. It's that every jurisdiction publishes differently, and the useful fields are usually buried in a PDF rather than a column.

Why build this

The people who care most find out last. A homeowner learns about the four-storey block behind them when scaffolding arrives; the comment window closed six weeks earlier. Small landlords, local journalists, estate agents, and community groups all end up refreshing the same portal by hand, or paying for a commercial planning-data product priced for developers rather than residents.

Two things make it tractable now that weren't a few years ago. First, open-data mandates mean a growing share of councils and cities expose permits as structured feeds rather than only HTML — Socrata and ArcGIS endpoints in much of North America, and scrapeable but consistent portals elsewhere. Second, document extraction got cheap: pulling a storey count and unit count out of a scanned design-and-access statement is now a per-document cost measured in fractions of a cent, not a human reading it.

Stack sketch

• Ingestion: Python workers per jurisdiction — httpx against Socrata/ArcGIS REST where available, Playwright for portals that only have a search form. One module per source, each returning a normalised record, so a broken council never blocks the others.
• Storage: Postgres with PostGIS. Applications table with a geography(Point) column, GiST index, plus a raw-payload JSONB column so you can re-parse history after changing the schema.
• Geocoding: self-hosted Nominatim for addresses, falling back to the jurisdiction's own parcel layer where it publishes one. Don't pay per-lookup for something you'll run millions of times.
• Document parsing: pdfplumber for text PDFs, then Claude Haiku on the extracted text to pull structured fields (storeys, dwelling count, use class, demolition yes/no) with a strict JSON schema and a confidence flag.
• Alerts: a nightly job that joins new applications against subscriber geofences with ST_DWithin, and sends digests through Resend. Postmark if you'd rather pay for better deliverability early.
• Frontend: Next.js with MapLibre GL and a vector tile layer of recent applications, so the map is browsable before anyone signs up.

Scope for v1

• One metro area. Pick one with a clean open-data endpoint so you spend your time on product, not scraping.
• Address in, radius slider, weekly email digest. Daily as a paid option later.
• Map view of the last 90 days, shareable by URL. This is the thing people send to a neighbourhood group chat, and it's your whole acquisition channel.
• Deliberately out: comment submission, document OCR for scanned-only files, appeal and decision tracking, any kind of prediction about whether something will be approved.

Where it could go

The obvious expansion is jurisdictions, and the honest answer is that each new one is a few hours of adapter work plus ongoing breakage. That's a moat if you treat it as inventory rather than a chore — maintain a public coverage map and let people vote for their city.

The second path is the one with revenue in it. The same normalised feed that emails a homeowner is what a builder, surveyor, or solar installer wants as a lead list: every extension application within their service area, within a day of filing, as a webhook. Same pipeline, different packaging, an order of magnitude more price tolerance.

A third, slower path is longitudinal. Once you've held five years of applications, you can answer questions no portal will: how long approvals take by ward, which agents get refused, where density is actually changing. That's the version local reporters cite.

Watch out for

Portal terms of use vary, and a few explicitly prohibit automated access even where the underlying data is public record — check before you point Playwright at anything, and prefer official endpoints. The other trap is alert quality: one irrelevant email about a loft conversion three streets over and people unsubscribe, so tune the radius and the noise filters before you chase volume.