When off-the-shelf doesn't cut it.

Sometimes a website isn't enough. You need something that actually does something — whether that's a member portal, a booking system, or a database.

The line between web design and digital development are blurred. A key thing about digital development is generating a website, an API, or even a suite of apps that work the way your organisation works rather than forcing you to adapt to someone else's software. It's the difference between a static website, and a web application. It is something built specifically for what you need, not a template you're fighting against.

---

What this looks like in practice

Custom web applications

Software built around your workflow, not the other way around. If you've ever thought "I wish we had a system that just did this" — that's what I build.

Database design

Structured, sensible data storage that makes reporting easy and stops people putting phone numbers in the wrong field. (Yes, that's a real example.)

API development

If your systems need to talk to each other — or to external services — I can build the connections. Your website talking to your CRM, your booking system updating your mailing list, that sort of thing.

Integrations

Connecting the tools you already use so you're not copying data between spreadsheets. Payment processors, email platforms, CRMs — I'll make them work together.

Authentication

Secure login systems for members, staff, or donors. I use battle-tested tools like Clerk rather than reinventing the wheel — because security isn't something to improvise.

---

Catmin: a case study

When I worked at Calibre Audio, they were using a library management system that didn't fit how they actually operated. So I built them a new one from scratch.

Catmin handles their entire audiobook library — thousands of titles, tens of thousands of members, and a workflow tailored to how their volunteers and staff actually work. It replaced a system that had been held together with workarounds for years.

It's not perfect, and there's plenty I'd do differently now. But it works, it's theirs, and it means they have data and insight they never had before.

---

How I approach it

This kind of work starts with understanding the problem properly — not jumping to a solution. I'll ask a lot of questions: What are you actually trying to do? What's frustrating about how you do it now? What does success look like? From there:

• Scoping — defining what we're building and what we're not
• Architecture — planning how the pieces fit together before writing code
• Build — iterative development with regular check-ins so you can see progress
• Testing — making sure it works for real users, not just in theory
• Handover — documentation and training so you're not dependent on me forever