Made by David, Built with AI
All projects

The ‘Defender’ sites

Three live products that turn a confusing UK letter into a clear, evidence-led response, built from first idea to launch with AI.

The problem

People facing a planning application next door, a service charge demand or a refused school place get dense paperwork and little guidance. A solicitor is the usual answer, and it is expensive for a first step.

Each site takes what the person pastes in, checks the case is in scope, shows a plain-English summary, and produces a structured pack: an objection letter, a Defence Pack or an Appeal Pack.

What I built

Planning Defender came first. It reads a planning application, suggests grounds for objection tied to real planning considerations, and drafts a submission-ready letter. It includes a directory of 243 councils, with a checked link to the council's own planning portal for 234 of them.

Section 20 Defender and School Place Appeal were built from the same architecture. They are separate products with their own domain, data and accounts. Each one refuses cases outside its scope, for example a tenant or a case outside England, and says why.

Everything around the product was also built with AI: the copy, the payment flow with Stripe, the database, transactional email, deployment on Vercel, and the SEO and security work.

The Planning Defender home page
Planning Defender: object to a planning application.
The Section 20 Defender home page
Section 20 Defender: question a service charge.
The School Place Appeal home page
School Place Appeal: appeal a school admission refusal.

How a case moves through each site

  1. PasteThe person pastes their notice or letter
  2. Scope checkIn scope, or a clear reason why not
  3. SummaryPlain-English reading, free preview
  4. AssessmentEvidence present, missing, questions
  5. PackLetter or pack, paid via Stripe, emailed

How AI was used

Claude as builder and adviser

Claude wrote the code, working inside my editor, and I also used it to advise on hosting, integrations and the order to do things in. It was a technical partner, not only a code generator.

Skills for design and SEO

A front-end design skill gave the sites a deliberate look. An SEO skill produced written audits, a prioritised backlog and a changelog for each site, so SEO work was tracked like any other workstream.

A template, then clones

Once Planning Defender worked, it became the reference architecture for the other two. That made the second and third sites far faster, while the rules kept each product's scope tight.

Fact-checking with a different AI

These sites give guidance people may rely on, so accuracy matters. Claude built the sites and wrote the content. I then exported each project's content into a document and asked Microsoft Copilot's Deep Research to check it critically. A second AI from a different vendor, with no stake in the original wording, is a useful reviewer.

What I think is clever

  • Speed from a template. Planning Defender went from first commit to live Stripe payment testing on its first day, 15 August. School Place Appeal was copied from it on 20 August and was rebranded, security-hardened and SEO-audited within two days.
  • Scope guards: the wizard checks the case is genuinely in scope and stops with a clear message if it is not. Honest refusal is a feature.
  • No merits scores and no legal opinions. The packs show evidence present, evidence missing and neutral questions to ask.
  • Verified council portal links. 234 of the 243 were found on the council's own site and loaded to check they were live, instead of guessing the address from the software vendor. The other nine have a documented reason.
  • AI used at runtime with guardrails. Claude is called through a forced schema, told never to invent facts, and the output is validated and retried. The Section 20 prompt forbids any statement that a charge is valid or invalid. A check rejects forbidden wording and retries, and where to submit an objection is a lookup table, not generated text.
  • Claude as the auditor. Claude Code was run as a security auditor and as an SEO consultant, producing an audit, a prioritised backlog and a changelog for each site. The audits found real problems, for example scope checks that trusted the browser, now recomputed on the server.
  • Written test packs for the appeal and Section 20 flows, plus recorded security audits for each site.

What I learned

  • Treat the first product as a template. The marginal cost of the second and third drops sharply if the architecture is clean.
  • Where users may rely on the content, build a checking step into the process. Do not rely on the author to catch its own errors.
  • Keep audits and backlogs as files in the repository. They show what was decided and why.
  • Fast does not mean finished. The first build shipped with invented homepage statistics and testimonials, and a paid session that could be replayed to unlock unlimited packs. Both were found and fixed within a day. A fact check of the Section 20 guides then found 22 accuracy problems across 12 of 13 guides.
  • What I would do differently: add more unit tests. The sites lean on CI checks and manual test packs, which caught a lot but not everything. School Place Appeal's CI did not run at all for a while because it pointed at the wrong branch name.

Guidance, not legal advice. Nothing is filed or sent for the user.