Internal Tools & Business Systems
Custom Software Development
Some requirements have no product that fits them. When a process is specific to the way your business runs, and the spreadsheet holding it together has stopped coping, a system built around that process is usually the more sensible long-term answer. We build those systems, and we say so plainly when one is not needed.
Deciding factors
When Custom Software Is the Right Answer
Custom software is a commitment to maintenance as much as to a build. It is worth making when the alternatives cost more, and it is 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 information is re-keyed into two or three systems that have no way of talking to each other.
- The process is particular to how you operate, and every product trialled so far needs a workaround to fit.
- Reporting is assembled by hand each month because no existing tool can produce the view you need.
- A system that works cannot be extended, and the people who originally built it are no longer available.
- 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 changing week to week, so building now would fix in code something that has not settled.
- The requirement is genuinely standard. Accounting, payroll and statutory filing are better bought than written.
- One person needs it, and a shared document or a better-configured existing tool would do the same job.
- Nobody inside the business is able to own the system once it is live, and no support arrangement is planned.
Worth saying plainly. We would rather tell you in the first conversation that an existing product already covers your requirement than take on a build that should not happen. A project that starts on a false premise is expensive for both sides, and the cost lands on you long after the invoice.
Capabilities
What We Build
The kinds of work that make up most custom software engagements. A single project usually draws on several of them at once, and rarely on all.
Internal Business Tools
Software for the people inside your organisation rather than for customers. Enquiry registers, stock records, dispatch logs, approval queues: the quiet systems a business actually runs on, which no public product ever quite matches. They are usually the smallest builds and the first to repay the effort.
Workflow & Operations Systems
Systems that carry a job through its stages, from first entry to final sign-off, with a record of who did what and when. Rules about who may move an item forward are enforced by the software instead of being remembered by staff. Status becomes something anyone can look up rather than something they have to ask about.
Admin & Reporting Panels
The administrative half of an application: accounts, roles and permissions, search across records, bulk actions and exports. Reports read from the same tables the operational screens use, so a summary figure always reconciles with the records behind it. Access is scoped to what a role genuinely needs.
API & Integration Layers
Interfaces that let your systems exchange data with each other and with the third-party services you depend on. Endpoints are versioned, validated at the boundary and documented, so whoever integrates next is not reverse-engineering behaviour. Failures are logged and handled deliberately rather than passing unnoticed.
Database Design
The data model is settled before the screens, because it is the part that costs most to change later. Tables, relationships, constraints and indexes are designed around the questions the business will ask of the data. Migrations are written and versioned, so a schema change is reviewed like any other code.
System Modernisation
Work on software that already exists and still matters: an ageing application, an inherited codebase, or a system pinned to a platform version that is no longer supported. We read what is there before proposing anything, then move in stages so the business keeps operating while the work goes on.
Technical Documentation
A written account of how the system fits together: data model, environment setup, deployment steps, API reference and the reasoning behind the significant decisions. It is written as the work happens rather than reconstructed at the end. It is what makes a handover to your own team possible.
Ongoing Enhancement
Software that is used is software that will need changing. After launch we can continue with corrections, small additions and the dependency and platform updates that keep an application supportable. What that covers is agreed in writing rather than left as an assumption.
Before any code
How a Requirement Becomes a Specification
Builds go wrong long before the first line of code, usually because both parties agreed on a sentence and pictured different things. This is the work that prevents it.
- 01
Discovery conversations
We talk to the people who will use the system daily, not only to whoever commissions it. The person doing the work knows the exceptions, and the exceptions are what break an otherwise sensible design.
- 02
Write down the current process
The existing process is recorded as it genuinely runs, manual steps and informal workarounds included. Seeing it written down often changes what people want built, and changing your mind at this stage costs a conversation.
- 03
Identify the data model
We establish what the system has to store: the records, how they relate, and which fields are truly required. Disagreements about vocabulary surface here, where they are a discussion rather than a rebuild.
- 04
Agree the first working version
We define what the first usable version must do to be worth putting in front of staff. It is a deliberately short list, chosen so the system starts earning its place early instead of arriving complete and late.
- 05
Name what is out of scope
Everything considered and deliberately left out is written down beside what is included. An unrecorded assumption turns into a dispute; a recorded exclusion stays a decision, and can be revisited on purpose.
What comes out of it is a short written document: what the system does, what it stores, who may do what inside it, what it deliberately will not do, and the technical approach. Nothing of consequence is agreed on a call alone.
Technology
What These Systems Are Built With
Choices are made per project, weighed against the requirement, where the system has to run, and who will maintain it after launch.
- 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 on every engagement. Each one ends with something you can look at and sign off, rather than a status update.
- 01
Discover
Understand requirements, business objectives, users and technical needs.
- 02
Design & Plan
Define user experience, technical architecture, milestones and implementation plan.
- 03
Develop & Test
Build using maintainable code while testing functionality, usability and performance.
- 04
Launch & Support
Deploy the finished product and provide continued maintenance and improvement when required.
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 whether a custom build is the right answer, and what building it would involve.