Services
We are a small studio, so we are deliberately narrow. These are the three things we do, and we would rather turn work down than take something we would be learning on your budget.
Custom software development
Building the thing that does not exist yet, in a way that survives the people who built it.
Backends, web applications, internal systems. The hard part is almost never the first version - it is whether anyone can still change it in two years. We write for the person who inherits the code, because on a long enough timeline that person is you.
- A working system, deployed, not a prototype that needs a rewrite
- Documentation written while it is being built, not afterwards
- Tests where they earn their keep, not a coverage number
Planning and architecture
Deciding what to build, and what it will cost, before anyone writes code.
Data modelling, service boundaries, infrastructure and a realistic estimate. Most expensive software mistakes are made in the first week, by people who were trying to be helpful and start quickly.
- A written technical plan you own, whoever ends up building it
- A cost estimate for running it, not just building it
- An honest answer about what should not be built at all
Maintenance and evolution
Taking over something that already exists and making it stop hurting.
Systems that are slow, fragile, undocumented, or whose original author has left. We start by making the current behaviour visible, because changing a system nobody can observe is guesswork with a deployment step.
- Monitoring and alerts that name the thing that broke
- The failures ranked by what they actually cost you
- A runbook, so the next incident is not an emergency
How we build
Three habits. They are unglamorous, and they are the difference between software that lasts and software that gets rewritten.
Measure before changing the engine
An optimisation without a measurement before and after is a guess that cost money. We establish the number first, then change one thing, then check the number moved. It is slower for a day and faster for a year.
Do the expensive work only when it is necessary
Anything that runs on a schedule should first ask whether the work is needed at all. Most systems are slow not because the code is bad but because they cheerfully redo work nothing asked for.
Write the exposure model down
Every service should have a documented answer to "what can reach this?". Security that lives only in someone’s head is not a security model, and it is the first thing lost when a team changes.
Commercial terms
A paid discovery first
One to two weeks, fixed price. You get a written technical plan and a fixed quote for the build. If you take the plan elsewhere, it is yours - that is the point of paying for it.
Fixed scope, fixed date
We quote a defined piece of work with a delivery date rather than selling hours. Scope changes are re-quoted in writing, not absorbed quietly and then argued about.
You own everything
Code, infrastructure and accounts are in your organisation from the first commit. There is no handover event because there is nothing to hand over.