When Building Becomes Cheap, Responsibility Moves Upstream

Last month I built a small public-information tool for Spanish radon: a municipality lookup that combines the official building-code zone classifications with the national municipality base, and tells you whether your town is in Zone I, Zone II, not classified, or — and this was the important state — pending validation.

That sentence used to sound like a software project. In 2026 it is barely the point. With modern AI-assisted development, the hard part was not making the search box. The hard part was deciding what the search box was allowed to say.

This piece is about the practice that lands underneath that sentence. It is not really about radon. It is about the kind of work that becomes load-bearing when the building work becomes cheap.

The cost curve, very briefly

A consumer-facing public-information tool used to take months. A small team, a database, a frontend, an extraction pipeline for whichever PDF or registry you were translating, deployment, hosting, the works. Because it took months, the implicit decision rule was only build this if you are sure. Cost was the filter.

A consumer-facing public-information tool, in 2026, can take a long weekend. The filter is gone. Anyone with the inclination can put a public-information tool on the internet. Some of them will be careful. Most of them will not.

The web is, predictably, going to fill with half-maintained, vibe-coded public utilities. Some of them will be harmless toys. Some of them will sit near health, money, rights, housing, or bureaucracy, where an inaccurate answer can mislead someone in a way that matters. The standard response is do not publish if you cannot do it perfectly. That is not realistic and, more importantly, it is not honest. Public tools mostly are not perfect. UKradon is not perfect. The CSN's own mapping is not perfect. Waiting for institutional perfection is one of the reasons useful information stays trapped in PDFs and procedures.

So if the answer is not "do not publish," the answer has to be a different one: be a good citizen in the new floor that just opened.

That is what the methodology is about.

What good citizenship looks like

Three principles, in increasing order of how much I care about them.

1. State the source, and date it.

The tool says where its data came from, when it was extracted, and what document or registry was the basis. If you cannot point at the underlying authority for a given answer, you have not earned the right to give it. This is a low bar and most consumer-grade civic tools fail it.

2. State the limits, and refuse to round them off.

The tool says what it can and cannot tell you. For a radon lookup that is:

It does not tell you whether a specific house is safe.
It does not replace measurement.
It does not make address-level claims.
It does not turn absence from a classification list into proof of low risk.

These four statements are not boilerplate. They are the four ways a careless implementation of the same dataset would mislead somebody. Each one is included because somebody, somewhere, will assume the opposite. The job of the tool is to refuse the assumption.

3. Distinguish known unknowns from reassuring negatives.

This is the principle I care about most, because it is the one that the new low cost of building is most likely to erase.

Here is the failure mode. You write an extraction pipeline. For most of the country it works. For one province the PDF parser hits a layout edge case, and you end up with no rows. The tool, naïvely, treats those municipalities the same way it treats genuinely unclassified ones: a clean, fast "not found." A user in that province sees what looks like a reassuring result. It is not reassuring. It is a failed extraction, presented as confidence.

In the radon tool I wrote, the answer to this is a state called pending_validation. Municipalities in province blocks where the extraction or the reconciliation was not trusted enough are deliberately withheld from the standard result, and the UI returns a different state: the data for this area is not confident enough to publish yet. The user gets a worse answer. They also get an honest answer.

The general principle: a tool that cannot distinguish "I don't know" from "the answer is no" is worse than no tool at all in any domain where the difference matters. Health, money, rights, housing, bureaucracy — most of the domains where civic-tech work concentrates.

The single biggest piece of intellectual work in shipping a useful public-information tool, in 2026, is identifying every place where your data pipeline can fail silently and ensuring the failure is visible to the end user, not just to you.

The radon tool has nine withheld provinces and one suspicious-low-coverage province at present. The honest move is to expose those counts in the public UI. The lazy move is to ship the cleaner-looking version where everything renders. The lazy move is now much easier than it used to be.

4. Make the maintenance contract legible — and admit it might fail.

The first three principles are about what the tool says. The fourth is about what the tool is.

A small public-information tool is a maintenance commitment. Datasets get updated. Regulations change. Source PDFs get reissued. Authoritative registries change schema. If the tool is going to be useful in 2027, somebody has to keep it true. The honest move here is to publish the maintenance status — last updated, next planned review, contact for corrections — and to be clear that I might fail to keep it up.

This is the part that the standard advice on "responsible civic tech" tends to fudge. Real talk: I might abandon this tool. The radon project is not central to my work. If life intervenes — a job change, a family thing, a different project — it could rot in production for a year before I noticed. The honest version of the maintenance contract is to make the abandonment risk visible to the user, not to pretend it is solved.

For this project, the maintenance contract also includes a public follow-up: who I contacted, whether anyone responded, and whether the tool ever made it as far as a real home measurement.

That is what make the maintenance contract legible really means: not "promise indefinite upkeep" but "tell the truth about the upkeep, including its fragility."

Why this is sharper than it was five years ago

Pre-AI, a developer who built a careless public tool was bottlenecked by their own carelessness. The thing they could ship was small enough that the harm radius was small.

Post-AI, the carelessness scales. A weekend project can have national reach. A failed PDF parser can produce a confident-looking lookup tool covering 8,131 municipalities, of which a few hundred are wrong in a domain (cancer-risk geography) where wrong-and-confident is the worst possible outcome. The same productivity gain that lets a careful developer ship something useful in days lets a careless one ship something misleading just as fast.

The implication is uncomfortable but specific: the load-bearing work in civic-tech, post-AI, has moved from making the tool to deciding what the tool is allowed to claim. The making is solved. The decisions about scope, confidence, source attribution, and maintenance are now most of the job.

This is not how the public discourse around AI-assisted development is currently framed. The discourse is mostly about productivity gains and the displacement of routine engineering work. Both of those are real. The under-discussed third thing is that responsibility moves upstream, and the developer's job in 2026 is to take that seriously.

How this generalises

The radon tool is one application. The pattern shows up elsewhere in the work I am doing, and probably elsewhere in any AI-assisted civic-tech practice.

The heat-mortality research points at a possible second example: a working back-office for one ayuntamiento, pairing a vulnerability registry with alert-triggered check-in scheduling for a single municipality's servicios sociales team. That is exactly the same shape of project. Public data, vulnerable users, real consequences for getting it wrong. The same four principles apply, with the data-protection layer (LOPDGDD, vulnerability data, maximum severity) sitting on top. I have not published that avenue yet, so I am keeping it here as a future-pattern note rather than pretending there is a finished companion piece.

The same shape will keep showing up. AI is not making more avenue investigations possible; it is making the artifact end of avenue investigations cheaper. Which means the writer-builder's job rebalances: less time on the build, more time on the boundary of what the build is allowed to say.

The principles I am settling on, for any small AI-assisted public-information tool I ship from this point on:

The source is named, dated, and reproducible from the repo.
The limits are stated in the UI — not buried in a footer — and they are written specifically against the failure modes of this dataset.
Failed pipeline stages are surfaced as their own visible state, never as silent reassurance.
The maintenance contract is published, and the abandonment risk is named honestly.

Add an AI-assistance disclosure if the development was AI-collaborative — which most of mine now are — and that is the floor.

What this changes about the practice

A consequence I am still adjusting to: the right amount of time to spend not coding on a project like this is now considerably more than the time spent coding.

The radon tool's data pipeline took a couple of focused sessions. The decisions about which provinces to withhold, what the four user-facing states should be called, whether the UI should expose the withheld-province count, what wording to use for the pending validation tooltip, whether to include a Cadastre-Augmented risk calculator (no), whether to add a paid tier (no), whether to maintain a mitigator directory (no, can't keep it true) — those took longer than the build, and they should have. Each no is a deliberate refusal of false precision.

The skill that is becoming valuable is knowing what to refuse. That is closer to editorial judgement than to engineering judgement, and the developer who is going to be useful in this era is the one who can do both — write the extraction pipeline and recognise the place where the cleaner-looking version of the lookup result is the dishonest one.

That is slower than shipping a search box.

It is also the actual work.

Worked examples used in this piece:

The companion radon tool: radon.willworth.es. The avenue investigation that produced it is Radon in Spain: An Overhang You Can't Smell.
The proposed heat-mortality back-office for one ayuntamiento, as a non-built future example of the same pattern.