Rung 1 — Spreadsheet / POS export

One line: One person, one file, one source of truth by default. Perfectly good until a second person needs to write to it.

1. Concept

There is no previous rung. This is where every business starts and where many should stay for a while. The "system" is a spreadsheet, a notebook, or the export button on a point-of-sale (POS) app like Square or Shopify.

What this stage is for: getting orders out the door and knowing at the end of the month whether you made money. Nothing else. A spreadsheet is the right tool for that because it has zero setup cost, you can see all of your data at once, and you can change the "schema" (the columns) in seconds when the business changes — which at this stage it does weekly.

The mistake people make here is not "using a spreadsheet". It is treating the spreadsheet as if it were a database — sharing it with three people, running the business off formulas nobody remembers writing, and never noticing that the numbers stopped matching the bank account.

For students: this rung teaches the shape of data before any tool does. If you can lay out orders, customers, and products as three clean tabs with an ID column each, you already understand what a relational database is going to ask of you at Rung 2.

2. Signs you are here

In business language

• One person "knows the numbers" and it is you.
• The master file has a name like orders_2026_v3_FINAL.xlsx.
• Month-end means an evening of matching the sheet to the bank statement.
• The customer list lives in your phone contacts and Instagram DMs.
• A new hire asks "where do I put this?" and the answer is a Slack message.

In technical language

• Data is entered by hand or downloaded from a POS export on a schedule.
• No schema: columns are added when needed; a cell can hold anything.
• Business logic lives in formulas (VLOOKUP, SUMIF) chained across tabs.
• One writer at a time is the assumption even if it is not enforced.
• Backups are "it's in Google Drive" or nothing.

3. The decision

The fork at Rung 1 is how disciplined to make the spreadsheet versus when to leave it. There are three real options:

Option	Choose it when
A. Stay, but make it disciplined — one shared sheet, one tab per thing, data validation, an ID column, a "do not edit" raw-export tab	Still 1 writer (maybe 2 who never overlap); <30 orders/day; no customer-facing app needed
B. No-code database (Airtable, Notion databases, Baserow)	2–5 writers; you need forms, views, and simple automations; still no customer-facing app
C. Go to Rung 2 — a managed database with an app in front	>1 person writing at the same time; dozens of orders/day; a second location or channel; customers need to see their own data

How to choose: count writers, count orders per day, and ask whether a customer ever needs to log in. Two of those three pointing up means Rung 2. Option B is a legitimate stop, not a detour — many businesses run for years on it — but it does not teach you anything the student needs, so the learning path treats it as Rung 1.5.

[k3r war-story slot: the business that stayed on a spreadsheet too long — what broke first]

4. Tools

Categories first. Named examples are current as of writing; fit matters more than brand. Affiliate disclosure: links marked (affiliate) may pay us a commission. It never changes the recommendation.

Spreadsheets

• Google Sheets — fits when you need sharing and a free API later. Default choice.
• Microsoft Excel — fits when the owner already lives in Excel or the accountant does.
• Apple Numbers — fits only if you never share with anyone. Rarely the right call.

POS / commerce with a good export

• Square — fits a physical counter with occasional online orders.
• Shopify (+ Shopify POS) — fits online-first with some in-person; strongest export and app ecosystem.
• Toast / Clover — restaurant and hospitality specific.

No-code databases (the Rung 1.5 option)

• Airtable — fits when you want forms, views, and light automation; costs per seat.
• Notion databases — fits when the team already documents in Notion; weaker for volume.
• Baserow / NocoDB — open-source alternatives if you want to self-host later.

Capture forms — Google Forms, Tally, Typeform: get the data entered once, at the source.

Simple accounting — Wave (free), QuickBooks: keep money in an accounting tool, not in the orders sheet.

5. Next trigger

Business thresholds (any two of these → plan the move to Rung 2)

• More than one person needs to edit at the same time.
• Roughly 30–50+ orders or transactions per day, sustained.
• A second channel or location (online + counter; two stores).
• Monthly numbers don't reconcile and nobody can say why.
• A customer asks "can I see my order / my account online?"

Technical symptoms

• Two people overwrite each other's edits; "who changed this?" has no answer.
• Formula chains break when a column is inserted.
• The sheet has tens of thousands of rows and is slow to open.
• The same fact is re-keyed into two systems (POS → sheet → accounting) by hand.

---

Threads

Security

• The real risk is sharing: "anyone with the link can edit". Set it to specific people.
• Two-factor authentication on the Google/Microsoft account that owns the file.
• Never put card numbers, full bank details, or passwords in the sheet. The POS handles cards; you never need them.
• Know who has a copy. Every "download as Excel" is an uncontrolled copy.

Compliance placement

• PCI — applies if you store card data. You should not. Let Square/Shopify/Stripe carry it; that is what you pay them for.
• GDPR / CCPA — if you keep customer names and emails, you must be able to find and delete a person's data on request. In a sheet, that is a filter and a delete row. Write down that this is the procedure.
• HIPAA — if anything health-related is in the sheet, this rung is already wrong for you. Go to a vendor with a Business Associate Agreement (BAA) now.
• SOC 2 — not applicable. Nobody will ask yet.

Data modeling

• One tab per thing: orders, customers, products. One row per record. Header row only.
• An ID column on every tab, never reused, never edited. This is your first primary key.
• Orders reference a customer by ID, not by retyping the name. This is your first foreign key.
• No merged cells, no colour-as-data, no totals rows inside the data. Totals go on a separate tab.
• Keep the raw POS export on its own tab, untouched. Derive from it; never edit it.

Cost

• Near zero in money. The cost is your evenings and the errors nobody catches.
• The first bill you see will be per-seat pricing on the no-code option (Airtable), which is fine until seat count is the reason you are paying more than a database would cost.