Spreadsheet Or Database Skill
Every important spreadsheet is either the right tool or a database wearing a costume — and both errors are expensive: migrating a perfectly good sheet to an app nobody needed (months of building, adoption never comes), or riding a sheet years past its limits (the tab named Sheet1 (Recovered), the row someone sorted into the wrong customer, the formula civilization one intern away from collapse). The decision has real signals, and honest cost accounting on both sides — because "we should build an app" and "the sheet is fine" are both usually said by whoever pays neither cost.
What This Skill Produces
- The signal assessment — the five outgrowth signals scored against the actual workbook
- The verdict — stay / stay-with-hardening / move — with the costs of each stated, not implied
- The hardening list (when staying) — the protections that buy years: input isolation, validation, protection, the audit pass
- The migration path (when moving) — sized honestly: low-code table tools before custom apps, one workflow at a time before big-bang
Required Inputs
Ask for these if not provided:
- The workbook and its job — what process lives in it, who touches it, how often; "the sheet" is usually three processes sharing a file, and they may deserve different verdicts
- The pain, specifically — overwrites? version forks? broken formulas? permission anxiety? The signals need symptoms, and vague dissatisfaction isn't one
- The team's build-and-maintain reality — who would create and keep alive anything new; a database nobody maintains is a spreadsheet with worse export
- Scale numbers — rows, editors, update frequency; the strain signals key off real magnitudes
Framework: The Five Signals
- Concurrent-editing collisions: multiple simultaneous editors overwriting, sort-scrambles, "who changed this" mysteries — the strongest move signal, because it's structural: sheets share state; databases share records.
- Relational strain: the same entity retyped across tabs (customer names in five places, drifting), VLOOKUP chains holding the tabs together — the sheet is imitating foreign keys without their guarantees. Drift-repair time is the measurable cost.
- Permission granularity: "they should see their rows but not the salary column" — sheet permissions are file-grained (tab protection is a workaround, not a wall); needing row/column-level access control is a database feature being mimed.
- Scale symptoms: load-time complaints, tens of thousands of rows, formula recalc pauses — the honest note: modern sheets carry more than folklore says, and this signal alone rarely justifies moving.
- Process-in-comments: status tracked in cell colors, workflow in comment threads, approvals by "I bolded it" — the sheet is hosting a process, and process tools (or a database with views) make state explicit. The verdict math: 0–1 signals = stay · 2 signals = stay + harden (spreadsheet-audit + validation + input isolation) · 3+ = move, incrementally: low-code table tools first (they migrate imports in days, not months), custom builds only when those demonstrably fail, and one workflow at a time — the big-bang replacement of a living sheet is where these projects die.
Output Format
Verdict: [workbook] — [stay / harden / move]
Signal Assessment
| Signal |
Evidence here |
Score |
The Costs, Both Ways
[Staying: the drift/repair/risk hours · Moving: build + migration + adoption + permanent maintenance owner — named or the move is fiction]
The Path
[Stay: the hardening list · Move: tool class → first workflow to migrate → the sheet's read-only retirement per migration-day-runbook logic]
Quality Checks
Anti-Patterns
1---2name: spreadsheet-or-database3description: Decide honestly when a spreadsheet should become a database or app — the five outgrowth signals (concurrent editing, relational strain, permission needs, scale, process-in-comments), what staying costs vs what migrating costs, and the incremental escape paths. Use when asked should this be a database, our spreadsheet is breaking, is it time to move off sheets, or what should replace this monster workbook. Produces the signal assessment on the actual workbook, the stay-vs-move verdict with costs both ways, and the migration path sized to the team.4---5
6# Spreadsheet Or Database Skill
7
8Every important spreadsheet is either the right tool or a database wearing a costume — and both errors are expensive: migrating a perfectly good sheet to an app nobody needed (months of building, adoption never comes), or riding a sheet years past its limits (the tab named `Sheet1 (Recovered)`, the row someone sorted into the wrong customer, the formula civilization one intern away from collapse). The decision has real signals, and honest cost accounting on *both* sides — because "we should build an app" and "the sheet is fine" are both usually said by whoever pays neither cost.
9
10## What This Skill Produces
11
12- **The signal assessment** — the five outgrowth signals scored against the actual workbook
13- **The verdict** — stay / stay-with-hardening / move — with the costs of each stated, not implied
14- **The hardening list** (when staying) — the protections that buy years: input isolation, validation, protection, the audit pass
15- **The migration path** (when moving) — sized honestly: low-code table tools before custom apps, one workflow at a time before big-bang
16
17## Required Inputs
18
19Ask for these if not provided:
20- **The workbook and its job** — what process lives in it, who touches it, how often; "the sheet" is usually three processes sharing a file, and they may deserve different verdicts
21- **The pain, specifically** — overwrites? version forks? broken formulas? permission anxiety? The signals need symptoms, and vague dissatisfaction isn't one
22- **The team's build-and-maintain reality** — who would create and *keep alive* anything new; a database nobody maintains is a spreadsheet with worse export
23- **Scale numbers** — rows, editors, update frequency; the strain signals key off real magnitudes
24
25## Framework: The Five Signals
26
271. **Concurrent-editing collisions:** multiple simultaneous editors overwriting, sort-scrambles, "who changed this" mysteries — the strongest move signal, because it's structural: sheets share state; databases share *records*.
282. **Relational strain:** the same entity retyped across tabs (customer names in five places, drifting), VLOOKUP chains holding the tabs together — the sheet is imitating foreign keys without their guarantees. Drift-repair time is the measurable cost.
293. **Permission granularity:** "they should see their rows but not the salary column" — sheet permissions are file-grained (tab protection is a workaround, not a wall); needing row/column-level access control is a database feature being mimed.
304. **Scale symptoms:** load-time complaints, tens of thousands of rows, formula recalc pauses — the honest note: modern sheets carry more than folklore says, and this signal alone rarely justifies moving.
315. **Process-in-comments:** status tracked in cell colors, workflow in comment threads, approvals by "I bolded it" — the sheet is hosting a *process*, and process tools (or a database with views) make state explicit. **The verdict math:** 0–1 signals = stay · 2 signals = stay + harden ([spreadsheet-audit](../spreadsheet-audit/SKILL.md) + validation + input isolation) · 3+ = move, incrementally: low-code table tools first (they migrate imports in days, not months), custom builds only when those demonstrably fail, and one workflow at a time — the big-bang replacement of a living sheet is where these projects die.
32
33## Output Format
34
35# Verdict: [workbook] — [stay / harden / move]
36
37## Signal Assessment
38| Signal | Evidence here | Score |
39|---|---|---|
40
41## The Costs, Both Ways
42[Staying: the drift/repair/risk hours · Moving: build + migration + adoption + *permanent maintenance owner* — named or the move is fiction]
43
44## The Path
45[Stay: the hardening list · Move: tool class → first workflow to migrate → the sheet's read-only retirement per [migration-day-runbook](../migration-day-runbook/SKILL.md) logic]
46
47## Quality Checks
48
49- [ ] All five signals scored with workbook-specific evidence
50- [ ] Both cost columns are filled — neither option rides free
51- [ ] A maintenance owner is named for any move verdict
52- [ ] Move paths start low-code and single-workflow
53- [ ] Multi-process workbooks got per-process verdicts
54
55## Anti-Patterns
56
57- [ ] Do not prescribe an app for a sheet with 0–1 signals — boring tools that work are underrated
58- [ ] Do not ride 3+ signals on sunk-cost loyalty — the collapse arrives at the worst moment by design
59- [ ] Do not big-bang the migration — one workflow proves the tool; the rest follows evidence
60- [ ] Do not move without a named maintainer — an orphaned database is strictly worse than the sheet
61- [ ] Do not treat scale alone as the verdict — modern sheets scale further than the folklore; the other four signals carry more
Mohit Aggarwal