The application for the process no package covers.
Purpose-built applications for the operational processes that are specific to how you work — engineered to the same standard as the systems around them, not assembled in a spreadsheet.
Where spreadsheets become systems
Every business has processes no package covers, so they end up in a spreadsheet or an access database that one person maintains. It works, until it holds real operational weight — at which point it has no access control, no audit trail, no backup and one point of failure who is due some leave.
- A critical process runs on a spreadsheet with macros one person understands.
- There is no audit trail, no access control and no meaningful backup.
- Several people edit copies and reconcile them by hand.
- Packaged products have been evaluated and none fits the process closely enough.
What we build
A proper application for the process: multi-user, permissioned, audited, integrated and supportable — sized to the problem rather than over-engineered into a platform.
- A data model appropriate to the process rather than a flattened grid
- Multi-user access with roles and permissions
- Validation at entry, so bad data is refused rather than corrected later
- An audit trail of who changed what and when
- Integration with the systems of record the process depends on
- Backup, monitoring and a documented support path
How it runs
The existing spreadsheet is the most honest specification you will get.
- 01Read the spreadsheet
It encodes the real process, including the rules nobody wrote down. We start there rather than from a requirements workshop.
- 02Model the data properly
Entities and relationships instead of a wide flat sheet, which is what makes reporting and integration possible.
- 03Build to the process
Screens and validation shaped around how the work is actually done, not around the data model.
- 04Integrate and migrate
Connected to systems of record, with the existing data migrated and cleansed on the way in.
- 05Operate it properly
Backup, monitoring, access review and a support path, which the spreadsheet never had.
What changes once it is running
What moving a process off a spreadsheet changes.
Key-person risk drops
The process no longer depends on one person and their undocumented macros.
The data becomes trustworthy
Validation at entry and a single copy remove the reconciliation of divergent versions.
It becomes auditable
Who changed what, when, is recorded — which a shared workbook can never genuinely provide.
It connects to everything else
A real data model means the process can integrate rather than exporting to CSV.
How an engagement is shaped
Small and iterative. A purpose-built application should not become a programme.
Process and fit review
One to two weeks on the process and whether a packaged product genuinely fits. Sometimes one does, and we will say so.
Build iteratively
Short cycles with the people who do the work, because they will spot the missing rule the moment they see a screen.
Migrate and support
Data migrated, users moved across, and a defined support arrangement rather than an informal dependency on us.
Common questions
The things buyers ask before they commit. If yours is not here, it is a good first question for the assessment.
- Should we buy something instead?
- If a package fits, buy it — custom software you own is a long-term commitment. The fit assessment is part of the engagement precisely so this is a decision rather than a default.
- What happens if we stop working with you?
- You hold the code and the documentation, deployed in your environment. We build so another competent team can take it over, because you should not be locked in by construction.
- Can you use a low-code platform?
- Where it genuinely fits, yes — it is often faster and cheaper. Where the process needs behaviour the platform resists, low-code becomes the expensive option. We choose after seeing the process.
Which spreadsheet would hurt most if it were lost?
That file is usually running a real process without any of the protections a real system would have.