Services
Custom Builds / Integrations
Technical work that does not fit a template.
Some problems are specific enough that a productised service is the wrong answer. The systems are unusual, the data flows are non-standard, the constraints are particular to your organisation. This service covers that work — scoped per engagement, priced per scope, delivered with the same documentation and handover discipline as every other service.
What you get
Every custom engagement is different. The scope is defined before work begins. Typical deliverables include some combination of:
- Working software or integration — A deployed, tested system against the agreed specification. The definition of "done" is agreed upfront and confirmed at handover, not left open.
- Technical specification — Documentation of what was built, the decisions made, and the reasoning behind them. Written so that another engineer can pick it up.
- Integration documentation — How the system connects to what it connects to: authentication, data formats, API contracts, error handling.
- Operational runbook — Procedures for operating, monitoring, and recovering the system. What to check when it behaves unexpectedly. How to update it. What the dependencies are.
- Handover session — A working session with the people who will own it. Not a slide presentation — a working walkthrough of what was built.
Typical engagements: connecting two systems that were not designed to talk to each other; migrating data from one platform to another with custom conversion logic; building a tool that exists nowhere off the shelf; replacing a critical dependency that is end-of-life; extending an existing system in a way the original vendor did not anticipate.
Process
- 1
Scoping call (30 minutes)
We listen to the problem, ask specific questions, and establish whether it is the kind of work we take on. We will tell you if it is not.
- 2
Technical scoping (paid, fixed-fee)
For complex builds, the first deliverable is a technical specification: what we would build, how, and what it will cost. This protects both sides from a build that starts before the problem is properly understood.
- 3
Build agreement
Fixed scope, fixed price, defined timeline. Signed before the build begins. Changes to scope are handled as explicit change requests, not absorbed.
- 4
Build, test, and documentation
Built against the agreed specification, tested, fully documented.
- 5
Handover session
The engagement closes when you can operate the system independently.
When it is the right fit
You should book a scoping call if:
- There is a specific technical problem that you cannot address with an off-the-shelf product, and you need someone who can build the thing rather than recommend a SaaS.
- Two systems that vendors tell you cannot be connected (or can only be connected by purchasing an additional product you do not want) need to talk to each other.
- A platform migration where the data export is more complex than a CSV.
- A bespoke tool built by someone who has left, that needs extending, documenting, or replacing.
Fixed scope. Fixed price. No day rates.
The constraint that produces good custom work is a properly agreed scope. We put effort into the scoping stage specifically because it makes the rest of the engagement predictable. You know what you will get and what it will cost before work begins. If the scope changes, that is an explicit conversation — not a surprise invoice.
Book a scoping call
30 minutes. No obligation. We will tell you if it is not a fit.
Book a scoping call