How to Build an App Like Notion

The block model

Every paragraph, heading, image, and embedded database row is a block with a type, properties, and a parent. Pages are blocks. Databases are blocks whose children are rows.

The elegance is real, and so are the costs:

Deep recursion. Rendering a page means walking a tree of unbounded depth. Naive queries produce N+1 explosions — you need recursive CTEs or a materialised path.
Ordering. Blocks need stable order under concurrent insertion. Integer positions require rebalancing; fractional indexing or a linked list avoids it.
Moves are re-parenting. Dragging a block subtree across pages must stay consistent, and permissions may differ at the destination.

Real-time collaboration is the expensive part

Two people editing the same paragraph simultaneously must converge without losing work.

Operational transformation transforms concurrent operations against each other. Powerful, and notoriously hard to implement correctly.

CRDTs — conflict-free replicated data types — converge by construction. Libraries like Yjs and Automerge make this tractable and are what most teams should use rather than building from scratch.

Either way you need presence (who's here, where their cursor is), an awareness channel separate from document state, and a persistence strategy that isn't "save the whole document on every keystroke."

Do not write your own OT engine for an MVP. This is the clearest buy-don't-build line in the category.

Permissions inherit, and that's subtle

A page inherits from its parent unless overridden. Sharing a nested page shares an ancestor path implicitly. Answering "can this user see this block" means walking up the tree, and doing it on every block render is a performance problem.

Cache resolved permissions per user per subtree, and invalidate on change. Getting this wrong leaks documents between workspaces, which is the failure that ends trust.

Offline is harder than real-time

Real-time collaboration assumes connectivity. Offline means local persistence, a sync queue, and conflict resolution on reconnect — CRDTs help enormously here, which is a strong argument for choosing them early if offline is on your roadmap at all.

Cut for an MVP

Databases with multiple views, templates, integrations, public sharing, and comments. Prove that nested blocks with real-time collaborative editing and correct permissions work first — that alone is a substantial build.

Related builds

How to build a SaaS MVP — tenancy, billing, and scope
Multi-tenant SaaS architecture — isolation done properly
Custom MVP development

FAQ

How does a block-based editor store data?

Every element is a block with a type, properties, and a parent, so pages are trees of unbounded depth. That needs recursive CTEs or materialised paths to avoid N+1 queries, and a stable ordering scheme — fractional indexing or a linked list — so concurrent insertions don't require constant rebalancing.

Should I build real-time collaboration myself?

No. Use a CRDT library like Yjs or Automerge. Operational transformation is powerful and notoriously hard to implement correctly, and hand-rolling either for an MVP is the clearest buy-don't-build line in this category. You'll still own presence, awareness, and a sane persistence strategy.

What's the riskiest part of a workspace app?

Permission inheritance. Pages inherit from parents unless overridden, so answering whether a user can see a block means walking the tree — and doing that on every render is slow enough that teams cache it. Getting the invalidation wrong leaks documents between workspaces, which is the failure that ends customer trust.