Solo operators love a single tab that does everything: inputs, calculations, dashboard, archive, and a graveyard of “old ideas.” It feels efficient until the file becomes a maze—and every FILTER breaks when someone sorts the wrong range.
The opposite failure is premature architecture: five linked sheets, IMPORTRANGE across files, and a Notion hub for a workflow that still fits on one screen.
This post is a decision guide for when to keep one sheet and when to split—aimed at Excel / Google Sheets templates (with a short Notion parallel) for people who run their own work.
Start from the atomic unit
Ask: what is one complete record?
- One expense line
- One content piece
- One applicant
- One weekly review row
If you can’t name the atomic unit, you aren’t ready to split. You’re still discovering the workflow. Stay on one sheet.
Stay on one sheet when…
1. You can see a full valid row without horizontal scrolling theater
Critical fields fit in roughly the first 8–10 columns. Extra detail can live far right or in a Notes column.
2. Your “dashboard” is just summaries of the same rows
SUMIF, COUNTIF, pivot tables, and a few charts on the same tab (or a Dashboard tab that only reads) don’t require a multi-file architecture.
3. Only one or two people edit
Coordination cost is low. A single sorted table with filters beats distributed truth.
4. Volume is modest
Hundreds of rows are fine. Tens of thousands, heavy volatile formulas, or constant collision on the same cells push you toward split or a real database.
Rule of thumb: if a competent friend can add a correct row in under five minutes on one tab, don’t split for aesthetics.
Split when…
1. Different cadences collide
Example: a daily habit log and a monthly budget sharing one grid. Daily rows bury monthly planning; monthly edits risk sorting daily history. Split by cadence.
2. Inputters shouldn’t see (or break) calculations
Put raw entry on Input, calculations on Model, presentation on Dashboard. Protect Model. This is the most common healthy split for templates you hand to clients.
3. Reference data is shared across workflows
Categories, rates, team roster, client list → Config or Dim_* tabs. Fact tables stay skinny. Changing a category name shouldn’t require find-replace across narrative Notes cells.
4. Archives poison filters
Active pipeline mixed with three years of Done rows makes every view fragile. Move Done to Archive on a schedule (monthly), or filter with a hard Status rule and accept the cost. If people keep “cleaning” by deleting, you needed an Archive yesterday.
5. Permissions differ
Google Sheets: sometimes a separate file with view-only dashboards and an editable intake form sheet is simpler than teaching protected ranges. Split for access control, not for decoration.
A simple split pattern that rarely goes wrong
For many solo templates:
| Tab | Holds | Editable? |
|---|---|---|
| Input | Atomic rows only | Yes |
| Config | Lists, rates, constants | Rarely |
| Model | Formulas, joins, helper columns | No (protect) |
| Dashboard | Charts / KPIs reading Model | No |
| Archive | Old Input rows | Append-only |
That’s enough structure for a serious personal CRM-lite or content system. More tabs usually mean undecided concepts.
Linked files (IMPORTRANGE) — higher bar
Separate spreadsheets linked by IMPORTRANGE / Power Query feel powerful and fail loudly when permissions rot.
Use cross-file links only when:
- Different audiences need different access, and
- One file is clearly the system of record, and
- You can tolerate refresh lag and broken auth
Otherwise prefer tabs in one file. One sharing link beats four.
Notion parallel (short)
- One database ≈ one atomic unit.
- Split databases when relations are real (Clients ←→ Projects ←→ Tasks), not when you wanted a prettier page.
- Linked views of the same database > duplicate databases that drift apart.
- A dashboard page that embeds views is fine; mirroring properties across two databases “to keep it simple” usually isn’t.
Decision tree you can steal
Can you name the atomic row?
No → stay exploring on one sheet
Yes → Can a new user complete one row in <5 minutes on one tab?
Yes → stay one sheet (add Config if lists grow)
No → Is friction from cadence, permissions, archive, or calc safety?
Yes → split tabs (Input / Config / Model / Dashboard / Archive)
No → simplify columns first; splitting won’t fix a confusing row
Need different sharing boundaries across teams?
Yes → consider separate files with one system of record
No → don’t IMPORTRANGE for fun
Migration without drama
When you do split:
- Duplicate the file as a backup.
- Create Input with identical headers to the old working range; paste values.
- Move formulas to Model; verify totals match the backup.
- Only then delete redundant columns from Input.
- Write a three-line note on Dashboard: where to type, what not to touch.
If totals don’t match before you delete anything, you aren’t ready to delete anything.
Where templates fit
Good templates choose a side. They don’t hand you seventeen blank tabs “just in case.” When I design sheet-style systems for PlanoNest, the default is one clear Input surface plus Config—and a split only when cadence or calc safety demands it.
Complexity should be earned by pain you already felt—not by architecture you might need someday.
Top comments (0)