Internal tools for the work that currently runs on spreadsheets
The operational software nobody sells you off the shelf, because it only makes sense inside your business.
Book a build review
Five kinds of operational software nobody sells you off the shelf
All five start from a process that already works in a spreadsheet. We are replacing the missing permissions, history and validation — not the logic the team spent years getting right.
- Operational dashboards
- One screen that shows the state of the operation, built around the decisions the team actually makes rather than every metric available.
- Back-office and admin systems
- The queues, approvals and record-keeping that run the business and that no vendor product fits without contortion.
- Spreadsheet replacement
- Taking the workbook the operation genuinely depends on and turning it into a system with permissions, history and validation.
- Integrations between systems
- Connecting the CRM, the ERP and the tools in between so a record does not get re-keyed three times.
- Reporting people trust
- Numbers that reconcile, with the definition of each metric written next to it.
Why the spreadsheet is still in charge
The spreadsheet is not the failure. It was the only thing that fitted, and it is still the most accurate description of how the business runs.
- The vendor tool covers eighty percent, and the missing twenty is where the actual business logic lives.
- The workbook has no permissions and no history, so nobody knows who changed the number or when.
- It runs on one person’s machine and one person’s knowledge, which is a risk nobody has priced.
- Every internal-tools project loses to customer-facing work, so it never gets built.
Four commitments you can check, rather than four values
Each one shows up in something you receive or something written down, not in how we describe ourselves.
We start from your process
We sit with the person doing the work before designing anything, because the workbook encodes years of decisions worth keeping.
Boring technology on purpose
Internal tools outlive the people who commission them. We choose stacks your team can hire for.
Permissions and history from the start
Who changed what and when, built in rather than added after the first dispute.
Small enough to be worth doing
These projects die when they get too big. We scope the first version to something that ships.
The builds behind this line — and how far each one opens
4 builds, delivered for clients under NDA. What you can open is our own reference build of each, with sample data in place of the client’s: 4 are navigable screen sets with no live backend.
Four steps, and you are running software by the third
Every step ends in something you can look at rather than a status update.
- 01
Watch the work
A session with whoever actually runs the process, and a copy of the real workbook.
- 02
Model the domain
The entities and states the operation already has, made explicit.
- 03
Ship the first slice
One workflow, in use, with real data — before we build the second.
- 04
Migrate and hand over
Historical data brought across, the team trained, and the runbook written.
The same four terms hold whatever we build
Scope in writing, code in your repository as it is written, support in business hours IST Monday to Friday, and the builder on the call.
- Scope agreed in writing before we start and a written note the moment something we find changes it.
- Code in your repository as we write it so there is no handover event at the end — you already had everything.
- Support in business hours, Monday to Friday IST with the response window for anything critical agreed in writing. We do not advertise a blanket SLA a team this size could not hold.
- You talk to the person building it with no account manager between the question and the answer.
The five questions that actually decide it
Asked on almost every call, answered plainly. Where the honest answer is “sometimes not”, it says so.
Can you work with our existing stack?
Usually yes. Most operational work involves connecting to a CRM, an ERP, a database or a warehouse over an API, and we would rather integrate with what you have than argue for replacing it. Where an integration is genuinely not worth it we will say so.
Our process is a mess. Should we fix it first?
No, and waiting for that usually means never starting. The mess is information — it tells us which parts are real constraints and which are historical accident. We model what exists, then propose the small number of changes worth making.
Who maintains it after you leave?
Your team, and we build for that. Boring, well-documented technology you can hire for, in your repository, with a runbook. If you would rather we stayed on for maintenance, that is a separate agreed scope, not a dependency we engineer in.
How do you handle access to production data?
Wherever possible we work against anonymised or sample data, and where we do need access it is scoped to what the task requires and revoked when it ends. Credentials stay in your secret manager, never in code or a chat message.
Is this worth it for a small team?
Sometimes not, and we will tell you when. If a spreadsheet with tighter conventions solves it, that is a better answer than software. The case for building is usually about risk and history rather than efficiency alone.
Tell us what you’re building.
Thirty minutes on the problem and what is actually hard about it, then a written note back. No obligation either way.
Book a build review