Services
Software built for the process you actually have.
When the product doesn't fit, and the workaround has become the process.
Symptoms, not specifications
Where this usually starts
Custom software is rarely the first idea. It tends to arrive after these.
- A spreadsheet has quietly become a system, and three people are careful with it.
- You bought the platform, then built a process around what it could not do.
- The quote, the approval or the calculation lives in one person's head.
- An Access database from a decade ago runs something you cannot switch off.
- Every new job means the same twenty minutes of copying between screens.
- The off-the-shelf option costs less than the customisation it would need.
Where we help
What this covers
Web applications and internal tools
The operational systems that don't exist off the shelf: portals, quoting and pricing tools, approval workflows, operations dashboards.
Platform extension
Custom modules, components and apps that extend HubSpot, Salesforce or your CMS rather than sitting beside it. Extending what you own beats adding a system to reconcile against it.
API and service development
Documented, versioned and monitored services other systems can rely on, including the ones your partners and clients will build against.
Website and CMS development
WordPress, Framer and HubSpot CMS builds with search visibility, performance and accessibility handled at build time rather than retrofitted.
Modernisation
Replacing spreadsheets, Access databases and end-of-life systems without losing the institutional logic buried inside them: the exceptions and edge cases that made the old thing work, not just its data.
Built into what you already run
New software that reads from and writes to your CRM, finance system and document store, rather than becoming a sixth place someone has to check.
What actually changes
We are usually replacing a person, a spreadsheet and a habit.
The gap between two systems gets filled by whoever is closest to it. That bridge is invisible on an org chart, undocumented, and load-bearing. Custom software earns its cost when it takes the bridge over completely, keeping the judgement calls with a person and taking the re-keying away from them.
What we build most often
Custom does not mean unusual. Most of what we build falls into a handful of shapes, which is why we can scope them honestly.
Quoting and pricing tools
The rules, the discount bands and the approval thresholds that currently live in a spreadsheet and a senior person's memory.
Approval workflows
Multi-step approvals with delegation, escalation and an audit trail that answers who approved what, when, on what information.
Client and partner portals
A place for the people outside your business to submit, track and retrieve, instead of emailing someone inside it.
Operations dashboards
The daily operating picture assembled from several systems, with each number traceable back to where it came from.
Compliance and audit records
Evidence captured as work happens rather than reconstructed the week before an audit.
Document and form processing
Intake, classification and extraction where the inbound work arrives as PDFs, photos and attachments rather than clean data.
How we keep it yours
The risk with custom software is not the build. It is being unable to leave the people who built it.
Your repository, your licence
Code lives in your source control from the first commit, not ours. You own it outright, with no per-seat charge for software you paid to have written.
A standard stack, deliberately
Mainstream frameworks another team could pick up, rather than a proprietary platform that makes us the only people who can maintain it.
Your infrastructure
Deployed into your cloud accounts and your tenancy by default, so hosting is not a hostage.
Documented handover
How to run it, deploy it, and fix the three things most likely to go wrong. Written for whoever inherits it, including a team that is not us.
Build or buy
We would rather configure something you already own than invoice you to build it again. Custom is the right answer when the process is what makes you money, or when nothing on the market models it. It is the wrong answer when it is being used to avoid changing a habit.
On your side of the table
What you actually receive
You own the output, not a licence to it. That covers the code, the deployment and enough documentation for another team to take it over.
- A process map that includes the exceptions, not just the happy path
- A working prototype against realistic data before build funding is committed
- Source code in your repository, owned outright, with no lock-in
- Automated tests over the rules that carry money, legal or compliance weight
- Deployment you can run yourselves, in your own cloud accounts
- Documented handover, written for a team that is not us
- A named support path with an agreed response time
Delivery lifecycle
How an engagement runs
Map the real process
Including the exceptions experienced people handle without noticing they are exceptions.
Prototype
A working screen against realistic data, so you fund the build having seen it rather than having read about it.
Build in slices
Usable increments with acceptance criteria at each milestone, not one delivery date at the end.
Hand over
Documentation, code, credentials, deployment and a support path. Handover as a deliverable, not a meeting.
Realistic timelines
A working prototype usually takes three to four weeks. A first production release commonly lands eight to fourteen weeks after that, and the range is driven by how many exceptions the real process contains, which is nearly always more than the original brief admitted.
How we build
- Scoped in writing
- Milestone-based delivery with acceptance criteria
- Code and artefacts yours outright
- Documented handover
- A named support path
Frequently asked
Questions buyers actually ask
Who owns the code once it's built?
You do, outright. Code lives in your repository from the first commit, deployment runs in your own cloud accounts, and every engagement includes a documented handover. There is no lock-in and no per-seat charge for software you paid to have written.
Can you build the website itself, not just the backend systems?
Yes. Website and CMS development (WordPress, Framer, HubSpot CMS) is part of this service, built with search visibility, performance and accessibility handled at build time rather than retrofitted afterwards.
What if we're replacing an old Access database or spreadsheet system?
That's a common starting point. We modernise these without losing the institutional logic buried inside them: the exceptions and edge cases that made the old system work, not just its data.
How do you stop the scope running away?
By prototyping before we build, and by delivering in slices with acceptance criteria attached to each one. Scope changes are priced as changes rather than absorbed silently, so the conversation happens while it is still a decision.
Should we build this at all, or configure something we already own?
Ask us before you commit. We regularly finish a discovery by recommending configuration of a platform a client already licenses, and we would rather give that answer in week two than build the wrong thing well.
What happens after launch?
A named support path with an agreed response time, and the option of an ongoing arrangement for enhancements. The handover is written so you are not obliged to take it, including the parts that let another team maintain the code.
Further reading
We've written this argument out at length.
Some of the organisations we work with
Start with a conversation, not a proposal.
Tell us the problem. We’ll tell you honestly whether it’s worth solving, and what solving it would take.