Internal Tools & Business Systems
Custom Software Development
Some requirements have no product behind them. Where the process is specific to your business and the spreadsheet holding it together is creaking, building around that process tends to cost less over a few years. We build those, and say so when you would be better off not.
Deciding factors
Signals Either Way
Commissioning software commits you to maintaining it, not only to building it. Good value when the alternatives cost more; a bad idea when they do not.
Building your own is usually justified when
- The system of record is a spreadsheet, four people edit it, and the live copy is whichever was emailed last.
- The same number is keyed into three places, with no rule for which one wins when they disagree.
- Every product trialled so far needed a workaround, and the workarounds have grown workarounds.
- Two days a month go into assembling one report by hand, because nothing on the market produces that view.
- It works but cannot be extended, and whoever wrote it is no longer reachable.
- Per-seat licensing has outgrown anything anyone can point to as value.
Buying or waiting is the better decision when
- A supported product already does this, and the differences are preferences.
- The process changes every month. Encoding it now only makes the next revision expensive.
- It is already solved. Accounting, payroll and statutory filing are bought, not written.
- One person needs it, and a well-built spreadsheet would genuinely serve.
- Nobody will own it after launch and no support is arranged. That software 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
Eight Components
What a build is assembled from. Any one project uses several and rarely all.
Internal Business Tools
Built for your staff, not your customers. Enquiry registers, stock books, dispatch logs, approval queues — the unglamorous systems a business runs on, which no general product quite fits. Usually the smallest builds and the fastest to repay.
Workflow & Operations Systems
Carries a job from entry to sign-off and records who moved it when. Approval rules live in the system rather than in one colleague’s memory, and status 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 reconciles with the rows beneath it.
API & Integration Layers
The joins between your systems and the outside services they depend on. Versioned endpoints, payloads validated at the boundary, documentation that removes the guesswork, and failures logged rather than swallowed.
Database Design
Settled before any screen is drawn, because it is the part that is ruinous to revisit. Tables, relationships, constraints and indexes shaped around the questions you will actually ask. Migrations written and versioned like code.
System Modernisation
Software that already exists and still matters — ageing, inherited, or pinned to a platform version that no longer gets security updates. Read first, then moved in stages, because the business keeps running throughout.
Technical Documentation
Data model, environment setup, deployment procedure, interface reference, and the reasoning behind the decisions that mattered. Written as the work happens. Without it, handover is a word rather than an event.
Ongoing Enhancement
Software in use needs changing. After release: corrections, additions, dependency and platform updates. What is covered gets written down rather than assumed.
Before any code
Requirement to Specification
Projects fail before any code exists, usually because both sides agreed to one sentence while picturing different things. These five steps catch that early.
- 01
Interview the users
Not only the budget holder. Whoever performs the task knows the exceptions, and exceptions are what break otherwise sensible designs.
- 02
Document the current process
As it actually runs, informal shortcuts included. Written down, it frequently changes what people want built — and here that costs a conversation.
- 03
Fix the data model
What is stored, how records relate, which fields are mandatory. Typically where two departments find they have used one word for two things.
- 04
Scope version one
What the first release must do to be worth putting in front of staff. Kept short, so the system earns its keep early instead of arriving complete and late.
- 05
List the exclusions
What is deliberately out, written beside what is in. An unwritten assumption becomes an argument; a written exclusion stays a decision.
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 Need
Decided against the requirement, where it runs, and who maintains it a year out.
- 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
Specification to Daily Use
The same four stages as anything else here, each ending in something you can open, read or click.
- 01
Specify
Conversations with whoever does the work now, turned into a written description of what gets built and what does not. You approve it before anything else begins.
- 02
Design
Screens, data model and structure decided before code. Then the whole thing is cut into milestones small enough to be either done or not done.
- 03
Build and Test
Delivered in reviewable increments. Each one is checked on the normal path, on bad input, on a slow connection and on hardware several years old.
- 04
Ship and Support
Released, with the repository, the accounts and the notes that explain the decisions. We remain available for fixes, releases and the next piece of work.
Next step
Outgrown Your Spreadsheet?
Describe how the work runs now and where it breaks. You get a straight answer on whether building is right, and what it would take.