A database around your real records
Jobs, orders, members, stock or whatever the sheet tracks today, modelled properly with relationships and validation instead of free-form cells.
Solution
Internal Platforms and Business Tools
Back-office tools that replace the shared spreadsheet with real records, roles, change history and a screen for each job.
Overview
What the system does
Typically integrates with
- Google Sheets and Excel for import and export
- Accounting software such as QuickBooks and Xero
- Google Workspace and Microsoft 365 sign-in
- Slack notifications
- Payment processors
- Shopify and other commerce platforms
Most businesses have one spreadsheet that runs half the operation. It works until two people edit it at once, or someone pastes over a formula. The master sheet has tabs nobody understands, colour codes only one person can read, and no record of who changed what.
An internal platform replaces it with a database designed around your real records, such as jobs, orders, members or stock, and a screen built for each job: the warehouse sees picking lists, the office sees invoicing.
We will also tell you when not to build. If the sheet is mostly a shared list that a few people use, Airtable, Smartsheet or a Notion database may be enough, and for admin screens on a database you already have, Retool or Appsmith can be quicker. Build custom when the tool needs logic those platforms make awkward, when per-seat pricing gets expensive across a large staff, or when customers or partners will one day need a login too.
Who needs this
Operations teams running a business on one shared spreadsheet that has outgrown the people who maintain it.
What we build
Start from the records the sheet tracks, then model them as tables with relationships and validation. Agree what each column really means before importing. Build the screen for the person who opens it every day first; rows that do not fit are set aside for a person to resolve rather than guessed.
Modules
Core modules
A screen for each job
Views built for the person using them, so each role works from the screen that fits its task rather than one giant sheet.
Roles and permissions
People only see and edit what their work needs. Pay rates, margins and other sensitive fields can be restricted per role.
Change history on every record
Who changed it, when, and what it was before, so a mistake can be traced and undone.
Search and filters
Saved filters and search in place of scrolling and Ctrl+F.
Import from your existing sheets
Rows that do not fit are set aside for a person to fix, with a dry run before anything is loaded.
Export back to spreadsheets
Excel or CSV export for anyone who still wants a spreadsheet at month end.
Architecture
How it fits together
A typical implementation flow, with explicit responsibilities at each boundary.
Integrations
- Google Sheets and Excel for import and export
- Accounting software such as QuickBooks and Xero
- Google Workspace and Microsoft 365 sign-in
- Slack notifications
- Payment processors
- Shopify and other commerce platforms
- 01
Model
Agree what each column means and design the records, relationships and required fields.
- 02
Import
Load existing sheets with a dry run, setting aside rows that fail validation for review.
- 03
Operate
Give each role its screen, record every change and export to spreadsheet formats on demand.
Security and controls
Design for the exceptions, not just the happy path.
Enforce roles on the server, not just in the screen, and restrict sensitive fields such as pay rates and margins. Keep a change history on every record and an access log for exports.
Technology options
We select the final stack after reviewing your existing systems and operating requirements.
Security and IP practicesFit
Industries that use this
FAQ
Questions people actually ask
Our spreadsheet is a mess. Do we need to clean it up first?
No, that is part of the job. We go through it with you, agree what each column really means, and the import sets aside the rows that do not fit. You decide what happens to those, not us.
Will my team actually use it?
They will if it is faster than the sheet for the task they do most. That is why we start with the people who open it every day and build their screen first.
Can it run on our own servers?
Yes, or in a cloud account in your company’s name. Either way you hold the keys and the data.
When should we use Airtable or Retool instead?
When the sheet is mostly a shared list for a few people, or when you only need admin screens on a database you already have. We will say so on the first call rather than sell you a build.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.