Topic
Sign in
Peyman Owladi

The genuinely new thing about AI-assisted development isn't speed – it's who can build. Campaigners, organisers, and charity staff can now make real, useful software: a volunteer rota, a form that feeds a spreadsheet, a lookup tool for your casework, a microsite for a local campaign, a script that turns voice notes into structured data. If it's for a known group of users, holds nothing sensitive, and resembles things that already exist, you can probably just build it.

Being a builder is still a disposition, though, not a default. You need some interest in technology, product thinking, and solving problems with tools to want to do this at all. And that's fine, because not everyone has to! The valuable new layer is non-developer builders who interface with non-developer non-builders: close enough to their colleagues to understand the real problem, close enough to the technology to build the answer.

The edges are where it gets interesting, and there are four worth knowing by name.

  • Sensitive data: the moment your tool holds information about real people – members, beneficiaries, voters – you've acquired security and legal obligations that no prompt will handle for you.
  • Reliability: the unexpected happens – an edge case, an outage, a malformed input – and a tool built without defences can lose data and disrupt the work it was meant to support.
  • Scalability: something that works great in your testing and with a few friends can easily fall over once you have hundreds of users, or even in some cases just because it's been running for a hundred days and has built up more data than the system was set up to handle.
  • Maintainability: Inevitably as you keep updating and adapting your tool, it gets increasingly complex. You get to the stage where fixing something in one place breaks something elsewhere and you're playing whack-a-mole with a blindfold on.

Cross any of those lines and you don't need to stop; you need a technical person in the loop, and ideally guardrails set up before you started: sandboxes, templates, review points, safe defaults.

For political and nonprofit orgs, where the person who understands the problem is almost never a developer, getting this deliberate rather than discovering the edges by incident is a structural advantage. The risk contrast to hold in mind is an agent running loose with full access versus a supported, safely-iterable workflow.

Key question/s: What's on your list that you could just build this week? Which of the four edges is your idea closest to? Who in your organisation is a builder who doesn't know it yet?

Reading/links