Is Notion Enough for Your Business?

Almost every growing business we speak to already has a workspace. Notion, Confluence, Google Drive, a shared folder structure someone set up carefully two years ago. It was built with real effort, it looked excellent for about a month, and now nobody opens it. The instinct at that point is to blame the tool and start evaluating a replacement. That instinct is usually wrong, and acting on it costs a quarter you won't get back.

The pattern: a beautiful workspace nobody opens

It goes the same way almost every time. Someone senior gets frustrated with the same questions being asked repeatedly, blocks out a week, and builds something genuinely good — nested pages, a clean hierarchy, templates, an onboarding section. For a few weeks people use it. Then a process changes and the page describing it doesn't. Then someone can't find the thing they need and asks in Slack instead, and gets an answer in forty seconds. Then everybody learns that asking is faster than looking.

Within a couple of months the workspace is a museum: accurate about how the company worked at the moment it was built, and quietly misleading about how it works now. The knowledge went back into people's heads, which is where it was before.

The third stage is the one worth staring at, because that's where the whole thing turns. Nobody decided to abandon the wiki. One person had a bad experience with it, took the faster route, and the faster route worked. Everyone who watched learned the same thing, and after that the wiki isn't competing with a better wiki — it's competing with asking a colleague, which is instant, conversational and always current. A page has to be very good indeed to beat that, and it only has to lose once.

Notice that nothing in that story is a complaint about the software. The pages rendered fine. Search worked. What failed was everything the software was never going to do on its own.

What Notion and its peers genuinely do well

Being fair about this matters, because a comparison that pretends the alternative is bad is no use to anyone deciding.

Modern workspace tools are excellent at what they're for. They're flexible enough to model almost any structure you can describe. They make writing and linking easy enough that people will actually do it. They handle permissions, version history, and collaborative editing without anyone thinking about it. Databases and relations let you build genuinely sophisticated structures without writing code. For a small team, one of these tools plus reasonable habits will carry you a surprisingly long way.

They are also, for most businesses, entirely sufficient as the surface. When we build a Business OS, the client's existing workspace usually stays exactly where it is. The problem was never the container.

It's worth saying the uncomfortable half of that out loud too: if you migrate, you will feel better for about six weeks. New software is genuinely motivating, and the act of moving forces someone to read every page and rewrite the worst ones. That's real value — but it came from the reading, not from the destination. You can have the same benefit without the migration, and keep the quarter.

Storage is not a system

Here's the distinction the whole question turns on. A wiki is a place to put things. A system is what decides what goes in, keeps it true, routes it to the person who needs it, and notices when it's wrong.

Put another way: a workspace tool is passive. It will hold whatever you give it, in whatever state you leave it, indefinitely, without comment. It has no opinion about whether the onboarding checklist still matches how you onboard. It cannot tell that two pages contradict each other. It won't notice that the person who wrote the refund policy left in March and nobody inherited it.

Everything in that list is a job. In most businesses those jobs are unassigned, which means they're done occasionally, by whoever is most annoyed, until they stop being done. That's not a tooling gap. It's an ownership gap wearing a tooling costume, and buying different software doesn't touch it.

Why the wiki goes stale, mechanically

It's worth being specific about the mechanism, because "people didn't keep it updated" is a description rather than an explanation.

Documentation decays when updating it is a separate act from doing the work. A process changes because someone made a better decision in the moment — that's healthy. But the decision happened in a call, or a thread, or someone's head. Reflecting it in the wiki is a second, optional task, performed later, by someone with no particular obligation, with no deadline and no consequence for skipping it. Multiply that by every process, every month, and the drift is not a surprise. It's arithmetic.

The asymmetry is what makes it relentless. Changing how the work is done takes a moment and produces an immediate reward; recording the change takes ten minutes and produces nothing anyone can see today. Nobody is being lazy. They are correctly reading the incentives in front of them, and the incentives say the page can wait. Any fix that relies on people ignoring those incentives forever is not a fix.

Three things break the cycle, and none of them is a better editor. Somebody has to own each area, by name. Review has to be scheduled rather than aspirational. And the knowledge has to live where the work happens, so that using it and maintaining it are the same motion rather than two. We go through the practical version of this in process documentation.

The findability problem

The second failure is quieter. Even when a page is accurate, people don't find it — and a document nobody finds has the same value as one that doesn't exist.

This is partly structural. Wikis grow by accretion: pages get added where whoever created them thought they belonged, and after a year the hierarchy reflects the order things were written rather than any logic a newcomer would guess. Search helps only if you know the term the author used. Someone looking for "how do we handle a refund" won't match a page titled "Client Resolution Protocol v2".

It's also a naming problem, and naming is unglamorous enough that nobody defends it. Pages get titled the way the writer was thinking on the day, which is almost never the way the reader will be thinking when they need it. The single cheapest improvement available to most workspaces is renaming the twenty most-needed pages to the question they answer — and it costs an afternoon, which is a fraction of what an evaluation of a replacement tool costs.

An internal assistant trained on the knowledge base changes this substantially — you ask in your own words and get the answer with its source, rather than hunting. That's one of the more immediately valuable things we build. But it comes with a warning worth stating plainly: retrieval amplifies whatever is in there. Point an assistant at a stale wiki and you get stale answers delivered with more confidence and less friction than before. Accuracy has to come first, which is why organizing the knowledge is the step people want to skip and can't.

Nothing in a wiki makes a decision

The third gap is the one founders feel most and name least. Documentation tells someone how to execute a task. It doesn't tell them how to judge.

Most of what actually bottlenecks on a founder isn't procedural — it's judgement. Should we take this client. Is this discount reasonable. Does this piece of work meet our standard. Do we make an exception here. No amount of process documentation answers those, so they route to the one person who knows how the business thinks, and that person becomes the constraint no matter how good the wiki is.

What resolves it is encoding the reasoning rather than the procedure: what we optimise for, what we won't trade away, who decides what at which threshold, and what to do when it's genuinely unclear. That's a decision framework, and it's the piece almost no workspace contains, because a workspace has no format that asks for it.

The test for whether you have one is blunt. Pick the last five judgement calls that came to you and ask whether someone else could have made the same call from something written down. If the answer is no five times, the wiki isn't the thing that's missing — the reasoning behind those five calls has never left your head, and no page structure will get it out.

What a Business OS adds around the tool

Set against that, a Business OS isn't a different place to put documents. It's the set of things that make documents stay true and get used.

It assigns ownership, so every area of knowledge has a name attached and staleness has somewhere to land. It schedules review, so currency is a routine rather than a rescue mission. It captures decisions and reasoning, not just procedures, so judgement can be delegated. It puts knowledge in the path of the work — surfaced in the tool people are already in, answerable by an assistant, attached to the process it describes. And it treats the whole thing as something that evolves with the business rather than a document set that was correct once.

The tool underneath all of that is frequently still Notion. That's the point. We design the process first and choose tools to serve it, never the reverse — technology is a tool, never the goal. Set the two side by side and the left column isn't the competitor of the right one; it's a component of it.

A worked example: the same Notion, twelve weeks later

Here is what that looks like in practice, on a workspace nobody was opening. The business: a studio of about a dozen people, two years of Notion, roughly four hundred pages, and a founder answering the same six questions every week. The brief they arrived with was "help us pick a replacement." We didn't touch the tool.

Week one was an afternoon of naming owners. Four areas — delivery, sales, finance, people — and four names, written at the top of each area's index page. Nothing was reorganised and nothing was rewritten. The only change was that every page in the workspace now had somebody whose job it was to care about it, which had never been true before.

Weeks two and three were the decision ladder above, written with the founder over three conversations and about two thousand words. That was the hardest part, because it required saying out loud what had only ever been intuition — what a discount may go to before it's a conversation, what makes a project worth refusing. Then the twenty most-asked pages were renamed to the questions people actually type, and an assistant was pointed at the workspace so those questions could be asked in plain language.

Week four was the board above, built in Claude Code and run in n8n: half a day, six nodes, no new subscription. By week twelve the founder's repeated questions had dropped to one or two a week, and the workspace had its first quarter in two years where every process page was reviewed. Same Notion. Same pages. Different jobs around them.

What fixing it actually costs

The honest number matters here, because the alternative on the table is usually a migration, and migrations are quoted optimistically by everyone including the person proposing them.

Naming owners costs an afternoon, once, and it is genuinely the whole of that cost — you are assigning existing people to existing pages, not creating work. Writing the decision ladder costs the most, because it costs the founder's attention rather than anyone else's: two or three conversations of an hour, plus the discomfort of committing to thresholds that were previously flexible. Renaming the twenty pages people actually need is an afternoon. The automation is half a day.

Then there's the part that never ends, and it's about an hour a month: the owners clear their flagged pages, and once a quarter somebody reads the review log. That hour is the entire difference between a system and a very good week of documentation. Skip it and everything above decays exactly as before, just from a higher starting point.

Set that against the migration. Even a well-run move to a new workspace takes a quarter of somebody's attention, breaks every link anybody had bookmarked, and lands you in a tool with the same missing jobs. The pages will be tidier, because someone read them all on the way through — and that improvement, the only real one, was available without moving anything.

The one cost we won't pretend away: this needs the founder in the room for a few hours, and it can't be delegated. Owners and cadence can be set by anyone senior. The reasoning behind the judgement calls exists in exactly one head, and getting it out is the part of the work that has no shortcut.

When a wiki genuinely is enough

Often, and we'd rather say so than sell past it.

If you're two or three people who talk constantly, a shared workspace and good habits are genuinely sufficient — the coordination overhead of a formal system would cost more than the confusion it removes. If your processes are still changing weekly because you're figuring out what the business is, documenting them properly is premature; you'd be systematizing something that won't survive the quarter. And if the questions people repeat are minor, the honest fix is a better-organized page, not an engagement.

The threshold is roughly this: a Business OS starts paying when the same questions reach you more than once a week, when a new hire takes longer to become useful than you can afford, when work stalls because you're unavailable, or when you can name knowledge that exists in exactly one person's head. Below that, tidy the workspace and get on with the business. We cover the fuller version of this in why every growing business needs a Business OS.

And if you're above the threshold, the bottom line is short. The replacement you're considering will fail in the same way for the same reasons, roughly eight weeks after you finish migrating. The pages were never the problem — the absent jobs around them were: nobody owning an area, nothing scheduling a review, no place for judgement, and no reason for anyone to look rather than ask. Fix those and the tool you already have is usually fine. That's a cheaper answer than a migration, and it's the one we give most often.

Frequently asked questions

What's the difference between a wiki and a Business OS?

A wiki is a place to put things; a Business OS is what decides what goes in, keeps it true, routes it to whoever needs it, and notices when it's wrong. The wiki is usually a component of the Business OS rather than an alternative to it — in most of our builds the client's existing workspace stays exactly where it is and the system is built around it.

Do I have to move off Notion to build a Business OS?

Almost never. In most builds the existing workspace stays and becomes the surface the system runs on. Migrating tools is disruptive, expensive in attention, and usually solves nothing — the workspace was rarely the thing that was broken. We design the process first and fit it to the tools you already pay for, adding something new only when a genuine job has no home.

Why does our company wiki always go out of date?

Because updating it is a separate act of goodwill rather than part of doing the work. A page is written once by someone with time, then the process changes and nothing forces the page to change with it. Nobody owns it, nothing flags it, and there is no moment in anyone's week when reviewing it is the obvious next step. Decay isn't a discipline failure — it's the predictable result of documentation that sits outside the workflow it describes.

Isn't this just better documentation discipline?

Discipline is what you need when the design is wrong. Every team that has tried to fix a stale wiki with a documentation push has watched it decay again within a quarter, because willpower was the only thing holding it up. A system changes the design instead: ownership is assigned, review is scheduled, and the knowledge is surfaced where the work happens, so staying current is the path of least resistance rather than an extra task.

Can AI make our existing wiki useful?

It can make a good wiki much more useful and a bad one more confidently wrong. An assistant trained on your documentation answers questions in seconds instead of sending people hunting through pages — genuinely valuable. But it will answer just as fluently from a process that changed eight months ago. Retrieval amplifies whatever is in there, so the accuracy and ownership work has to come first.

How is this different from a project management tool like Asana?

A project tool tracks work that someone has already decided to do and assigned to someone. It's a strong answer to what's in flight and who has it. It doesn't hold why the work is done that way, what good looks like, how an edge case gets decided, or what a new hire needs to read. Task tracking and operating knowledge are different jobs, which is why most teams end up with both and still can't answer basic questions.

How long does it take to fix a workspace nobody uses?

About four weeks of elapsed time, and far less in actual hours. Naming an owner for each area is an afternoon, renaming the pages people actually need is another, writing down how judgement calls get made takes two or three hours of the founder's time, and automating the review reminders is half a day. After that it's roughly an hour a month, forever — and that hour is what separates a system from a very good week of documentation.

Keep reading

• How to build a Business OS — the six steps, in order, with what each one produces.
• Why every growing business needs a Business OS — the growth ceiling this article's threshold is describing.
• Process documentation: a practical guide — how to write docs that survive contact with a real team.