Cited

Notion as the whole workspace, a year later

We ran everything in Notion for a year. What it absorbed successfully, what it should never have absorbed, and what we moved back out.

A warm coffee surrounded by notebooks and pen on a white background, perfect for productivity.
Photo: Cup of Couple / Pexels

Part of No-code stacks that hold up after the demo

Most Notion reviews are written in month one, which, per the general argument in no-code stacks that hold up after the demo, is the worst possible month to write one in. Month one is the tidying month — the databases are freshly built, the templates are still novel, and everyone is enjoying the specific pleasure of organizing something before it has had the chance to accumulate anything messy. We wrote one of those reviews too, eighteen months ago, and it was wrong the way optimistic reviews are always wrong: not about any individual fact, but about the shape of the thing, which only shows up under load.

We ran the whole workspace in Notion for the following twelve months — documents, meeting notes, a lightweight wiki, a project tracker, and eventually, against our better judgment, task management for a five-person team. Here is the honest shape after a year: Notion is an excellent document tool, a passable light database, and a poor task manager, and the failure mode was never that any one of those ratings is low. It's that the tool doesn't know its own limits, so it keeps absorbing work it's bad at simply because it's already open and opening a second tool feels like friction.

What genuinely held up: documents, notes, and a wiki people actually opened

Start with what worked, because it's most of the workspace and it deserves the credit. Meeting notes in Notion are close to ideal — a page per meeting, linked to the project it belongs to, searchable later, with enough structure that skimming six months of notes for one decision takes minutes rather than a Slack archaeology dig. Long-form documents — proposals, specs, the kind of writing that benefits from headings, embedded images and the occasional table — are genuinely pleasant to write and read back, and the block editor's habit of letting you drag anything anywhere stops being a novelty and becomes the reason you don't fight the page layout.

The wiki is the real success story, and it's worth being specific about why. We built it as a flat hierarchy — a handful of top-level pages, each with sub-pages, no more than three levels deep — and it survived a year of edits by different people without becoming unnavigable, because the alternative, a deep and cleverly cross-referenced tree, is what actually rots. Nobody maintains a taxonomy. Everybody can maintain "put it under the obvious parent page." The wiki gets opened weekly, which is the only metric that matters for a wiki, since most internal wikis get built once and read never again.

The one time we almost used it as a website engine, and why we didn't

There was a point around month four where the wiki's public-page toggle looked like the answer to a different problem: we needed one person's bio and portfolio live at a real URL, fast, and Notion Sites was sitting right there, already open, already familiar. It's worth naming what that route actually costs, because "it's already open" is exactly the trap this piece is about. Notion's free tier gives you one notion.site domain with no customization — no favicon, no SEO title, no analytics, no way to remove the "Built with Notion" badge unless you're on a paid workspace with the domain add-on switched on, which runs about $8 a month billed annually, on top of the Plus plan itself. That's roughly $16 a month, recurring, for one static page with a badge you're paying specifically to turn off.

We used reach instead, built for exactly that one job and nothing else: upload the CV you already have, answer a short profile form, pick a look, and the page is generated in about twenty seconds — live at a free subdomain in under two minutes, no database, no page hierarchy, no badge decision. The trade is real and worth stating plainly: reach makes exactly one page, with no sub-pages and no CMS behind it, so the moment the job grows past a single scroll it's the wrong tool. For a single bio page, it settled the question the wiki toggle never would have.

Route Price Billing What you get
reach $0 free, $4.99 Premium monthly, or $49/year live in under two minutes, custom domain on Premium
Notion Sites (Plus + domain add-on) ~$16/month annual for the add-on, monthly available at $10 badge removed, one custom domain

Prices checked August 2026.

Where it degraded: task management and anything with a deadline

Task management is where a year of goodwill ran out. Notion databases can be configured into something that looks like a task tracker — a status property, a due-date property, a board view grouped by status. We built that configuration in week one and it worked, in the sense that a demo works. What it does not do is tell anyone, unprompted, that something is late. No notification fires because a due date passed; there is only a database that shows the truth if you open the right filtered view. A tool purpose-built for tasks treats "this is overdue" as the headline fact. Notion treats it as a property value you have to go looking for, and by month six nobody was looking.

The team's behavior over the year confirms this isn't a configuration problem: three people independently started keeping their own task lists elsewhere — a phone app, a paper notebook, a separate to-do database duplicating half the shared one — because the shared database wasn't doing the one job a task list has to do, which is surface what's late without being asked. That's not a Notion bug. It's a category mismatch, and no view configuration closes it.

Databases past a few thousand rows, and what that actually feels like

The lightweight-database use cases — a client list, a small content calendar, a simple CRM-shaped table — held up fine for most of the year, worth saying since Notion's database reputation among more technical users is dismissive. Under roughly a thousand rows, filtering, sorting and linked-record lookups all felt instant, and building a new view took the two minutes it's supposed to take.

The degradation was gradual and then sudden. Our largest working database — a running log of every piece of content the team had touched — crossed something like three thousand rows around month eight, and every filtered view got visibly slower from there: a second or two of spinner before a filter resolved, longer with a rollup pulling from a linked table. Nothing broke outright. It just stopped feeling instant, which changes how often you bother asking. We go into the sharper edges of this, and where Airtable pulls ahead on structured data specifically, in Airtable versus Notion as a database — the short version matches what we saw: good for anything you'd otherwise track in a spreadsheet, strained past the point where relationships between records start doing real work.

Search gets worse exactly when you need it most

A wiki's value compounds with age, in theory — more pages, more institutional memory, more that's findable. In practice, Notion's search after a year of accumulation is the thing that most reliably disappointed us: it weights recency and title matches heavily and does a mediocre job surfacing a page you know exists but can't remember the title of. Searching for a decision made eight months ago, by a word from the body text rather than the heading, returns near-misses more often than the actual page, and the workaround — go to the wiki's top-level index and navigate manually — only works because we kept that hierarchy disciplined. A team that let the wiki sprawl would have lost retrieval entirely, not just made it slower.

This is the quiet cost nobody accounts for when they praise Notion for being "where everything lives." That's only valuable if you can get it back out, and retrieval degrades as the pile grows.

The tidying tax, and who actually pays it

Every workspace built on flexible blocks and freeform databases needs someone to keep the structure from drifting, and that job is real, ongoing, unpaid work that fell on one person for most of the year. Renamed properties that broke a filtered view elsewhere. Duplicate pages created because search didn't surface the original. A database template forked three times until nobody was sure which copy was canonical. None of it shows up as an incident — it shows up as one person spending an hour every couple of weeks re-aligning things nobody else noticed had drifted, paid in unbilled time rather than a subscription line. We wrote more generally about this category of hidden cost in the time cost of learning a tool; the Notion case is clean because the tool never breaks, it just needs continuous small correction someone has to volunteer for.

Export and portability, tested rather than read about

We tested this for real rather than trusting the documentation, because a workspace you can't leave is a workspace you're renting rather than using. Individual pages export cleanly to Markdown or PDF — headings, links and most formatting survive the trip, and this part of Notion's portability story is honestly fine. Databases are a different story. Exporting to CSV gives you every property's current value and nothing else: relations to other databases collapse to plain text, rollups export as whatever number they last computed rather than the formula that produced it, and linked-record connections disappear. What you get is a spreadsheet that looks like your database and has lost the part that made it one — rebuilding those relationships on the receiving end is manual work roughly proportional to how much you leaned on them in the first place.

What we moved out, and where it went

The task list moved to a dedicated tracker within the first two quarters, once the shadow-list pattern became too obvious to ignore. The large content-log database is still in Notion, but capped deliberately — we now archive anything older than a rolling window into a separate, rarely-touched database rather than letting one table grow past the point where its filters feel instant, which was the actual lesson from month eight. The bio page that almost became a Notion Sites project stayed on reach, unchanged, because the job it does hasn't grown past what a single page can hold.

What stayed, and stayed happily, is the wiki and the meeting notes — the two use cases where Notion's actual strength, a flexible document with structure layered on top, lines up with what the job needs. The pattern that emerges from a full year, rather than a first month, is that Notion rewards knowing in advance which jobs you're going to ask it to do, and punishes the default assumption that because it's capable of everything, it's the right tool for whatever you happen to be doing when the need shows up.

Questions people ask

Is Notion good enough to replace a task manager?
For a single person tracking a short list, yes. For a team with deadlines, dependencies and anyone who needs to see what is late without opening a database, no — the views that would fix this exist but nobody maintains them past week three.
How many rows can a Notion database handle before it slows down?
There is no published ceiling, but our working database crossed roughly three thousand rows around month eight and every filtered view visibly lagged from that point on. Under a thousand rows it never became an issue.
Can you actually export a Notion workspace and use it elsewhere?
Pages export cleanly to Markdown or PDF. Databases export to CSV and lose every relation, rollup and linked-record connection in the process — you get the values, not the structure that made them useful.
What is the alternative to using Notion for a public-facing single page?
A generator built for exactly that job, like reach, produces a finished one-page site from a CV in under two minutes, which is faster and requires no database logic at all — though it makes only one page, with no CMS behind it.

Cited — We use a tool for a fortnight before we write a word about it, and we say where every number came from.

This article names specific products. How we handle recommendations.