A company operating system in Notion: 17 areas, 8 databases, zero duplication

What an early brand actually needs at 9am

An early-stage brand is holding a dozen areas at once: strategy, a product in development, suppliers, research, contracts, finance. The question in the brief isn't "where do I put this", it's "how do I connect it so that at 9am I see what needs attention and what stage every project is at". That is an architecture question, not a pretty-template question, and the client said as much: they want to understand the system, not just receive a workspace.

Databases, not nested pages

The most common mistake, and the hardest to undo later, is building the system out of nested pages. A page inside a page inside a page. It looks tidy at twenty entries and falls apart at two hundred: you can't filter it, sort it or count it, and the same fact ends up in three places. The foundation is a small set of databases. Every "page" is then a row you can query, not a folder you have to dig through.

Eight databases, one source of truth

Seventeen things on the list collapse into eight databases. The rest is not separate databases, it is a "Type" property and relations. Suppliers, Manufacturers and Contractors are not three databases, they are one Partners database with a Type field. Strategy, research, brand docs, processes and contracts are not five sections, they are one Documents database with a Type and a relation to whatever they describe.

Projects is the operational spine the dashboard reads. Partners, Contacts, Products, Finance and Documents also link to each other directly, so the workspace is a graph, not a star. Each card below lists the key properties and what it relates to.

Relations instead of copying

A product points to its manufacturer through a relation, not through a copied address. Change the manufacturer's details once and every product is instantly correct. This is the exact answer to "avoid duplicate information": a fact has one owner, and everywhere else is just a pointer to it. The same holds for people and companies, projects and their costs, meetings and the decisions they produced.

Rollups build the dashboard

The home dashboard stores nothing. It reads. Projects rolls up its tasks: how many are open, the next due date, percent done. Finance rolls up cost per project. You open Notion at nine and the dashboard already answers "what needs my attention": tasks due today and overdue, projects laid out on a board by stage, recent meetings. You don't click into each project one by one, the view is assembled from filtered databases, not from new data.

• "My tasks today" is a Tasks view filtered to due ≤ today and assigned to me.
• "Projects by stage" is a board of Projects grouped by Stage, so status is one glance.
• "Budget vs actual" is Finance rolled up per project, next to the work it pays for.

It grows with the company, not against it

The system grows by adding properties, not databases. A new product attribute is one column, not a new section. When people join the team you share top-level sections with permissions, and because the data isn't duplicated, access control stays clean: one database, one place to set who sees what. That is the difference between a system that grows with the company and one you have to rewrite after a year.

Architecture first, clicking second

I would start by designing the architecture, not by clicking. First the model: eight databases, their properties, the relations and rollups, and the reason behind each decision, so you understand the system instead of just receiving it. That can be billed as one closed phase. Then, if we fit, we build the workspace and I teach the decisions along the way.