Peyman Owladi

There are different levels of grant in civic and political tech funding, broadly across this range. Each buys something qualitatively different, not just ten times more. I've run and advised projects at all of these scales. And it has changed less than you may think.

• £10k gets you enough of your time and a bit of support to create a proof of concept and validate it with users, and hopefully gets you in a position to seek the next tranche of funding
• £100k could just about get you to paying customers and a sustainable tool if your plans suit that model, and if not to generate some history to build the next fundraising round on
• £1m allows you to build out an organisation, sustainability plans, partnerships, and so on - but it's still only a small team for a few years and you need a plan for what comes next and what your endgame is

The acceleration of development has had a big impact on the early stage: you can get to real users and proving real value sooner. But ongoing maintenance overheads, the imperative to continue evolving, and the pains of scaling up are still real.

Happy to speak to you about a project you're considering. Useful sub-questions: what outcomes should you promise before the money runs out? How much goes to external support vs your own team? At what point do partners matter more than headcount?

Reading/links

• JRRT grants awarded - one of the few funders of explicitly political (non-charitable) tech; browse what real grants look like
• Dovetail briefs - scoped nonprofit tech projects with budgets attached
• GrantNav (360Giving) - search actual UK grants data to calibrate your ask
• What's your endgame? (SSIR) - the different "exits" for a nonprofit

Charities and campaigns hold some of the most sensitive data there is – beneficiaries, members, donors, political opinions – on some of the smallest tech budgets there are. Rapid iteration and good security are usually presented as a trade-off. In my experience they can go hand in hand: get the architecture right and a tiny team can ship daily without lying awake at night – and less technical teammates can get stuck in too.

I've architected products like Learning with Parents to build for security with minimal impairment to velocity, as well as working on DPIAs for government procurement, taking organisations through Cyber Essentials and ISO 27001 certification with policies and processes designed to minimise disruption, and building an AI product (Chalk) that touches schools' data, all with a handful of people. Happy to discuss what we've done to make this work.

My first thought in designing security architecture is to contain the risk in the smallest space possible – safety nets, sensible defaults, and clear boundaries around data – so the area that needs strict verification stays small. In a tech stack this means database-level controls on data access (specifically the Postgres "Row-Level Security" feature). At the org level it can mean a single store of sensitive data with separate controls from the rest of the estate. And data privacy needs to be thought about from day one – a DPIA can be a design tool – and it's useful to know the attack categories that actually hit small orgs.

Key question/s: How much security does your project actually need, and where should it live? What would let you stop worrying about most of your codebase?

Reading/links

• NCSC Small Charity Guide – the baseline, free, written for non-specialists
• Cyber Essentials – the UK's entry-level certification, with genuinely useful triggers for think about cybersecurity
• ICO guidance on DPIAs – when you need one and what goes in it
• Postgres Row-Level Security – the database feature that does the containment work
• OWASP Top Ten – the standard list of what actually goes wrong in web apps

Poteris is a not-for-profit tech collective: flat structure, equal pay, around a dozen people, no external funding. It's one answer to a set of questions every tech-for-good founder faces – nonprofit or for-profit? Agency work or products? Hierarchy or flatness? After five years I can share our experiences of our attempt at a flat structure, equal pay, a 4 day week, and trying to do things differently.

Things I'm happy to go deep on: legal form (we're a CIC – what that constrains and enables); why "equal pay" is simpler to run than any alternative we considered, and who it selects for and against; the cross-subsidy between client work and products; the problem with co-ops; and why it's OK to miss out on some work, some clients, and some growth.

Key question/s: What does a healthy team culture look like? Which parts of a conventional company are load-bearing, and which are habit?

Reading/links

• Reinventing Organizations – Frédéric Laloux; the standard tour of self-managing organisations
• Seven Transformations of Leadership (HBR) - an interesting view on multiplying up impact
• Community Interest Companies – the UK legal form we use

Routine, repeatable tasks are usually better as code – reliable, repeatable, verifiable – with AI steps embedded where needed, not handed wholesale to an agent. At the same time, fast development has revived the personal script: one-off, context-specific tools that were never worth building before, because the gap between "nothing" and "a maintained general-purpose tool" used to be too wide.

The key discipline is keeping the line clear between what you maintain and what you throw away. For me, every project and tool falls into one of these buckets:

1. productionised - other users, uptime requirements, churn brings risk
2. maintained - utilities and regular scripts that you need to keep in working condition but are free to amend, change and reset
3. archive - never updated, but mined as starting points
4. temporary one-offs

A key skill is identifying which bucket each tool you consider falls into, and applying only the necessary level of effort for that bucket.

Examples from our own work: a timesheet tool and a payroll-reconciliation script, both of which would have been agents if we'd been fashionable and worse if we had.

Key question/s: Which of your workflows deserve a tool rather than a chat window? What's in your personal toolkit?

Reading/links

• Building effective agents (Anthropic) – notable for how often it advises against agents
• Scripting with LLMs – Simon Willison's llm tool – the embed-AI-in-a-script pattern, ready-made

Are we stuck with the tools of 2024 because that's what the models were trained on? Or as they improve, do choices in fact widen? AI assistance quietly changed the calculus of stack choice: the best-documented, most-discussed technologies got a productivity multiplier that obscure-but-elegant ones didn't. Alongside it, not-invented-here syndrome has also multiplied: "Why pay for a SaaS when I can build it myself for nothing?"

I can share the stack we've settled on at Poteris for scalable apps on nonprofit budgets, and why each piece earns its place: Cloudflare for hosting/edge/DNS, Neon for serverless Postgres, Drizzle as the ORM, Better Auth for authentication, and Next.js or Svelte as the framework (a debate that's still live in our team).

And of course, "I can build it myself" continues to be a fallacy and a time-sink in all but the simplest cases. Any tool with a little meat to it benefits hugely from the fixes for all the bugs and pain points people have found over a period of use, and continued maintenance and improvement. Off-the-shelf remains the default choice: focus on the bits you're interested in, and piggyback off others for the rest (although personal/one-off tools with a very specific use can be a different matter).

The framework for making these choices: minimise the number of things that can wake you up at night, maximise what AI tooling can help with, let others do the heavy lifting where you can, and keep your escape routes open.

Key question/s: What should you build, what should you buy, and what should you let the models' training data choose for you?

Reading/links

• Choose Boring Technology – Dan McKinley's essay on stack choice
• In Defense of Not-Invented-Here Syndrome – Joel Spolsky's classic steelman for building it yourself
• Next.js · Neon · Drizzle ORM · Better Auth · Cloudflare – the Poteris default stack, all with generous free tiers for prototypes
• Svelte – the other side of our still-unsettled framework debate

Most tech projects don't fail early; they fail at the end. The demos look good, launch approaches, and then it's "almost there" for weeks. The fix is rarely technical: it's deciding how "good" each part actually needs to be, and for whom, then cutting scope until launch is possible. I've been brought in to dig teams out of this on multiple occasions — including once turning a multi-week overrun into two days of work in a half-hour conversation.

The useful mental moves: think in vertical slices (a thin end-to-end version of everything, rather than a polished half of something); distinguish "must be good", "must exist", and "can be absent" per user type; and keep the most important thing the most important thing. If your project can't ship a meaningfully smaller version this week, that's usually a scoping problem, not an engineering one.

Key question/s: Why do most tech projects fail late rather than early? What would it take for your project to launch this week?

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

• Not all AI-assisted programming is vibe coding - Simon Willison's view on the distinction
• Lovable - an opinionated platform helps, but still, here be dragons

Sprint is long dead. A fixed two-week cadence stopped making sense once daily delivery became normal – and that was before generative AI. But the answer isn't to abandon agile: it's to strip away the ceremonies that accreted around it and rebuild your practice from the core principles and motivations, which apply better than ever.

Read the Agile Manifesto again, with it's four value statements and twelve principles. It says nothing about sprints, story points, or standups. Working software over comprehensive documentation; responding to change over following a plan. Written in 2001, it fits today's pace better than the pace it was written at. The ceremonies were one generation's implementation of those values at a particular speed of delivery; when the speed changes, you re-derive the practice from the principles rather than defending the rituals.

I'd argue AI is best understood as the latest step in a twenty-year speed-up of software development, not a discontinuity – and seeing it as continuity makes the right responses much clearer and less reactive. The questions people treat as new ("now we need to think harder about what to build") have been live for ages. In my own team, re-deriving the practice at daily-delivery cadence looks like: continuous merging ("if it's better than what we have and won't adversely affect our users, merge it"), work sliced to a day or less, and keeping the most important thing the most important thing.

Key question/s: Which ceremonies would you reinvent from scratch at today's speed, and which quietly disappear? What replaces the sprint, the standup, the retro?

Reading/links

• The Agile Manifesto (and its twelve principles) – four sentences from 2001; still the core, still applies
• Scrumban – the halfway house many teams land on
• The Linear method – an opinionated modern take on structuring work
• Elephant Carpaccio – slicing work for fast feedback loops

The AI adoption story in the nonprofit and education sectors is nothing like the tech-industry one: budgets are tiny, risk tolerance is low, safeguarding is paramount, and the gap between staff already using ChatGPT personally and organisations with any actual policy is enormous. I watch this from both sides – building AI products used in hundreds of schools, and advising charity leaders on what to actually do – and regularly brief nonprofit working groups on the state of play.

What's worth knowing: teacher AI adoption is far ahead of school policy; the DfE has a framework worth reading even outside education because it's had to be ahead of the curve in official responses; charity adoption is high at the individual level and thin at the organisational level; and the biggest practical wins are boring – drafting, admin, resource adaptation – not moonshots. The interesting design question is building AI tools for sectors where trust must be earned structurally: what data you touch, what you never touch, and what stays human.

Reading/links

• DfE: Generative AI in education – the official UK position
• Charity Digital Skills Report – the best annual data on charity-sector adoption
• Chalk – our teacher tool; a live case study in earning trust in schools