About · One-person studio
Web apps, internal tools, and the systems that move data between them. I work with a small number of clients at a time, so each project gets proper attention and isn't just one of many on a board.
Automations stopped being enough.
Started 2024
Automations
Make.com scenarios, Airtable bases
Then
Applications
APIs, data modelling, front-end
Now
Software development
The systems thinking was the valuable part
I started building automations in 2024, Make.com scenarios and Airtable bases, fixing real day-to-day problems for a business that needed them fixed. It worked, and then I outgrew it. The more I learned about APIs, data modelling and front-end work, the more I found myself replacing automations with what they'd really been standing in for, which was an actual application.
That's why this site says software development and not automation. I think working out how the whole system fits together was always the part that mattered, and the tools just couldn't carry it any more.
I wanted to own the decisions.
In-house, I spent a long time building things I was proud of and watching them get shelved. They worked fine, but whether a system survives is rarely up to the person who built it. Working directly with clients means whoever makes the technical decisions is the person who has to live with them, and what I build has a real chance of still being there in a year.
That's what I'm actually in it for, more than the building itself. It's the moment something I made is just running in someone's business, saving them a day a week they'd stopped noticing they were losing.
I ask a lot of questions before I write anything. I'd rather spend the first week making sure I'm building the right thing than hand over something that works on paper and doesn't help in practice.
I think about what can go wrong early on. What happens on a re-run, or when the data's wrong, or in the middle of the night when nobody's watching. Most of what I build ends up being something the business relies on every day, so the interesting work is usually in stopping it from being wrong without anyone noticing.
I'm not a WordPress developer, and I'm not the right person for a quick patch on someone else's site.
On inherited systems
I'll take on an existing system, but I'll tell you up front what that involves. Working out the reasoning behind code you didn't write takes real time, and it usually means changing things just so the next person can follow them. Inheriting a system is often more work than designing one. Not always, but often enough that I think it belongs in the conversation before anyone agrees a number.
Where I'm best
I'm at my best designing and building something and then sticking around to live with it, or advising if that's what's needed.
I run the studio on software I built.
Built for AutomatedPanda
The internal platform the studio runs on, with clients, projects, enquiries and the content pipeline behind this site all in one place. It's not for sale and it's not a demo. I use it every day, which I think is the quickest way to answer whether I can build one for you.
Side project
A tool for a game that I built for myself. It's live and paid, and it's a fair demonstration of the same stack.
I take on a small number of client projects at a time. If that sounds like a fit, get in touch.
Get in touch