Build it with AI
Turn the spreadsheet or manual process your team depends on into a focused internal application.
Build forms, records, dashboards, workflows, and role-specific interfaces around an internal business process.
Introduction
What an internal tool has to hold.
Most teams end up with an internal tool the same way: a spreadsheet that grew into a dependency, or a request sitting in an engineering backlog. A spreadsheet is the right tool right up to the point where more than one person edits it and someone outside the team needs to see part of it. Both conditions arrive quietly, and neither triggers a decision to change anything.
The tool that would take an engineer a week is never worth a week, so the spreadsheet stays and quietly becomes production. There is no permission boundary inside the file, no validation preventing the entry that breaks a formula, and no history of who changed what when the number turns out to be wrong.
What follows covers building an internal tool: the records it holds (whatever the team needs to see and change, with owners and states attached), the systems it reads (Google Sheets and Slack), and what it does not fix.
The problem
The spreadsheet that runs a department and belongs to one person.
Spreadsheets are unmatched for modelling something quickly and have no concept of a role, a state, or a constraint. Internal software solves all three and waits behind customer-facing work in every roadmap, which is why the spreadsheet is still there.
The records are whatever the team needs to see and change, with owners and states attached, and the authoritative copy of most of them already lives in Google Sheets or Slack. Three people keep local copies of the master sheet because the shared one is always locked, and the merge back happens by eye at the end of the month.
The cost is not the inconvenience: an operational process depends on a file with no access control and no audit trail.
You're likely here because
- One person can break a departmental process with a paste
- The tool that would take an engineer a week is never worth a week, so the spreadsheet stays and quietly becomes production.
- When it is wrong, an operational process depends on a file with no access control and no audit trail
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Internal app
- • Role views
- • Workflow controls
Operated through Grow
- • Notifications
- • Follow-up
- • Connected actions
Systems it reads
- • Google Sheets
- • Slack
- • Airtable
The record model
What the spreadsheet was actually holding.
- The undocumented formula logic
- The substance of what has to be reimplemented. It is the specification, it is not written down anywhere, and the person who wrote it may have left.
- Validated inputs with the rejection reason
- Because the failure mode of a spreadsheet is silent propagation of a bad value, discovered three steps later as a wrong total.
- Role scope per view
- The reason local copies exist is almost always that the shared file is all-or-nothing. Role-scoped views remove the reason before anything else is built.
- Change history
- So a wrong number can be traced to a change rather than to a suspicion, which is currently the only available method.
- The upstream systems it is fed from
- Read directly rather than pasted. Removing the copying step often delivers most of the value on its own.
- Export in the original shape
- Because somebody downstream depends on that spreadsheet, and a tool that cannot produce it creates a shadow copy immediately.
- Owner
- A named person. An internal tool without one degrades the same way the spreadsheet did, more slowly and with better error messages.
How it runs
From a shared file to an application with roles.
Step 01
Describe what an internal tool has to do
Start from what the spreadsheet actually does rather than what its columns are named. The logic in the formulas is the specification, and much of it is undocumented.
Step 02
Connect the systems of record
The systems the spreadsheet is manually fed from should be read directly, which removes both the copying step and the staleness it introduces.
Step 03
Build the operating surface
Records, validated inputs, role-scoped views, and the workflow the sheet was approximating — as an application where a wrong entry is refused rather than propagated.
Step 04
Start narrow
The single view that the most people need and the fewest can safely have. Role-scoped read access usually removes the copies before anything else is built.
Step 05
Route the exceptions
An input that fails validation is refused at entry with the reason, rather than accepted and discovered three steps later as a broken total.
Step 06
Measure manual steps removed from the process the tool serves
Count the time spent maintaining the sheet and the errors traced back to it in the last quarter. Both are usually higher than the team’s estimate.
Implementation path
Replacing a critical spreadsheet without breaking it.
- 01
Read the formulas, not the headings. Undocumented logic is the substance of what has to be reimplemented, and the person who wrote it may no longer be there.
- 02
Baseline maintenance time and error incidents. Internal tools are usually deprioritised because the cost of the status quo has never been counted.
- 03
Connect the systems the sheet is fed from before rebuilding the logic. Removing the copying step often delivers most of the value on its own.
- 04
Run the application alongside the sheet for one full cycle and reconcile the outputs. Where they differ, the sheet is right until proven otherwise — it has been trusted for years.
- 05
Build the narrowest useful version first: the one screen the team opens most often, built properly with real permissions.
- 06
Reading the formulas with the person who uses the sheet daily is one to two days and is the real specification work. Connecting the upstream systems is often the highest-value week. Running the application alongside the sheet for a full cycle and reconciling outputs is not optional — where they differ, the sheet is right until you can explain the difference.
- 07
After the first sheet is replaced and reconciled, connect the remaining upstream sources so the copying step disappears entirely. A second sheet follows only if it meets the same three tests.
Controls
Controls that matter.
Control 01
Role-scoped access, since the reason for the local copies is almost always that the shared file is all-or-nothing
Control 02
Validation at entry with the reason given, because the failure mode of a spreadsheet is silent propagation of a bad value
Control 03
Change history retained, so a wrong number can be traced to a change rather than to a suspicion
Examples
Three risks that get retired.
The paste that broke the totals
Validation at entry refuses the value with an explanation, instead of accepting it and producing a wrong total that is discovered in a meeting two weeks later.
The three local copies
Role-scoped views mean people can see the part that concerns them without holding the whole file, which removes the reason the copies existed.
The person who owns the sheet is away
Logic encoded in an application with history is readable by someone else, which turns a key-person dependency into a normal handover.
How it goes wrong
Three ways internal tool builds go wrong.
Every spreadsheet in the department is queued for replacement.
Replace only the ones that run a process, are edited by more than one person, and would cause disruption if corrupted. Analytical and one-off sheets are better as sheets, and always will be.
The application is slower for the common case, and within a month people are back in the spreadsheet.
Match the fastest existing path first — usually bulk entry or keyboard-driven editing. That comparison is being made whether or not anyone says so out loud.
The reimplementation is built from the column headings, and a piece of logic in a nested formula is quietly lost.
Read the formulas, not the headings. Undocumented logic is the substance, and losing one rule produces a number that is wrong in a way nobody notices for a quarter.
Limitations and considerations
What building internally does not remove.
- Spreadsheets remain better for exploration and one-off modelling. Replacing every sheet is the wrong goal; replacing the ones that run a process and cannot safely be edited is the right one.
- Reimplementing undocumented formula logic requires somebody who understands what it was meant to do. That understanding is the scarce input, and its absence is what stalls these projects.
- An internal tool without an owner degrades the same way the spreadsheet did, just more slowly and with better error messages.
- If one person owns the sheet, edits it alone, and it is used for analysis rather than operations, leave it. If the logic cannot be reconstructed because nobody understands it, that is the constraint, and building will produce a confident reimplementation of something wrong.
- Connector coverage varies: Google Sheets, Slack, Airtable are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build an internal tool with AI: common questions.
Which spreadsheets are worth replacing?
The ones that run a process, are edited by more than one person, and would cause real disruption if corrupted. Analytical and one-off sheets should stay as sheets — they are better at that job than any application.
How do we handle the logic nobody documented?
Reconstruct it from the formulas with the person who uses the sheet daily, then run both in parallel and reconcile. Where they disagree, the sheet is the reference until you can explain the difference.
Will people go back to the spreadsheet?
They will if the application is slower for the common case. Match the fastest path first — usually bulk entry or a keyboard-driven edit — because that is the comparison being made whether or not anyone says so.
What about the export people rely on?
Keep it. An internal tool that cannot produce the spreadsheet somebody downstream depends on creates a shadow copy immediately, and the shadow copy is the thing you were trying to remove.
What should the first version contain?
The one screen the team opens most often, built properly with real permissions. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure manual steps removed from the process the tool serves against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build an internal tool around the process you actually run.
Read the formulas rather than the headings, run both for a cycle, and treat the sheet as right until you can explain the difference.