Service
Every business has work no product covers. That is what we build.
Bespoke systems for the processes that keep your company running — internal platforms, line-of-business applications, and the legacy software everyone quietly works around. We build them to fit how you already operate, then hand them over documented.
The Problem
The workaround becomes the system.
Almost nobody sets out to build custom software. Companies arrive at it slowly, after years of paying for the gap between what a product does and what the job requires — usually in people's time.
- 01
The product nearly fits
A platform covers most of the work, so the remainder migrates into side databases, shared inboxes and one person's memory. That person becomes a dependency nobody chose.
- 02
Licences price your growth
Per-seat and per-module pricing turns every new hire and every new process into a negotiation. The tool starts deciding which parts of the business are allowed to expand.
- 03
The old system cannot be touched
Legacy software still runs the core of the company, but nobody left knows why it behaves the way it does. Every change becomes a risk nobody wants to sign for.
The Approach
Fit first, then durability.
We start with the work itself — the handoffs, the edge cases, the report someone rebuilds by hand every Monday. The design follows that, not a vendor's data model.
- 01
Model the domain, not the screens
We settle what things are, what states they can hold and which transitions are legal, before any interface exists. Screens change constantly; a sound model outlives all of them.
- 02
Replace legacy in slices
No rewrite ending in one terrifying cutover. We put a seam around the existing software and move capability across a piece at a time, running both until the new path has earned the traffic.
- 03
Build for the cost of change
Module boundaries, tests and documentation are sized to how often each part will move — the volatile edges get the heavier safety net, the stable core stays lean.
Capabilities
What we take on.
Most engagements begin with a single system and widen from there, because a process that is difficult in one place is rarely tidy either side of it.
-
Internal operations platforms
The system your team lives in all day — scheduling, inventory, case management, approvals — shaped around how the work runs on a bad day as well as a good one.
-
Line-of-business applications
Software that carries one critical process end to end, from intake to record, with the validation and traceability the people accountable for it need before they will sign anything off.
-
Legacy modernisation
Establishing what the current software genuinely does, writing it down, then moving it forward in stages — so the knowledge stops living in one head and the business keeps trading throughout.
-
Systems integration
Getting the finance system, the CRM and the warehouse to agree on what a customer and an order are, with reconciliation for the days they disagree — and they will disagree.
-
Reporting people trust
One definition per number, computed in one place, with the lineage visible. Most reporting arguments are definition arguments wearing a dashboard.
-
Handover and long-term care
Environments, pipelines, runbooks and credentials given to your team — whether they take the system over entirely or keep us alongside them for the next phase of it.
Technologies
A short list, chosen on purpose.
We work from a small set of mature tools and choose per problem, never per fashion. When the boring option is the right one, we will say so.
Application
Data
Interface
Platform
Process
How a build actually runs.
- Step 01
Sit with the process
We watch the job being done and read the spreadsheets people built to survive it. Requirements tend to hide in those files, several layers below the brief.
- Step 02
Agree the domain in writing
Entities, states, rules and the vocabulary your team already uses, settled before code is written. Disagreement is cheap here and ruinous three months in.
- Step 03
Prove it with a thin slice
One complete path through the system — real data, real authentication, deployed where you can open it. Architecture is proven by something running; a diagram proves nothing.
- Step 04
Widen with users in the room
Capability lands in short cycles and goes in front of the people who will use it daily, because "that is not how we do it" is worth hearing early.
- Step 05
Cut over deliberately
Data migrated and checked against the records it came from, the old system retired on a date instead of left running just in case, and your team trained on what they now own.
Tell us what does not fit.
Describe the process, the system you are working around, and where it hurts. We will tell you whether custom software is the right answer — including when it is not.