Internal Tools & Business Systems
Custom Software Development
Some requirements have no product behind them. When a process is specific to how your business runs, and the spreadsheet holding it together has started to creak, a system built around that process usually costs less over a few years. We build those \u2014 and we will tell you when you do not need one.
Deciding factors
Worth It, or Not Yet
Commissioning software commits you to maintaining it, not just to building it. That is worth taking on when the alternatives cost more, and worth deferring when they do not.
Building your own is usually justified when
- Four people edit the same spreadsheet and nobody can say which copy is the real one.
- The same figure gets typed into three systems, and when they disagree there is no rule for which wins.
- Every product you trialled needed a workaround, and the workarounds now have workarounds.
- Somebody rebuilds the same report by hand every month because nothing on the market produces that particular view.
- What you have works, but it cannot be extended and the person who wrote it stopped answering emails.
- Per-seat licence cost has grown faster than anything you get out of the product.
Buying or waiting is the better decision when
- A supported product already does this and the gaps are preferences, not obstacles.
- The process is still changing every month. Writing it into code now just makes the next change expensive.
- It is a solved problem. Accounting, payroll and statutory filing get bought, not written, and whoever says otherwise is selling you hours.
- One person needs it, and a well-built spreadsheet or a properly configured off-the-shelf tool would genuinely do.
- Nobody on your side will own it after launch 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 Pieces
What most builds are assembled from. A given project uses several of these and almost never all of them.
Internal Business Tools
Software for your own staff, not your customers. Enquiry registers, stock books, dispatch logs, approval queues — the quiet systems a business actually runs on and that no general product ever quite fits. Usually the smallest builds, and usually the fastest to pay for themselves.
Workflow & Operations Systems
Software that carries a job from first entry to final sign-off and records who moved it and when. The rules about who may approve what sit in the system instead of in one long-serving employee’s head, and “where has this got to?” becomes a screen rather than a phone call.
Admin & Reporting Panels
The back half: 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 beneath it — which sounds obvious until you meet a system where it does not.
API & Integration Layers
The joins that let your systems trade data with each other and with the outside services you depend on. Versioned endpoints, payloads checked at the boundary, and documentation good enough that the next developer is not working out the behaviour by trial. Failures get logged and handled rather than quietly swallowed.
Database Design
The data model is settled before a single screen is drawn, because it is the part that is ruinous to change afterwards. Tables, relationships, constraints and indexes are shaped around the questions you will actually ask of it. Migrations are written and versioned like everything else.
System Modernisation
Software that already exists and still matters: an ageing application, an inherited codebase, something stuck on a platform version that stopped getting security updates. We read what is there before proposing anything, and move in stages — the business still has to run while the work happens.
Technical Documentation
A written account of how the thing fits together: data model, environment setup, deployment steps, interface reference, and why the decisions that mattered were made. Written as the work happens, not reconstructed from memory afterwards. This is the part that makes a real handover possible.
Ongoing Enhancement
Software in use is software that needs changing. After launch we can carry on with corrections, small additions, and the dependency and platform updates that keep it supportable. What that covers gets written down rather than assumed.
Before any code
Getting to a Specification
Projects fail long before anyone opens an editor, normally because both sides nodded at the same sentence while picturing different things. This is the work that catches that.
- 01
Talk to the people who use it
Not only whoever signs off the budget. The person doing the job daily knows the exceptions, and exceptions are what break an otherwise sensible design.
- 02
Write down what happens now
How the process really runs today, informal workarounds included. Seeing it written down frequently changes what people want built — and changing your mind here costs a conversation rather than a rebuild.
- 03
Pin down the data
What the system stores, how the records relate, and which fields are genuinely required. This is usually where two departments find out they have been using one word to mean two different things, which is much better discovered now.
- 04
Define the first usable version
What version one has to do to be worth putting in front of staff. The list is kept deliberately short, so the system becomes useful early instead of arriving complete, late and resented.
- 05
Write down what is excluded
What has deliberately been left out is recorded next to what is in. An unwritten assumption becomes an argument later; 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
Tools for This
Decided against what it has to do, where it has to run, and who is 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
Spec to Something in Use
The same four stages as any other build here. Each one ends with something you can open, read or click rather than a status update.
- 01
Work Out the Job
We spend time with whoever does the task today, write down what actually happens, and agree what the software is supposed to change. Numbers come after that, not before.
- 02
Settle the Shape
Screens, data and structure are decided first, then split into milestones small enough that "is it finished?" has an obvious answer.
- 03
Build in the Open
Work arrives in reviewable pieces, tested as it goes — the normal path, the awkward cases, and how it holds up on an older phone and a poor connection.
- 04
Release and Stay
We publish it, hand over the repository and the notes that explain it, and remain reachable for fixes, releases and whatever comes next.
Next step
Process Outgrown Its Spreadsheet?
Describe how the work runs now and where it is coming apart. You will get a straight answer on whether building is the right call, and what it would take.