What AI-assisted development looks like for tight-budget organisations

I have been building bespoke software for charities and not-for-profits for years. The work is rewarding but the budgets are always tight, which means every project involves hard choices about what to include and what to leave on the table. Features that would genuinely help get cut because the hours are not there. Scope gets trimmed to fit reality rather than need.

So I have been exploring what happens when you take 25 years of product, design, and engineering experience and combine it with AI-assisted development. Not vibe coding. Not typing a sentence and hoping for the best. Properly directed, closely reviewed, human-led development where AI handles the implementation and I handle everything else. Lanco and Quill are the results of that exploration, and the implications for the sector are significant.

The declarative vs imperative gap

Non-technical users prompt AI declaratively: "Build me a case management system." That works for demos. It produces something that looks plausible in a screenshot and falls apart the moment real people try to use it with real data.

Technical users prompt imperatively: "Build a case management system where cases are defined as structured records with status transitions, role-based field visibility, and audit logging on every state change. The data model should support nested case types for multi-agency referrals."

The second approach constrains the solution space. The AI is not guessing at every technical decision; it is implementing a specification. The difference between getting a toy and getting something production-ready is not the AI itself. It is whether the person directing it knows what good architecture looks like, which edge cases exist before they bite, and how to constrain the problem so the AI delivers to a spec rather than improvising.

I wanted to test this with real products, not throwaway prototypes.

Lanco: freelance management built in days, not months

Lanco is a freelance management tool I built to scratch my own itch. Every feature was specified by me and implemented by AI under close review. The codebase is almost entirely AI-generated; the architecture, design decisions, and quality standards are entirely human.

The interface is mobile-first and deliberately minimal. Not the feature-bloated enterprise tool with seven hundred settings you will never touch, and not the bare-bones tool that falls apart when you have multiple clients or currencies. Just what is actually needed, built to feel like one coherent product rather than a collection of features bolted together.

AI builds to spec, not to delight

AI is excellent at producing functional code. It can scaffold features, wire up APIs, and handle the plumbing faster than any human. But it has no taste. Left to its own devices, AI produces interfaces that work but do not feel right. The animations are either missing or generic. The micro-interactions that make software feel polished, the subtle hover states, the satisfying button feedback, the smooth transitions between views, none of that comes naturally.

Every AI-generated component gets reviewed for feel, not just function. Does the invoice slide in or just appear? Does the delete confirmation feel appropriately weighty? Does the whole flow hold together as a single experience? The AI handles velocity. The design eye handles quality. Both are necessary, and I suspect that balance is not going to change any time soon.

Quill: a production-ready form builder for a not-for-profit

Quill was the second test. A specific not-for-profit client needed a form builder that actually worked for their team, not a survey tool with a free tier. A proper form platform with role-based access, sensitive data handling, and accessibility baked in from the start.

The architecture underneath is a JSON schema approach to form definition. Every form is data: fields, types, validation rules, conditional logic, all expressed as structured JSON. That makes forms portable, versionable, and completely decoupled from how they are rendered. This is exactly the kind of architectural decision that separates a real product from a demo. You cannot prompt for it without knowing it should exist.

Where this is heading

Both Lanco and Quill are live, in production, and used by real people. They are not proofs of concept. They are working products that were delivered in weeks rather than months, at a fraction of the traditional cost.

The reason I keep coming back to charities and not-for-profits is that this is where the impact lands hardest. These organisations have always been priced out of bespoke software. The combination of experienced practitioners and AI-assisted development means that is no longer necessarily the case. I am still refining the process, still finding the edges, but the early results are genuinely encouraging.

Try Lanco at lanco.flett.cc. Try Quill at quill.flett.cc.