Internal Tools & Business Systems
Custom Software Development
Some requirements have no product that fits. When the process is particular to how you work, and the spreadsheet holding it together has started to creak, a system built around that process is usually the cheaper answer over a few years. We build those — and we will tell you plainly when you do not need one.
Deciding factors
When Custom Software Is the Right Answer
Commissioning custom software is a commitment to maintaining it, not just to building it. Worth doing when the alternatives cost more; 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 figures get typed into two or three places, and nobody is quite sure which one is right.
- Every product you have trialled needed a workaround, and the workarounds have started needing workarounds.
- Somebody spends two days a month rebuilding the same report by hand because no tool produces that view.
- The system works, but it cannot be extended and whoever wrote it is long gone.
- 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 month to month. Writing it into code now just makes the next change expensive.
- It is a solved problem. Accounting, payroll and GST filing are bought, not written, and anyone telling you otherwise is selling hours.
- One person needs it, and a well-built spreadsheet or a properly configured existing tool would genuinely do.
- Nobody on your side can own it after launch, and no support arrangement is planned. That system will be abandoned within a year.
Worth saying plainly. We would rather lose the work in the first conversation than take on a build that should not happen. A project founded on a wrong premise is expensive for both of us, and you are the one still paying for it long after the invoice is settled.
Capabilities
What We Build
The work that makes up most custom builds. A given project usually needs several of these at once and almost never all of them.
Internal Business Tools
The software your staff use, not your customers. Enquiry registers, stock books, dispatch logs, approval queues — the quiet systems a business genuinely runs on and that no off-the-shelf product ever quite fits. These are usually the smallest builds and the first to pay for themselves.
Workflow & Operations Systems
Software that walks a job from first entry to final sign-off and records who did what, when. The rules about who can push something to the next stage live in the system rather than in one experienced employee’s memory. “Where has that reached?” becomes a screen instead of a phone call.
Admin & Reporting Panels
The administrative half: accounts, roles, permissions, search, bulk actions, exports. Reports read the same tables the working screens do, so a total always reconciles with the rows underneath it — which sounds obvious until you meet a system where it does not.
API & Integration Layers
The plumbing that lets your systems talk to each other and to the outside services you depend on. Versioned endpoints, payloads validated at the boundary, and real documentation so the next developer is not guessing from behaviour. Failures get logged and handled, not swallowed.
Database Design
We settle the data model before drawing screens, because it is the part that is ruinous to change later. Tables, relationships, constraints and indexes are shaped around the questions you will actually ask of the data. 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 stopped getting security updates. We read what is there before proposing anything, then move in stages, because the business still has to run on Tuesday.
Technical Documentation
A written account of how the thing fits together: data model, environment setup, deployment steps, API reference, and why the significant decisions went the way they did. Written as we go rather than reconstructed from memory afterwards. This is what makes a real handover possible.
Ongoing Enhancement
Software that gets used is software that needs changing. After launch we can carry on with fixes, small additions and the dependency and platform updates that keep it supportable. Exactly what that covers is written down, not assumed.
Before any code
How a Requirement Becomes a Specification
Projects fail long before anyone writes code, usually because both sides nodded at the same sentence while picturing different things. This is the work that stops that happening.
- 01
Discovery conversations
We talk to the people who will use it every day, not only to whoever signs the cheque. The person doing the work knows the exceptions, and it is always the exceptions that break a sensible-looking design.
- 02
Write down the current process
We write down how the process genuinely runs today, informal workarounds included. Seeing it on paper frequently changes what people want built — and changing your mind here costs a conversation rather than a rebuild.
- 03
Identify the data model
We pin down what the system stores: the records, how they relate, which fields are genuinely mandatory. This is where two departments discover they have been using the same word for different things, which is much 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 starts being useful early rather than arriving complete, late and disliked.
- 05
Name what is out of scope
What we have deliberately left out is written down next to what is included. An unrecorded assumption becomes an argument later; a recorded exclusion stays a decision, and can be revisited on purpose.
The output 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 how it will be built. Nothing that matters gets agreed on a phone call alone.
Technology
What These Systems Are Built With
Decided per project, 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
From Specification to a System in Use
The same four stages as every other build here. Each ends with something you can open, read or click, rather than a progress report.
- 01
Discover
We learn how the work is done today, who does it, and what the software actually has to change. Nothing is estimated before this is written down.
- 02
Design & Plan
Screens, data model and architecture are agreed on paper, then broken into milestones you can recognise and sign off individually.
- 03
Develop & Test
Code is written in reviewable pieces and tested as it goes — behaviour, edge cases, and how it holds up on a mid-range phone or a slow connection.
- 04
Launch & Support
We handle the release, hand over the code and the documentation, and stay available for fixes and the next round of changes.
Next step
Have a Process That Needs a System?
Describe how the work runs today and where it is falling over. We will tell you honestly whether a custom build is the right answer, and what it would take.