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.
Four stages. Three of them you pay for.
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.
Understand it
We spend time with the people doing the work. Not just the person who owns the problem — the estimator, the supervisor, the admin who holds it all together, whoever's actually filling in the sheets. They know where it's broken, and they'll usually tell you if you ask properly.
We follow the work from enquiry to invoice and mark every point where something gets re-typed, printed, photographed or chased. Those points are where the time goes and where the mistakes live.
We also look at what you already pay for. If one of the tools you've already bought could do the job properly, that's a cheaper answer than ours and we'll say so.
Fix it
Then we argue with it.
Putting a broken process into a nice interface gets you a nicer broken process. So before anything gets built we work through why things are done the way they are — whether that form really needs six fields, which step exists because of a problem that got solved in 2019, why two people are checking the same thing.
Some of what changes is the software. A fair bit of it is how the work gets done and who does it. That's the part most people skip, and it's the part that makes the difference between a system that gets used and one that gets worked around.
Build it
Fixed scope, fixed price, clear timeline. You'll have clicked around a working version before you commit to anything, so there are no surprises about what you're getting.
Then we build it in the open. Every week your team sees it, uses it, and tells us what's wrong — and we fix that before the next session. On bigger builds we roll it out department by department rather than switching everything on at once.
By the time it goes live, nobody's being trained on a system they've never seen. They've been using it for weeks.
Improve it
Software's never finished. Your business changes, a client changes their requirements, a regulator moves the goalposts.
So we stay on — improving it, extending it, and fixing things before they become problems. This is also where AI usually starts earning its keep, once the foundations are solid enough to carry it.
What a week actually 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, no delivery lead, no senior name at the pitch and a junior on the actual 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, even if some of the build work is shared with a trusted development partner.
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.
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 actually 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.
Worth saying plainly: 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 one in the folder nobody's opened since 2021.
- 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 takes six weeks and one that takes six 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. If something breaks at an awkward hour, we know before you do.
- 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 →
What the first month looks like.
This week
A half-hour conversation. You tell us what's slow, broken or missing. We tell you honestly whether it's worth doing.
Week one
Discovery starts. We're in your business, talking to your people, following the work.
Week two
We build the shell and write up what we found. You get a map, a roadmap, a fixed quote, and something on screen you can click around.
Week three
You decide. Build with us, act on the findings yourself, or do nothing. All three are fine, and you keep everything either way.
Week four
If we're building, we've started. First working session at the end of it.
A month in, you'll either have a system taking shape or a very clear picture of your own operation. Neither is a wasted month.
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.