Explore Kingston

One developer, no reviewer, no budget, and a real deadline. A volunteer project has no code review, no product owner, and nobody to notice a shortcut. The usual result is software that works and cannot be handed to anyone.

That was the actual risk here, and it was not hypothetical. An app a town depends on, understood by exactly one unpaid person, is a liability dressed as a contribution. The interesting constraint was never can this be built — it was can it be built so that my leaving is survivable.

Every governance practice that normally exists because someone enforces it, applied with nobody enforcing it. Not for tidiness — because the handover was the requirement.

• 369 test files across two suites, one of which runs against real Postgres rather than a mock
• Architecture decision records — seven of them, each naming the option rejected and why
• Dependency-boundary linting, so the layering is machine-enforced instead of remembered
• Lighthouse CI with a performance floor that fails the build
• A freeze manifest — a list of files that agents may not edit without a human, enforced by a pre-edit hook and a CI check, not by a comment asking nicely
• Around 35 documents covering architecture, data provenance, operations, incident response, and restore drills

The result is currently 496 source files and 511 commits across 164 merged pull requests — a pull-request workflow maintained by someone with no one to review the pull requests.

No decision records, no boundary lint, no freeze manifest — because there is no reviewer, and every one of those costs time that could go into features. For a weekend project that is the correct call.

It is the wrong call here, and the reason is counter-intuitive: a volunteer project has higher handover risk than a funded one, not lower. A funded team has payroll, onboarding, and people who will still be there next quarter. A volunteer project has one person's attention, and that attention is the single point of failure. The discipline is worth more precisely where nobody is requiring it.

Beyond tourism, the app is becoming the chamber's membership system of record, replacing a commercial association-management product. The safe option was to keep paying for it and let the app stay a brochure.

What made that decision serious is a one-way door. The incumbent product auto-renews annually, written non-renewal notice is due well before term end, and there is no data export after termination. Get the sequence wrong and the records are simply gone.

So the plan is written export-first: everything comes out while the subscription is still live, the app becomes the system of record before anything is cancelled, and the accounting system keeps owning the money. That sequencing is the whole decision. The build is the easy half.

This one is in progress, not finished — the rollout is phased and deliberately slow. Claiming an outcome here would be claiming something I cannot yet show.

It is not evidence of stakeholder management. There was no client, no procurement, and no organisational resistance to move. It is evidence that I build, and that I build to a standard when nobody is checking.

And the documentation is aimed at the wrong reader. Around 35 documents for humans — and the agent-facing configuration is a single file of a few hundred bytes. I built a codebase that a person can learn and an AI assistant largely cannot navigate, which is a strange thing to have done while using AI assistance to build it. Fixing that deliberately is the next project.