How We Work
No mystery. Just a clear path from problem to working software.
If you've been through a system implementation before, you're probably braced for six months of meetings and a launch nobody's ready for. This is deliberately not that.
The method doesn't change with the size of the job. Whether you're buying one workflow or the whole operating system, we analyse the entire business first, work out what the system should look like end to end, and then build the part you've paid for as a piece of that. It costs us more time up front. It's the reason nothing we build turns out to be a dead end.
Four stages. Three phases.
How we think about the work, and how it maps to what you actually buy.
Method
What you buy
Most of the value is in the first two, which is also the cheapest part. That's not an accident: it's the whole reason we start there.
What else you could do.
- Buy off-the-shelf.
- Fastest and cheapest up front, and sometimes it's genuinely the right answer. We'll tell you when it is. The catch is what happens around it: you adapt to the software, and the gaps get filled with spreadsheets, re-typing and somebody's notebook. That's a second system running alongside the one you're paying for, and because it comes out of hours rather than licences, it never appears next to the subscription when anyone adds it up. It's fine until the gaps are the bit that proves you did the job.
- Hire a developer.
- Full control, and it makes sense once there's enough work to keep someone busy for years. Below that you're carrying a salary, recruiting for a skillset you can't assess, and betting the business on one person's notice period.
- Go to a big agency.
- More people, more process, and a rate card to match. Works well for big programmes. For a fifty-person business it usually means a senior name at the pitch and a junior on the actual work.
- Work with us.
- Small team, fixed prices, and the person who understands your business stays with it, from the first conversation to the thing still running three years later. We're not right for everyone. If you need a hundred developers, we're not it.
What a week looks like.
During a build, this is the rhythm. It's less disruptive than most people expect.
- Monday
- A short written update. What we did last week, what's coming this week, anything we need from you. Two minutes to read.
- Midweek
- We build. You don't hear from us unless something needs a decision, in which case we'll ask rather than guess.
- Thursday or Friday
- An hour with you and whoever's using the thing. Not a demo: you drive it, on your own data, and tell us what's wrong. That's where the real requirements come from.
- Between times
- We're on email and phone. You'll get an answer the same day.
That's it. One hour a week from your team, and a message you can read standing up.
You'll deal with the person building it.
No account manager and no delivery lead between you and the work. The person who sits in your business working out what's wrong stays with it: the person who understands your business is who you deal with, start to finish. Our main office is in South Wales and we have a development office in Sri Lanka; that team builds, and what they don't do is sit between you and the person who worked your business out.
That's the upside of being small. The obvious question is what happens if we get hit by a bus, which is fair, and the answer is in what we build. Standard, well-documented technology, no proprietary tricks, and you own all of it. Any competent developer could pick it up. We'd rather you stayed because we're good than because leaving is difficult.
New software means new ways of working. That's a people problem, not a technology one.
Most system rollouts fail on the human side, not the technical one. So we treat that as part of the job rather than something you deal with after we've gone.
We talk to people before the decision, not after.
The team can tell when something's been decided over their heads. Involving them early costs an hour each and saves months of quiet resistance.
We take the fear seriously.
When AI comes up, somebody usually goes quiet, often the person who's been doing the job longest. That's a reasonable reaction and it deserves a straight answer, not a reassuring slide. We'll tell your team what the system does, what it doesn't, and what it means for them.
Nobody's job is a line item in our proposal.
If a change frees up someone's time, the useful question is what they do with it. We'd rather help you work that out than hand you a saving and leave you with the conversation.
Some work is better done by a machine. That's the point.
Re-typing the same information into a second system, chasing the same paperwork, checking a thing twice because nobody trusts the first check. Nobody's good at that and nobody should have to be. What people are good at is judgement, difficult conversations, and spotting the thing that's about to go wrong. We build systems that take the first kind of work and hand the second kind back.
Sometimes we'll tell you not to automate something.
Not because we can't, but because the judgement in it is the reason the job is worth doing, and a role stripped back to handling exceptions is a role someone leaves. That advice costs us the work, which is roughly why it's worth saying.
We find someone inside your business to own it.
Every rollout that sticks has one person on the inside who gets it and champions it. We'll spot them early and make sure they know it better than we do.
Move at a pace your people can take. It's slower on paper and quicker in reality.
Working with a studio that uses AI
We use AI tooling in almost everything we build: it's why a team our size can ship like a much bigger one, and why our prices work for a small business.
But AI is the tool, not the point. The point is software that does a real job for a real business. We just happen to build it faster than most.
Using AI to build your software and putting AI into your business are two different things. The first is how we work and it's included. The second is a decision you make later, when the foundations are there to support it.
What we'll need from you.
Not much, but not nothing.
- Time with the people who do the work.
- An hour or two each with three or four of your team gets us further than a month of meetings with management.
- Honesty about the workarounds.
- Including the embarrassing ones. Especially those: that's usually where the actual process lives, as opposed to the version that got written down once and never revisited.
- Someone who can make a decision.
- One person on your side who can say yes without convening a committee. It's the single biggest difference between a build that lands in weeks and one that drags on for months.
The boring but important bit.
- Standard technology, nothing exotic.
- We build on tools that thousands of developers know. No proprietary framework that only we understand.
- It's hosted properly.
- Backed up, monitored, and updated. Nobody in your business has to be the one who notices.
- It works on a phone.
- If part of the job happens in a van or on a site, that part has to work on a phone with one bar and gloves on. That's a design constraint from the start, not a later addition.
- You own all of it.
- The code, the data, and the right to take it elsewhere. See what you own →
Ready when you are.
Half an hour, no pitch, no obligation. Tell us what's not working and we'll tell you what we'd do about it, including if the answer is nothing.