Replacing Notion with a Tool Built Around How I Actually Work

At the end of 2025 I took a short Udemy course on Notion and decided to use it for my second brain. My automation work with Make had already made it a priority to understand widely used SaaS products, and Notion was on the list. After the course I adopted it for a number of purposes and planned to write several blog posts about how I'd built my whole organisation system around it. That was until I found its faults and saw how it really didn't work for me at all.

The hardest part of my role as product manager is the context switching. In my early days at BAFTA Tech I was responsible for sales, marketing and support as well as defining features and being the product bible. Now, with more clients and projects, I need to get up to speed on work I haven't touched in months, jump into something new or allocate my time effectively, and planning is the key word for all of it. Before Notion I ran everything off my Google Calendar: every minute between meetings blocked into chunks, and anything unfinished just moved to the end of the day and got reprioritised. But as the work and the projects got longer, blocks kept getting moved and moved until it became unworkable.

I needed an additional resource to manage tasks: I couldn't just create a diary block for something due sometime next month, and I wanted another way to organise the work itself. Notion looked like the answer. I could create projects, keep a tasks database and use Make to sync it with my calendar, creating an event when a task was scheduled and moving it when the task changed. I never got that resync fully working, and after several months the whole thing was breaking and fragile.

Around March I discovered MCP servers with Claude and started writing documentation as I went, editing straight into Notion. It was painfully slow, more time spent clicking accept and waiting than actually writing, which defeated the point of having AI review what I'd written. Claude Cowork and working in markdown documents changed that, and it was much faster. By late May my Notion usage had dropped off and I knew the product wasn't working for me. Having vibe-coded other products before, I knew the answer: build my own.

The approach

I didn't have an overarching idea of what the product should be, but I decided it only needed to work on my desktop, which made development easier. It needed to feed into my diary, since that's the screen I actually wanted to work from. It needed pages to work as context, cards for tasks and an MCP server so it could work with Cowork. I took the proposal to ChatGPT, which tried to convince me to use off-the-shelf solutions instead. I looked, but decided I didn't want the cost or to adopt yet another system I'd end up dropping. From my initial research there was nothing that did exactly what I wanted, partly because I didn't know exactly what I wanted myself, so I decided to bite the bullet and build it myself using Claude Code. If it worked, great, and if it didn't, I'd at least have a story about how not to build something.

Claude and ChatGPT went back and forth and defined the architecture and the core foundation, and this is important, because most of what came later was me tweaking the UI rather than changing what the core product actually was. The core model was: one diary maps to one board, cards hold the work, and diary entries become sessions against those cards unless they're meetings.

So with those stages mapped out, Claude started building. I'll be honest, I wasn't always completely sure what it was building because I ran most of this project while watching the World Cup, and I deliberately didn't want it turning into days and days of work like some of my other side projects had.

The build

The order I actually built in came down to one practical decision rather than the original plan: I needed to start using Continuum and refine it against real use before I went too far down a design that might turn out to be wrong. The initial design went in first: the database schema, the command layer every write goes through and the logic that works out which bucket a card belongs to (Today, This Week, Next Week, Later, Waiting) without ever storing that bucket anywhere. I checked that foundation by hand through a real session with Claude rather than trusting the test suite alone, and it caught a genuine date mistake on Claude's side before anything else got built on top of it.

Once that existed I brought in the cards I already had rather than working against sample data. Importing my Notion backlog wholesale brought in around 196 cards, well past the 40-card alarm the original plan had set for "you need to triage this down". I pulled everything in on purpose rather than pre-filtering, on the basis that Continuum could sort it out once the data was actually inside it.

Working through those real cards is what actually refined the dashboard, not a spec written in advance but watching how cards behaved once real work was sitting on them. One rule I kept even when it would have been easier not to: you can't drag a card between the bucket columns on the board. Buckets are worked out from dates rather than stored, so dragging a card would mean the UI writing a value the architecture doesn't allow. When the itch to add it anyway showed up, I took that as the signal to stop, not to bolt on a workaround. A real-browser check, not just the automated tests, also caught a UI bug the tests had missed entirely, which turned into a habit for the rest of the build: looking at the running app is a different check from running the test suite, not a substitute for it.

This split was actually there from the start, even if I hadn't quite internalised it until I was living in the tool. A card and a diary entry were never the same thing. The card holds the details: title, description, notes, a checklist and its status. A session is just the diary link, a block of time tied to a card, and a card can have no sessions at all, one or twenty scattered across weeks. The sessions table existed in the schema from the very first phase, well before the calendar was even connected to it. What changed through actually using it was less the architecture and more my own picture of what a card was: once cards started accumulating several sessions each, it became obvious a card could function as its own small project rather than a single task.

After that it connected to my actual calendar, read only. Meetings get filtered out by whether anyone other than me is on the invite. Everything else gets matched against my open cards by title, and because most of my diary blocks were already synced from Notion, an exact match against one open card was enough to link a session with no extra formatting needed. Anything uncertain goes into an inbox rather than being guessed at. Chasing down a discrepancy in this phase also turned up a real timezone bug: Google's time offsets were being compared as text rather than as actual times, which meant some sessions silently failed to match when they should have.

This is also where the original problem actually got solved properly. Diary blocks that used to just get moved and moved until the day became unworkable now become lapsed if their time passes without being marked complete, and a lapsed session is what drives rollover: the work surfaces again on the next sync instead of quietly disappearing into a moved slot.

The original plan had the knowledge side of the tool, write-ups and handover notes, coming before the ability to write back to the calendar. I built it the other way round, for the same reason as everything else: I needed to be using the tool, not just building it. A tool I can't use to actually book time isn't one I'll use every day, so calendar write came first. That's the part that lets me tell Continuum to give me two hours on something and have it create the diary block itself, tagged to the card from the moment it exists, so it never has to be matched or guessed at afterwards. Given how eager the auto-create logic had turned out to be earlier on, I ran the scheduler in preview mode first, showing me the slots it would book without writing anything, before I let it touch the real calendar.

What went wrong

Not everything survived contact with actually using it. An early version tried to auto-pick a free slot for me, and I pulled it back out: a technically empty evening isn't automatically a sensible time to work, and that's a decision I want to keep making myself. The bucket that was meant to show "what needs me today" once showed 87 cards, of which exactly one was actually due that day, which meant it had stopped meaning anything, so I split overdue out into its own bucket instead.

I also made two actual mistakes worth admitting to. I edited an already-applied database migration directly instead of writing a new one, which is precisely the sort of thing that's supposed to be impossible, so a check now exists that makes that mistake fail loudly if it happens again. A bulk import also changed some of its own decisions after I'd already approved a dry run of it, which taught me not to assume an earlier yes still holds once anything has changed since.

What actually works

Alongside all of that I built a test suite that grew with the tool rather than getting bolted on afterwards. Each invariant gets a test before anything is built on top of it, which is how the bucket rule, the migration checksum guard and the born-linked session logic all got proved before I trusted them with real data. There are 188 tests passing now, run with Node's own test runner, and the typecheck is clean. A handful of the more important ones proved things I couldn't just eyeball: that a status change made through the UI and the same change made by asking Claude produce an identical entry in the operation log, that no bucket value is ever actually stored anywhere and that moving an event in Google only ever touches a session's times and never the card underneath it.

What's made it work day to day is the same thing that shaped the order I built it in: using it. Being both the product manager and the only user means feedback goes straight back into the build. If something's missing I can build it, test it and refine it again the same day, because I'm still working out what I actually want from it as I go rather than building to a brief someone handed me.

What's next

Continuum is still a prototype, but it's now at the point where I'm using it every day. I'm still tweaking it and there's more to build, the knowledge layer especially, but it's already doing the job: it's organising my work better than Notion did and better than anything I'd used before it. I've already cancelled my Notion subscription.