Internal tools development for teams running the company on a spreadsheet
The sheet that started as a tracker and became the system of record. We turn it into software with permissions, an audit trail, and validation, without losing the flexibility that made people use it in the first place.
- We watch the current process before designing the replacement
- Your data migrated and reconciled, not retyped
- Fixed price agreed after the tooling audit
Why this is worth building, and why us.
Spreadsheets are the most successful internal tool ever built, which is exactly why they end up load-bearing. Someone makes one to track a process, it works, other people start using it, and eventually it holds customer records, pricing, inventory, or payroll, with no permissions, no history, and one person who understands the formulas.
The failure is rarely dramatic. It is a pasted row that overwrites a formula, two people editing different copies, a number nobody can trace, or a departure that takes with it the only mental model of how the thing works. By then the sheet is not a document, it is an application without any of the properties applications have.
What replacing it actually gives you
- 01Permissions, so people see and change what their role allows and nothing else
- 02An audit trail: who changed what, when, and what it was before
- 03Validation at entry, so bad data is refused rather than discovered in a report
- 04One record of the truth, instead of four copies with slightly different names
- 05Search, filtering, and views that do not require anyone to understand a formula
- 06An API, so the next tool you buy can read from it instead of becoming another island
Priced by what the tool has to hold
Replacing one bad spreadsheet and building the operational backbone of a company are different jobs. These tiers separate them rather than quoting a day rate and hoping.
Three days with the people who use the sheets. You get what each one is really doing, which of them are load-bearing, where the data risk sits, and a costed order to replace them in. Credited back in full against any build you start within 30 days.
- One Tool$2,9973 weeks
Replacing the single spreadsheet that causes the most damage.
- One workflow rebuilt as a real application with roles and permissions
- Your existing data migrated in and reconciled against the sheet
- Validation, an audit trail, and backups from the first day
- CSV export kept, because people will still want it
- Deployed, documented, and yours
- Most chosenInternal Platform$7,9977 weeks
Several teams, several processes, and the handoffs between them.
- Everything in One Tool, across the connected processes rather than one
- Role-based access that matches how your organisation actually works
- Integrations with the systems you already pay for: CRM, accounting, storage
- Dashboards and reporting that replace the Monday export ritual
- An admin surface, so your team adds users and changes settings without a developer
- Training and documentation aimed at the people who will use it daily
- Tooling Retainer$997/moMonthly
Internal tools that keep changing because the business does.
- New views, fields, and workflows as your processes change
- Monitoring, backups, and someone responsible for both
- A standing channel for the small requests that would otherwise go unbuilt
- A monthly call on what the team is quietly working around
- Cancel any month, no notice period
- We watch the current process before designing the replacement
- Your data migrated and reconciled, not retyped
- Fixed price agreed after the tooling audit
- We will tell you when Airtable is the right answer and stop there
Sometimes the honest recommendation is not custom software. A team of five with one process does not need a build; they need their spreadsheet cleaned up, or a properly configured Airtable base, and we will say so and charge you for the audit rather than a platform. Custom starts paying when permissions get complicated, when the data has to be correct rather than approximately right, or when a per-seat tool has quietly become a serious annual bill.
The moment a spreadsheet becomes a liability
There is a reasonably clear line. Below it, a sheet is a document: one person maintains it, mistakes are visible, and nothing else depends on it. Above it, it is a system: several people write to it, other work is driven by what it says, and a wrong cell has consequences somebody has to unpick.
The trouble is that nothing marks the crossing. The sheet does not change, the stakes do, and the tools it was never given (permissions, history, validation) are precisely the ones you now need. Most teams find out during an incident, which is a bad time to be reading a formula bar.
Why people go back to the spreadsheet
Internal tools fail in a specific way: they get built, they get announced, and within a month people are exporting to a sheet again to get their work done. It happens when the software models the process someone described in a meeting rather than the one that actually runs, so every exception becomes a thing you cannot do in the new system.
We design against that by watching the work before drawing anything, keeping the escape hatches (bulk edit, import, export) that made the sheet workable, and shipping something small early, so the people who use it can tell us what is wrong while it is still cheap to change.
When Airtable is the right answer
Airtable, Notion, and their relatives are good products, and a large number of teams should simply use them properly. Configured well, with the right views, permissions, and a couple of automations, they cover a real range of internal work at a price no custom build competes with.
They stop being the answer at fairly predictable points: when per-seat pricing crosses what an engineer costs, when permissions need to be finer than the plan allows, when you need real relational integrity rather than linked records, or when performance degrades because the base has grown past what it was designed for. We do the arithmetic honestly, including the version where the answer is that you keep what you have.
Not claims. Shipped work.
- 01ReadyShortlistA marketplace with several user types and the operational tooling behind it.See the work
- 02ChatberryA multi-tenant platform with an admin surface a team operates daily.See the work
- 03Altamar ChartersA booking product running the day-to-day of a real business.See the work
- 04Business process automationIf the problem is work moving between systems rather than the system of record itself, start here.See the work
Common questions.
01What does internal tools development cost?
$497 for a three-day tooling audit, $2,997 to replace a single spreadsheet with a real application in three weeks, $7,997 for a seven-week internal platform across several processes, and $997 a month to keep changing it as the business does. Fixed prices agreed after the audit, which comes off the build.
02Should we just use Airtable or Retool instead?
Often, yes, and we will tell you when. Those tools cover a lot of internal work well and cost far less than a build. They become the wrong choice when per-seat pricing overtakes what an engineer costs, when you need finer permissions than the plan supports, when the data has to be relationally correct, or when the base has grown past comfortable performance. The audit runs that comparison with your real numbers.
03Can you migrate our existing spreadsheet data?
Yes, and it is part of every build rather than an extra. Migration is usually the most revealing part of the project: it is where you find the duplicates, the rows with a note typed into a number column, and the three different spellings of the same customer. We reconcile against the original and show you what did not fit rather than quietly dropping it.
04How do we stop people going back to the spreadsheet?
By building the process they run rather than the one described in a meeting, and by keeping the escape hatches. Bulk editing, import, and export stay, because the reason people reach for a sheet is usually that the software will not let them do something quickly. We also ship a small first version to the people who will use it, while their feedback is still cheap to act on.
05Do we own it, and can someone else maintain it?
Yes to both. The repository is yours, the infrastructure sits in your accounts, and the stack is deliberately ordinary: Next.js, TypeScript, and Postgres, with Payload where a content surface helps. Any competent developer can pick it up, which is the point of not being clever with internal software.
Start with the spreadsheet you are most afraid of losing
Tell us what it holds, who edits it, and what breaks when it is wrong. Three days later you will know whether it needs software or just a better configuration, and what either one costs.
- A real person replies, usually same day
- No sales sequence, no automated nurture
- Tooling Audit is credited back if you go ahead