Capability
Custom software
Software built around a process that no off-the-shelf product fits, delivered with the source and documented well enough for someone else to pick up.
Most businesses reach this point the same way. A process grew up around a spreadsheet, then around three spreadsheets and an inbox, and the workarounds now cost more time than anyone wants to add up. The available products each solve a different problem, or solve this one for an organisation ten times the size at a price to match.
What we build is the thing that fits the process you actually run. Not a configuration of somebody else's product, and not a rewrite of how you work to suit the software.
What this typically looks like
Systems we build
- Internal back-office tools: clients, jobs, quoting, invoicing, scheduling, records.
- Compliance and record-keeping software where a document has to stand up to inspection later.
- Multi-tenant web platforms where several separate businesses use one system and must never see each other.
- Desktop applications holding data locally, with no hosting and nothing leaving the building.
- Front-ends layered over systems you already run, where the data is fine and the interface is the problem.
- Document generation, where output has to be accurate, consistent and accessible.
What comes with it
- A written scope stating what is included and what is deliberately not.
- Working software at the end of each phase rather than a status report.
- Source code and documentation, with ownership set out in the contract.
- Installer and a written guide for desktop tools.
- Accounts and credentials in your name, not ours.
- An accessibility check before handover, included as standard.
Evidence
Things we have actually finished
Rather than describe our approach in the abstract, the five tools under Software are ours, which means we can be specific about how each is built without any client's commercial confidence getting in the way. Each page sets out the design decisions and the limits.
Two are compliance products where a document has to survive being read back months later by someone looking for a problem. One is a multi-tenant platform being built with its first customer. One is the back office this business runs on every day, which is a harder test than a demo.
Where we will tell you not to
Custom software is a commitment. It has to be maintained, and someone has to understand it. There are cases where it is the wrong answer, and we would rather establish that during scoping than after delivery.
Reasons we have talked people out of a build
- An existing product does the job well enough, and the gap is smaller than the cost of owning software.
- The process itself is unsettled, so anything built now would be rebuilt within a year.
- The real problem is a reporting question that a better view of existing data would answer.
- Nobody internally will own it after handover, which makes a subscription the safer answer.
Questions we get asked
How do you decide whether something should be custom at all?
The first question in every scope is whether an existing product does this well enough. Custom software carries a maintenance obligation that a subscription does not, so it has to be worth that. If a product on the market fits, we will tell you which one, and that ends the conversation without an invoice.
Desktop or web?
It depends on where the data has to live and who needs to reach it. A local desktop tool keeps everything on your own machines with no hosting bill and no data leaving the building, which suits records you would rather not put in someone else’s cloud. A web application suits work where several people or several sites need the same view. We will recommend one and explain the trade, rather than defaulting to whichever is easier to build.
What do we actually receive at the end?
The running software, the source code, the documentation, and whatever accounts and credentials it depends on, in your name. For desktop tools that includes an installer and a written getting-started guide. Ownership is in the contract.
What if requirements change during the build?
They usually do. Small things get absorbed. Anything that changes the shape gets re-quoted in writing before it is built, so the change is a decision you make rather than a surprise on the final invoice.
Do you build things that handle payments?
We build ordering, quoting and invoicing. Taking card payments inside a platform brings regulatory obligations that are rarely worth it for a business this size, so our usual recommendation is to keep money out of the software and let an established provider handle it. We took exactly that decision on our own trade platform.
How do you handle personal data?
Where a system holds personal data we work out who is controller and who is processor before the build starts, because it changes what the software has to do. Where we act as processor a data processing agreement has to be in place before it goes live. We will raise this early rather than at handover.
Start with a conversation
Tell us what the system has to do and what it has to work alongside. You will get a written scope and a price before anything is committed, and your enquiry goes straight to the person who would build it.