The problem
The operation is a workbook, an inbox and a chat thread. The same row is copied, and the approval is a message.
Spreadsheets to software
From a spreadsheet to software.
When a workbook, an inbox and a chat thread run the operation, we keep the rules the sheet already encodes and put them in an application a colleague can run. A large platform is the last option.
- The sheet
- The rules, lists and approvals you already use
- The application
- One workflow, not a suite you do not need
- Hosting
- Environment, updates and a named owner, agreed separately
Ready
Where a spreadsheet stops being enough
The file can stay as the record of the rules. It does not have to stay as the system.
The hidden cost
Two people hold two versions. The only person who knows the file is away. Nobody can see which figure is current.
The outcome
Software for that one workflow. A colleague can run it, and the decision is on the record instead of in a chat.
How the sheet becomes software
Three parts. We do not start by replacing every workbook in the company.
1 · The rules
Read the sheet before writing software
Limits, owners and exceptions are already in the workbook. We write those down and keep them. A product we already run is used only when it covers this workflow.
2 · One workflow
Build the application for that job
Screens, the approval, and the link to the mail, ERP or files you already use. Other sheets stay until they are the next problem.
3 · Hosting
Someone owns it after the file is retired
Environment, updates and a named owner are a separate agreement. The first build does not include them automatically.
What you can check
You can compare the application with the sheet before the sheet is retired.
- Rule note
- The limits, owners and exceptions taken from the workbook, written in plain language.
- Gap list
- What the sheet does today, and what the application still has to do.
- Working system
- The one workflow, available to the people who used the file.
- Acceptance record
- Checks against realistic rows, and a written list of what we did not test.
- Hosting terms
- Who runs it, how updates happen, and who you call when it fails.
- Contract
- Ownership or licence, data handling, and later changes as separate lines.
Where this sits
Public examples of systems that replaced a repeated manual step. A new project reuses a product only when it fits. Measured client results are shared only with permission.
- BeondAuditAudit workflow with exceptions and a review record.
- WingspanPOSRetail sales and stock, when the counter is still reconciled in a sheet.
- Enterprise applicationsWhen the operation already spans several tools, not one workbook.
- Custom business softwareThe wider delivery model: a product we run, only the gap, then hosting.
- Application modernisationWhen an older application should stay, and only one part should move.
- Product catalogueSystems a custom workflow can stand on.
Hosting is agreed separately
The usual path is our environment, updates, monitoring and a named owner. A private environment on your cloud or network is available when the contract requires it. We do not promise uptime.
Show us the workbook.
We will say which rules move first, whether a product we already run fits, and how we would host the result.