The system that replaces the spreadsheet everyone fears
Most businesses run a critical process on a shared file that one person understands, nobody dares change, and no one can audit. We build the system that takes it over — with permissions, history and reports that survive that person leaving.
Off-the-shelf nearly fits, and nearly is the problem
Every serious operation ends up with a process no product quite covers. So it lives in a spreadsheet with hidden columns and colour-coded rules, or in a system bent so far out of shape that half the team keeps a private copy anyway.
The damage is rarely dramatic. It is a slow tax: numbers that disagree between departments, a change nobody can trace, an approval that happened in a chat message, and an entire process that stops when one person is on leave.
Custom software is worth it exactly when the process is genuinely yours and genuinely load-bearing. When it is not, we will tell you to buy something instead — we would rather say that in the first call than invoice you for finding it out.
What goes into an internal system
Every item here is something we built and still run ourselves — not a service line we have only read about.
Roles and permissions that hold
Who may see, edit and approve what — enforced on the server for every request. An interface that merely hides a button is not access control.
A real audit trail
Who changed what, when, and — where the old value matters — what it was before. The question that matters arrives months later, and only a system that recorded it can answer.
Approvals and workflow
States and handoffs modelled explicitly — a lesson moves from scheduled to live to ended, a submission from handed-in to graded, a recording from interrupted to finalising to ready — so the process lives in the system instead of in people’s memory.
Reports finance trusts
Figures computed once from the source data, so two departments cannot arrive at two different totals for the same month.
Talks to what you already run
Payment gateways, WhatsApp, transactional email, object storage and push notifications — the integrations we run in production ourselves. A system that cannot exchange data becomes another island within a year.
Your existing data, brought across
Getting your existing spreadsheets into the system is part of the build, not an afterthought: we model the sheet you actually keep, load it, and reconcile the totals against the ones you already expect before anyone switches over.
Sensitive data protected
Encryption at rest for financial and credential columns — payment tokens, two-factor secrets, API tokens, stored phone numbers — with secrets held outside the codebase, least-privilege database accounts, and a rotation script that re-seals every encrypted column.
Backups that have been restored
Encrypted, off-site, automatic — and actually restored to prove they work. An untested backup is a belief, not a safeguard.
How we approach an internal system
The same sequence on every engagement, whatever the stack.
1. Watch the real process
We sit with the people doing the work and map what actually happens, including the workarounds. The documented process and the real one are rarely the same, and the real one is the requirement.
2. Replace one piece at a time
The most painful part first, running alongside the old way until it is trusted. Big-bang cutovers are how these projects fail.
3. Hand it over twice
Once to the people who use it daily — trained on the process as it now runs, and on what to do when the system disagrees with them. Once to whoever administers it: deployment, backups and the runbook, in your accounts, not ours.
Straight answers
The questions that actually come up on a first call.
Often it is, and we will say so. The test we apply: if your process is genuinely unusual and central to how you make money, custom pays for itself. If it is ordinary work in an unusual arrangement, an existing product plus a small integration is almost always the better buy.
You own the code and can hire anyone, including your own team — that is the point of a boring, well-documented stack. We are available for continued work, but nothing about the way we build it makes us hard to replace.
Financial and credential columns encrypted at rest with a rotation script that re-seals all of them; secrets outside the repository; database accounts limited to the operations they need; every denied authorization recorded; and encrypted off-site backups that get restored to prove they work. These are the practices running on our own product, not a checklist written for this page.
Yes. Shared repository, shared review, and a deliberate effort to leave your developer able to carry the system rather than dependent on us.
Describe the process that keeps breaking
Tell us what it is, who touches it, and what goes wrong. You will get a written scope back — including an honest answer if buying something would serve you better.
Every project starts with a scoping conversation and a written estimate before any code is written. No retainer required to talk.