33 guides

Guides to working with data that connects

Most operational work does not fit in one table. These are practical guides to the ideas and the builds that make relational data manageable — written to be read once and used, not to rank for something.

Relational basics

All 7 →

The handful of ideas — relations, lookups, rollups, junction tables — that separate a spreadsheet from a system.

Linked records: the one idea that replaces half your formulas

A linked record is a pointer to a real record, not a typed name. Understanding that single distinction removes most of the maintenance work from a spreadsheet.

5 min

Lookup vs rollup: which one do you actually need?

Both read data across a link. A lookup borrows one record's value; a rollup summarises many. Here is how to tell them apart and pick correctly every time.

5 min

Database normalization for people who aren't engineers

Normalization has an intimidating name and a simple rule: every fact should live in exactly one place. Here is what that means in practice, without the formal theory.

5 min

One-to-many vs many-to-many, explained without the jargon

Getting the shape of a relationship right takes thirty seconds and saves weeks. Here is how to tell which one you have, using two plain-English questions.

5 min

Rollups, formulas and when to reach for each

Calculated fields come in three kinds, and picking the wrong one is why your numbers drift. Here is the decision rule, plus the patterns worth stealing.

5 min

What is a junction table (and when do you need one)?

When two things relate many-to-many, the relationship itself has data. A junction table is where that data lives — and it is the most useful structure in operational modelling.

5 min

Why every table needs a stable ID (and why it shouldn't be a name)

Names change, duplicate and get mistyped. If your records are identified by name, every link you build is standing on sand. Here is the fix, and it takes five minutes.

5 min

Spreadsheets, databases and the space between

All 8 →

Why teams outgrow the sheet, what a relational workspace actually is, and how to tell which one you need.

Seven signs your spreadsheet has quietly become a database

Spreadsheets rarely fail loudly. They degrade. Here are the seven symptoms that mean your sheet is now doing a database's job badly — and what to do about each.

6 min

What is a relational workspace?

A relational workspace is what you get when a spreadsheet's ease of use meets a database's structure. Here is what that actually means, and when you need one.

6 min

Approval workflows that actually hold

Most tools give you a status field called Approved and call it an approval workflow. The difference shows up the first time somebody edits an approved record — here is what a real one has to do.

7 min

Spreadsheet vs database: what actually changes

Not which is better — what is genuinely different. A clear-eyed comparison of the trade-offs, and the specific jobs each one wins.

5 min

The no-code database: a plain guide

What "no-code database" actually means, what these tools can and cannot do, and how to evaluate one without getting sold to.

5 min

The seal: approval status that can't be faked

Most approval workflows end by writing a status cell that anyone can edit afterwards — the ceremony is elaborate and the record of it is a suggestion. Here is what it takes to make "Approved" mean something: a status only the flow can write, gates that watch the linked records, and a sealed state the whole product respects.

5 min

Why our AI shows its working

Language models are persuasive whether they're right or wrong. So we stopped asking you to trust ours — every figure is re-checked against your live data, every change is signed, and one click walks it back. Here's the engineering behind that decision.

3 min

Why VLOOKUP keeps breaking your spreadsheet

VLOOKUP is not a bad function. It is a fragile substitute for a relationship, and it fails in five specific ways. Here is each one, and what replaces it.

5 min

Build it: playbooks

All 8 →

Step-by-step builds for the systems teams actually run — CRM, inventory, hiring, projects, content.

How to build a CRM you'll actually use

Most CRMs fail because they ask for more data than they give back. Here is a five-table model that stays useful, and the fields that earn their place.

5 min

Orders and line items: the classic build, done right

Every order system is the same three tables. Getting them right — especially the frozen price — is the difference between accurate revenue history and quiet corruption.

5 min

A project tracker that survives contact with a real project

Most project trackers die because updating them is work that benefits someone else. Here is a model where the person doing the update gets something back.

5 min

Build a content calendar that connects to the work

A calendar of dates is not a content system. Model pieces, channels and distribution separately and you get planning, production and performance in one place.

5 min

Build an applicant tracking system in an afternoon

Hiring is the textbook many-to-many problem. Model applications as their own table and the pipeline, the reporting and the candidate history all work.

5 min

Build an inventory system that reconciles itself

The single biggest inventory mistake is a stock level you edit by hand. Track movements instead and the number becomes both correct and explainable.

5 min

Collect work from clients without email ping-pong

Requests arriving by email are unstructured, unassigned and untracked. Structured intake fixes all three, and takes about an hour to build.

5 min

Track equipment and assets without a spreadsheet graveyard

Asset registers rot because they record state instead of events. Model custody and maintenance as movements and the register stays true on its own.

5 min

Comparisons and alternatives

All 6 →

Honest comparisons against the tools you are probably already evaluating.

Tool roundups

All 4 →

What is genuinely good, what it costs, and who each option really suits.

Stop fighting your spreadsheet

RowFold gives your data the structure it already has in your head — tables that know about each other, views that fit the work, and AI that can actually answer questions about it.