Skip to main content
Vol. III · May 2026
Writing

When Building Becomes Cheap, Responsibility Moves Upstream

In 2026, the hard part of shipping a small public-information tool is not making it work. The hard part is deciding what it is allowed to say. This is a methodology note about confidence boundaries, the abandoned-utility risk, and the kind of practice it takes to ship something useful without quietly making the world worse.

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 — the important one — pending validation.

That used to sound like a software project. In 2026 it barely is. 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 underneath that sentence. It is not really about radon. It is about the work that takes over once building stops being the hard part.

A consumer-facing public-information tool used to take months, so the implicit rule was only build it if you are sure — cost was the filter. Now it can take a long weekend, and the filter is gone: anyone with the inclination can put one on the internet, and most will not be careful. The web is going to fill with half-maintained, vibe-coded utilities — some harmless, some sitting near health, money, rights, or housing, where a wrong answer misleads someone in a way that matters. "Don't publish unless it's perfect" is neither realistic nor honest; public tools mostly are not perfect. So if the answer is not "don't publish," it has to be: be a good citizen of the new floor that just opened.

Four 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 which 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. It is a low bar, and most consumer-grade civic tools fail it.

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

For a radon lookup, that is four specific refusals:

  • 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 are not boilerplate. They are the four ways a careless implementation of the same dataset would mislead somebody. Each one is there because somebody, somewhere, will assume the opposite.

3. Distinguish known unknowns from reassuring negatives.

This is the one I care about most, because it is the one 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 get no rows. Naïvely, the tool treats those municipalities the same as genuinely unclassified ones — a clean, fast "not found." A user there sees a reassuring result. It is not reassuring. It is a failed extraction, presented as confidence.

My answer is a state called pending_validation: province blocks where the extraction or reconciliation was not trusted enough are deliberately withheld, and the UI returns the data for this area is not confident enough to publish yet. The user gets a worse answer. They also get an honest one.

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.

4. Make the maintenance contract legible — and easy to hand off.

A small public tool is a maintenance commitment: datasets update, regulations change, source PDFs get reissued. The honest move is to publish the maintenance status — last updated, next review, contact for corrections — and to be clear that I might not keep it up. Real talk: I might abandon this tool. The radon project is not central to my work; if life intervenes, it could rot in production for a year before I noticed.

Which is why the better answer than promising forever-maintenance is to make abandonment survivable. The extraction and reconciliation scripts are in the open, the sources are named and dated, the whole thing reproducible from the repo — so a person or an institution who actually owns this problem can pick it up without having to reverse-engineer me first. It is the same instinct as the pharmacogenomics tool I wrote about earlier: publish it as something inspectable and forkable, so it can improve through other people rather than depending on me. Building something to be handed off is its own kind of honesty.


The radon tool is one instance. The same shape appears wherever public data meets vulnerable users and a wrong answer has consequences — and the four principles travel with it. What changes, across all of them, is where the time goes. The radon tool's data pipeline took a couple of focused sessions; the decisions — which provinces to withhold, what to call the four user-facing states, whether to expose the withheld count, whether to add a risk calculator (no), a paid tier (no), a mitigator directory (no, can't keep it true) — took longer, and 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 engineering judgement, and the developer who will be useful in this era is the one who can do both: write the extraction pipeline and recognise the point where the cleaner-looking version of the result is the dishonest one. That is slower than shipping a search box. It is also the actual work.


A note on that tool, consistent with the argument above: it exists, it works, and it is deployed — but I am not linking it here yet. It is public health information, and before I promote it I have asked someone who knows the field to tell me whether I represent the risk responsibly. When that review closes, this piece will link both the tool and the avenue investigation that produced it. Publishing the reasoning before the artefact is, precisely, the practice this piece is about.

Discuss this article

Claude and ChatGPT open a new chat with this article link already filled in. Copy Markdown takes the source text for notes or another model.

ClaudeChatGPT