B—01
Custom applications
Software built around an existing workflow rather than a workflow rebuilt around software.
Why custom
Off-the-shelf software is a set of somebody else's decisions.
That is usually fine. Accounting is accounting; email is email. Buying is the right answer for anything where your business is not different from anyone else’s.
It stops being the right answer at the point where the way you work is the business — the particular way you price, schedule, approve, allocate or report. That is where a general-purpose product forces a workaround, and the workaround becomes a spreadsheet, and the spreadsheet becomes load-bearing.
Custom software is worth it exactly there and rarely anywhere else. Part of our job is telling you which side of that line you are on.
Capability
What we build.
Most projects are two or three of these together — a portal is rarely useful without the internal tool behind it, and neither is much use without the integrations.
B—02
Internal tools
Replace the spreadsheets and manual steps that hold a process together.
B—03
Customer and partner portals
Give people a place to see what they currently have to email you about.
B—04
Integrations
Connect the systems you already pay for so data stops being carried by hand.
B—05
Dashboards and reporting
One view of the numbers, rebuilt from source instead of assembled by hand.
B—06
APIs and backends
The reliable layer underneath — data, rules, and the things other systems call.
B—07
Workflow and automation
Automate the repetitive steps where it genuinely earns its place.
B—08
Data migration
Getting years of history out of the spreadsheets and into the system.
Principles
How we decide what to build.
The technology is not the hard part. Deciding what deserves to exist, in what order, is where a project is won or lost.
Start from the work, not the software
The first version of a system should encode how the job is done today, including the exceptions. Redesigning the process and the software at the same time doubles the risk and halves the chance anybody adopts it.
Build the smallest thing that changes something
A system that covers one painful process and is live in eight weeks teaches you more than a full specification does in eight months — including which of the remaining requirements turn out not to matter.
Keep what already works
Your accounts package, your CRM and your email are usually fine. The problem is that nothing joins them. Replacing working software is expensive and rarely the actual requirement.
Design for the second version
The business will want something we have not thought of yet. That is not a failure of planning — it is the normal condition, and the architecture should assume it rather than resist it.
Boring technology on purpose
We choose tools with long support horizons and large hiring pools. Interesting technology is a cost you pay later, usually when somebody else has to maintain the result.
Leave it handoverable
You own the code and the infrastructure. Documentation, access and a written architecture note are part of delivery — not because we expect you to leave, but because a supplier you cannot leave is not really a supplier.
Practice
What 'built properly' means here.
These are unremarkable in a good engineering team and absent in a surprising amount of delivered agency work. They are what makes a system changeable in two years' time.
- Version control and code review. Every change is recorded, attributable and reversible.
- Automated tests. Enough that a change to one part of the system tells you when it broke another.
- Separate environments. Development, staging and production genuinely apart, so nothing is ever tested against live data.
- Reversible deployments. A release that turns out to be wrong is rolled back, not fixed under pressure at five o’clock.
- Infrastructure written down. The environment is defined in configuration, not assembled by hand and remembered.
- Documentation that a stranger could use. Architecture, access, and how to run it — written for whoever comes next.
Technology
We use unremarkable, well-supported technology.
Typically TypeScript across the application, a relational database, and cloud infrastructure appropriate to the load — chosen for long support horizons and a large pool of engineers who already know it, so you are not dependent on us to keep it running.
Where a project has a genuine reason to use something else, we will say so and explain the trade. What we will not do is choose a technology because it is interesting to us.