Software

Custom Software

Built for the process you actually run

How this is usually engaged

Phased. A first release covering the workflow with the most value at stake, then extension informed by real usage. The first phase is usually fixed-scope over eight to sixteen weeks; later phases work better as a rolling arrangement, because by then you know things about the problem that neither of us knew at the start.

Start a project brief

Practice: Software Engineering
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Applications designed around your operation rather than around a product's assumptions, with the domain rules written down, enforced on the server and covered by tests.

01What this solves

The problem this addresses

Organisations usually reach custom software after two failures. The product they bought forced them to change how they work, and the change cost more than the licence saved. Then a member of staff built something in a spreadsheet or a low-code tool to cover the gap, and now a business-critical process depends on one person and a file nobody else understands. Neither situation is a tooling problem. Both are the result of the operating rules never having been written down anywhere a system could enforce them.

02Capabilities

What is included

Domain modelling

Entities, states, transitions and the conditions attached to each, agreed with the people who perform the work. This is the deliverable that outlives the code, and it is written in language your team uses rather than ours.

Business rule enforcement

Rules implemented on the server, in one place, with the system able to explain why it refused an action. Rules scattered across form validation and user habit are not rules.

Role and permission design

Access defined as data — roles, permissions and record-level scoping — so it can be audited and changed without a release, and so a leaver's access can be evidenced as removed.

Automated testing

Unit tests for the domain rules and end-to-end tests for the paths that would cost you money if they broke. The suite runs on every change, which is what makes later modification affordable.

Data migration

Getting existing records out of spreadsheets, legacy databases and retiring products, with validation, a dry-run mode and a reconciliation report you sign off before cutover.

Reporting and audit

Operational reporting and an append-only history of who changed what and when, designed for the data volume you will have in three years rather than the volume you have now.

03Use cases

Where this work usually starts

Replacing a process held together by spreadsheets

A workflow that runs the organisation but lives in files with no permissions, no history and one person who understands the formulas.

Professional Services

A product that fits most of the work

The part it does not cover is the part that differentiates you, and it currently runs on email, manual re-keying and institutional memory.

Logistics & Transport

Rebuilding an application nobody will touch

Software that still works but has no tests, no documentation and an original author who left. Every change is a gamble, so changes stopped being made.

04Approach

How we approach it

We start by getting the domain out of people's heads and into a model: the entities, the states they move through, who is allowed to cause each transition, and what must be true before it happens. That model is enforced on the server and covered by tests, so the rules survive staff turnover and later changes. The interface is then designed around the handful of tasks people perform dozens of times a day, at the density those tasks need, rather than around a demo path.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Process mapping
The work as it is genuinely performed, including the workarounds people invented and do not mention in meetings.
02
Domain design
The model written down and reviewed with the people who will live with it, before any interface is drawn.
03
Interface design
Designed at real density against real records, for the tasks repeated most often.
04
Iterative build
Working software in an environment you can open, reviewed on a fixed cadence rather than at milestones.
05
Migration and cutover
Dry run, reconciliation, agreed discrepancies, then cutover with a rollback path.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Domain and permission modelEntities, states, transitions and access rules, documented in plain language.
Working application and administration interface
Automated test suiteDomain rule tests and end-to-end coverage of the paths that matter commercially.
Migration tooling and reconciliation report
Deployment pipeline, monitoring and alerting
Repository, runbook and handover session

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript
Node.js

Data & Storage

PostgreSQL
Prisma

DevOps & Operations

Docker
GitHub Actions
Sentry

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Authorisation is checked on the server for every request, against the acting user's role and their relationship to the specific record. Input is validated against a schema at the boundary before it reaches business logic. Secrets live in a managed store rather than in configuration files, dependencies are scanned on every build, and actions that change money, permissions or personal data are written to an append-only audit log.

Our full security and quality approach

09Questions

Asked before we start

How do we know custom is the right answer?

Often it is not, and we will tell you when a supported product would cover the work for a licence fee. Custom earns its cost when a product would force you to change something that is genuinely part of how you compete, when integration and workaround effort has overtaken the build cost, or when no product models your domain at all. If your requirements list reads like a description of an existing product, buy the product.

What happens if we want to move to another supplier?

You own the repository, the pipeline, the infrastructure definitions and the documentation from the first commit, not at the end. We keep the stack ordinary and widely used for exactly this reason. A competent team should be able to pick the project up from the repository alone, and if they cannot, we have not finished.

Can you work to a fixed price?

For a defined first phase, yes, once discovery has told us what we are actually building. For open-ended work a fixed price only holds if the scope is frozen, and frozen scope on software you have never used before usually means paying for the wrong thing precisely. We would rather agree a budget and a review cadence.

Who owns the intellectual property?

You do, for everything written for you, assigned on payment. Third-party open source components keep their own licences, and we list those with their terms so your legal team can review them. We do not retain reusable modules in your codebase that we then licence back to you.

START HERE

Talk to us about Custom Software

The project brief takes about five minutes and gives us enough to have a useful first conversation about Custom Software rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.