Operations
Business platforms
Internal software for the operation you actually run, rather than the one a generic product assumes you run.
What this is
The work, described plainly
Every business has a handful of processes that are genuinely theirs, and a long tail that is standard. The standard tail should be bought. The processes that make you different are where custom software pays for itself, because that is where nothing off the shelf fits.
These platforms tend to start narrow — one team, one process — and grow along the paths the first version made obvious. We build the first version to be extended rather than to be complete.
They also tend to outlive the people who commissioned them, which is why the documentation and the data model matter more than the feature list.
What you get
What is actually handed over
Concrete deliverables, not phases on a timeline.
Data model
The entities your business actually has, named the way your team names them.
Operational interfaces
Screens built for the people who use them all day, not for a demo.
Reporting
The numbers your managers currently assemble by hand, produced by the system.
Audit trail
Who changed what, and when, on records where that question will eventually be asked.
Is this you
Signals this is the right fit
- A critical process runs on a spreadsheet nobody wants to touch.
- Your team maintains the same information in three places.
- Reporting means someone assembling a file every Monday.
- You need the system to reflect your process, not the reverse.
Typical stack
Chosen per project against your constraints, not applied by default. This is what the work usually involves.
- Next.js and TypeScript
- MySQL with Prisma
- Server-side authorisation
- Background jobs
- CSV and PDF export
FAQ
Questions people actually ask
Can we start small?
That is usually the right approach. One process, in production, used daily, teaches more about what to build next than any amount of planning.
Who owns the code?
You do. Ownership and repository access are part of the handover, not an upsell.
What happens if we want to take it in-house later?
The documentation is written for that case. Standard stack, conventional structure, and no dependency on us to keep it running.
Start here
Tell us what is slow, manual, or breaking.
Answer a few questions and get a written brief back — scope, proposed architecture, and what it would take to build.