Internal Tools & Business Systems
Custom Software Development
Some requirements have no product that fits them. Where a process is particular to how you work, and the spreadsheet holding it together has begun to creak, a system built around that process is usually cheaper across a few years. We build those, and we will say plainly when you do not need one.
Deciding factors
When Custom Software Is the Right Answer
Commissioning custom software commits you to maintaining it, not merely to building it. Worth doing when the alternatives cost more, and worth postponing when they do not.
Building your own is usually justified when
- The work runs on spreadsheets that several people edit, and nobody is certain which copy is current.
- The same numbers are entered in three places and nobody can say which copy is authoritative.
- Each product you have trialled required a workaround, and those workarounds now require workarounds of their own.
- Someone loses two days a month rebuilding the same report by hand because nothing on the market produces that view.
- It works, but it cannot be extended, and whoever wrote it is no longer contactable.
- Per-user licence costs have grown faster than the value taken from the product.
Buying or waiting is the better decision when
- A well-supported product already covers the requirement, and the gaps are preferences rather than obstacles.
- The process is still shifting month to month. Fixing it in code now only makes the next revision costly.
- It is already solved. Accounting, payroll and statutory filing are bought rather than written, and anyone arguing otherwise is selling you hours.
- A single person needs it, and a well-built spreadsheet or a properly configured off-the-shelf tool would genuinely serve.
- No one on your side can own it after launch and no support arrangement is planned. Software in that position is abandoned within the year.
Worth saying plainly. We would rather lose the work in the first conversation than accept a build that should not go ahead. A project founded on a false premise is expensive for both parties, and you are the one still paying for it long after the invoice is settled.
Capabilities
What We Build
What most custom builds consist of. A given project usually draws on several of these at once and very rarely on all.
Internal Business Tools
Software for your own staff rather than your customers. Enquiry registers, stock books, dispatch logs, approval queues: the quiet systems an organisation actually runs on, which no general product ever quite fits. They are usually the smallest builds and the quickest to repay their cost.
Workflow & Operations Systems
Software that carries a job from first entry to final approval and records who did what and when. The rules about who may advance something live in the system rather than in one long-serving employee's memory, and the status of anything becomes a screen instead of a phone call.
Admin & Reporting Panels
The administrative half: accounts, roles, permissions, search, bulk operations and exports. Reports read the same tables the working screens use, so a total always reconciles with the records beneath it. That sounds obvious until you meet a system where it does not hold.
API & Integration Layers
The connections that let your systems exchange data with each other and with the outside services you rely on. Versioned endpoints, payloads validated at the boundary, and documentation good enough that the next developer is not inferring behaviour by trial. Failures are logged and handled rather than quietly swallowed.
Database Design
The data model is settled before any screen is drawn, because it is the part that is ruinous to revise later. Tables, relationships, constraints and indexes are shaped around the questions you will genuinely ask. Migrations are written and versioned like any other code.
System Modernisation
Software that already exists and still matters: an ageing application, an inherited codebase, something pinned to a platform version that no longer receives security updates. We read what is there before proposing anything and move in stages, because the organisation still has to operate while we work.
Technical Documentation
A written account of how it fits together: data model, environment setup, deployment procedure, interface reference, and the reasoning behind the decisions that mattered. Produced as the work happens rather than reconstructed from memory at the end. This is what makes a genuine handover possible.
Ongoing Enhancement
Software that is used is software that needs changing. After launch we can continue with corrections, small additions and the dependency and platform updates that keep it supportable. What that covers is set down in writing rather than assumed.
Before any code
How a Requirement Becomes a Specification
Projects go wrong well before anyone writes code, usually because both sides agreed to the same sentence while imagining different things. This is the work that prevents it.
- 01
Discovery conversations
We speak to the people who will use it daily, not only to whoever approves the budget. The person doing the work knows the exceptions, and exceptions are what break an otherwise sensible design.
- 02
Write down the current process
We record how the process genuinely runs today, informal workarounds included. Seeing it written down often changes what people want built, and changing your mind at this point costs a conversation rather than a rebuild.
- 03
Identify the data model
We establish what the system stores: the records, how they relate, and which fields are genuinely required. This is usually where two departments discover they have been using one word for two different things, which is far better found now.
- 04
Agree the first working version
We agree what the first usable version must do to be worth putting in front of staff. The list is deliberately short, so the system becomes useful early instead of arriving complete, late and resented.
- 05
Name what is out of scope
What has been deliberately excluded is recorded alongside what is included. An unwritten assumption turns into a disagreement later; a written exclusion stays a decision and can be reopened deliberately.
The result is a short written document: what the system does, what it stores, who may do what within it, what it deliberately will not do, and how it will be built. Nothing of consequence is agreed on a call alone.
Technology
What These Systems Are Built With
Decided per project, against what it must do, where it has to run, and who will be maintaining it a year from now.
- Backend Development
- Node.js
- PHP
- Laravel
- REST APIs
- Databases
- MySQL
- PostgreSQL
- Firebase
- Frontend Development
- React
- Next.js
- TypeScript
- JavaScript
- HTML5
- CSS3
- Tailwind CSS
- Cloud & Infrastructure
- AWS
- Google Cloud
- Firebase
- Development Tools
- Git
How we work
From Specification to a System in Use
The same four stages as every other build here. Each finishes with something you can open, read or click rather than a progress report.
- 01
Discover
We sit with the people doing the job, map what happens now, and agree what the software is meant to change. No figure is quoted before that exists on paper.
- 02
Design & Plan
Screens, data and architecture are settled first, then cut into milestones small enough that you can tell whether each one is genuinely finished.
- 03
Develop & Test
We build in reviewable increments and test as we go: the ordinary path, the awkward cases, and how it behaves on modest hardware and a patchy network.
- 04
Launch & Support
We publish it, hand across the repository and the notes that explain it, and stay reachable for corrections and whatever you want built next.
Next step
Have a Process That Needs a System?
Describe how the work runs today and where it is breaking down. We will tell you honestly whether a custom build is the right answer and what it would involve.