Internal Tools & Business Systems
Custom Software Development
Some requirements have no product behind them. Where a process is particular to your business, and the spreadsheet holding it together is starting to creak, building around that process usually costs less across a few years. We build those \u2014 and say so plainly when you would be better off not.
Deciding factors
Build, or Wait
Commissioning software commits you to maintaining it, not just to building it. That is a good trade when the alternatives cost more, and a bad one when they do not.
Building your own is usually justified when
- The real system is a spreadsheet, several people edit it, and the current copy is whichever one was emailed most recently.
- One figure gets entered into three places, and when they disagree there is no rule for which one wins.
- Every product you trialled needed a workaround, and those workarounds have since acquired workarounds.
- Somebody spends two days a month assembling the same report by hand because nothing available produces that view.
- What you have works but cannot be extended, and whoever wrote it has moved on.
- Per-seat licensing now costs more each year than the value anybody can point to.
Buying or waiting is the better decision when
- A supported product already covers this and the differences are preferences rather than obstacles.
- The process is still being rewritten every month. Fixing it in code now only makes the next revision expensive.
- It is a solved problem. Accounting, payroll and statutory filing are bought, not built, and anyone saying otherwise is selling hours.
- One person needs it, and a carefully built spreadsheet or a properly configured off-the-shelf tool would genuinely serve.
- Nobody on your side will own it afterwards and no support is arranged. Software in that position is abandoned inside a 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
The Components
What a build is normally assembled from. Any one project uses several of these and hardly ever all of them.
Internal Business Tools
Software for your own staff rather than your customers. Enquiry registers, stock books, dispatch logs, approval queues — the unremarkable systems a business actually runs on, which no general product ever quite fits. Normally the smallest builds, and normally the quickest to pay for themselves.
Workflow & Operations Systems
Software that carries a job from first entry through to sign-off, recording who moved it and when. Who may approve what lives in the system rather than in one long-serving colleague’s memory, and the status of anything becomes a screen instead of a phone call.
Admin & Reporting Panels
Accounts, roles, permissions, search, bulk operations, exports. Reports read the same tables the working screens write to, so a total always reconciles with the rows under it — obvious until you have met a system where it does not.
API & Integration Layers
The joins that let your systems exchange data with each other and with the outside services you depend on. Versioned endpoints, payloads validated at the boundary, documentation thorough enough that nobody has to deduce the behaviour, and failures logged rather than quietly swallowed.
Database Design
The data model is settled before a screen is drawn, because it is the part that is ruinous to revisit. Tables, relationships, constraints and indexes are shaped around the questions you will really ask. Migrations are written and versioned like any other code.
System Modernisation
Software that exists already and still matters: an ageing application, an inherited codebase, something pinned to a platform version that stopped receiving security updates. We read it before proposing anything and move in stages, because the business has to keep operating throughout.
Technical Documentation
A written account of how it holds together — data model, environment setup, deployment, interface reference, and why the decisions that mattered went the way they did. Written while the work happens, not reconstructed afterwards. Without it, handover is a fiction.
Ongoing Enhancement
Software that gets used is software that needs changing. After launch we can continue with corrections, additions, and the dependency and platform updates that keep it supportable. What that covers is written down rather than assumed.
Before any code
Turning a Requirement Into a Spec
Projects go wrong long before any code exists, normally because both sides agreed to a sentence while picturing different things. This is the work that catches that while it is still cheap.
- 01
Sit with the people doing it
Not only whoever approves the budget. Whoever does the task daily knows the exceptions, and the exceptions are what break an otherwise reasonable design.
- 02
Record the process as it is
Including the informal shortcuts nobody mentions in a meeting. Written down, it often changes what people want built — and at this stage changing your mind costs a conversation.
- 03
Settle the data
What gets stored, how records relate, which fields are genuinely required. Usually the point at which two departments discover they have been using the same word for different things, which is far better found now than later.
- 04
Agree version one
What the first usable release must do to be worth putting in front of staff. Kept deliberately short, so the system starts being useful early rather than arriving complete, late and unloved.
- 05
Record what is excluded
What has been left out is written alongside what is in. An unwritten assumption turns into a disagreement; a written exclusion stays a decision, and can be reopened on purpose.
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 Use
Decided against what it has to do, where it has to run, and who will be looking after 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
Spec to Daily Use
The same four stages as anything else here, each one closing with something you can open, read or click instead of a progress report.
- 01
Understand
Time with the people who do the task now, writing down what actually happens rather than what the org chart says happens. The gap between those two is where most of the surprises live.
- 02
Write It Down
Screens, data and structure settled on paper, then cut into milestones small enough that whether one is finished is a matter of fact rather than opinion.
- 03
Build
Delivered in pieces you can look at, tested as they go — the ordinary path first, then the awkward inputs, a weak connection and a phone that is several years old.
- 04
Hand Over
Published, with the repository, the credentials and the notes that explain the decisions. We stay reachable for corrections, releases and whatever the next thing turns out to be.
Next step
Has a Spreadsheet Stopped Coping?
Describe how the work runs now and where it is falling over. You will get a straight answer about whether building is the right move, and what it would take.