Handbook

Preface

How can we keep our important notes continuously up to date and organized as more information piles on and on?

Handbook takes the unorganised exhaust of learning (scattered LLM conversations, articles, notes, bookmarks) and organises it into a structured, searchable reference guide. The distinguishing move that separates it from NotebookLM or Notion? Content doesn’t pile up in individual clumps, requiring you to constantly organize it. Handbook automatically files new information in the right place of your guide so the structure stays living and uniform.

It’s like adding another drop of water to a pond. The content distributes neatly.

Outcomes

• A living guide builder that works end to end. Paste in raw material and Handbook places it in the right tab and section. It merges ideas that overlap with what's already there, starts a new tab when nothing fits and shows you the result before anything is applied. Live at handbook.it.com.
• I use this tool regularly. With a cohort of 6 usability testing candidates, I’ve built this tool off observations and pain points of working professionals and landed on a configuration that I find useful to open and interact with on a daily basis.
• Generation cost cut sharply so cost is optimized. A guide of 30 online articles once cost about $10 to generate. Moving to Sonnet, a working cache for tabs whose sources haven't changed, and dropping a second full rewrite pass brought that down. The second pass alone was about half the cost of a first generation.
• A bill of materials or components (BOM) that fuels the design system and user interface. The application’s components and tokens follow the documentation provided by an active linkage between Figma MCP and the codebase.

The problem: learning that scatters

Especially in today’s world where learning and written material is practically free, fragments of important information grow and become spread across too many places. No tool turned these pieces into something structured that kept up with the new developments in my learning.

The clearest case for me was music. I taught myself to mix and master my own tracks properly chatting with Claude. It worked! My mixes came out louder, cleaner and more professional. But the learning grew to live across a dozen conversations and notes. Every time I wanted to reapply a technique, I was scrolling and sifting, excavating old chats to find it. Not to mention, if I learned something new, I would want it to either overwrite or sit amongst adjacent concepts I already knew.

What I built

A tool that ingests raw material from wherever you learn and returns neat, referenceable categories. You keep feeding it; new information lands in the right place and merges with what is already there rather than piling up. You don’t need to file anything by hand (unless you choose to).

The mechanism felt like how we think about liquids: adding a new source should feel like adding a drop to a homogeneous mixture. It blends in, the whole stays coherent, nothing clumps or duplicates.

Because the structure is generated rather than authored, the product is domain-agnostic. The same pipeline produces a design reference, a cooking guide, and a weight-training program.

What’s great about building a handbook is the guide stores as markdown, making it easily exportable and interpretable by your favourite coding agent. It’s a guide for both you as the human author/reader as well as for machines!

The early-on choices I made, and why I reversed them

While making an AI-based product, it can become tempting to power every functionality with AI. Originally, I wanted to have AI not only organize information by subject matter, but also stylize and categorize information into different types of content:

• what information is a principle?
• What should I mark as an anti-pattern (notes on what to avoid or be wary of)?
• Show me key quotes among raw text or prose

I built the functionality, however, after building several handbooks and seeing the output my testing participants got, it was clear that this mechanism was not sufficient enough to make a judgement call on ranking information by principle, anti-pattern, quotes etc.

I quickly realized that too many pieces of information were being classified as a principle over regular prose arbitrarily, with no clear rationale as to why the decision was made. I looked a little deeper in the code with Claude and the differentiation was simply because of text formatting the user never had a hand in, so it was truly an arbitary decision.

The question the product appeared to answer: “Is this a principle?” was never being asked.

The fix wasn't a better prompt. It was admitting the question was wrong. "Principle or prose?" has no right answer, so the model can't be accurate at it and you can't meaningfully disagree. "Does this deserve a name?" you can judge at a glance, and overrule by typing one. The four types are gone. Every block is a heading and a body, and the heading is yours.

Auditing the AI file organizer capability.

Editing blocks of written content, dragging them around, undoing a mistake — Notion does all of that, and does it better. The one thing with Handbook you can't get elsewhere is what happens when you add a new piece of content: a new note finding its place in a guide that already exists, and merging with whatever already said it.

Like with many feature builds using AI, one has to test functionality to make sure things are working as intended. For this key functionality, I needed to ensure the merging of new content into existing material happened successfully after multiple usability tests revealed that:

• the AI function was not detecting all the information that was being loaded into Handbook
• If the AI function was sorting and organizing information, it was only based on section headers (not the subject matter of a section’s contents).

These issues have since been fixed where the AI function now detects all the information being loaded into Handbook and sorts based on all existing material present within so that merging is accurate and based on the actual data.

What I still don't know is whether it feels right — how close two passages have to be before merging them is a number I picked, not one I’ve tested rigorously.

Design decisions that define it

• Sources in, handbook presses out. The founding pivot: the product does not curate fixed content, it ingests your raw material and generates the structure. You bring the mess; it makes the shape.

• Merge by meaning, always visible. New content is embedded and compared against what exists. Near-duplicates merge by default, related ideas sit together, genuinely new ideas start a new section, or a new tab when the guide has no category for them at all — and every merge is surfaced, never silent. This is the drop of liquid into the mixture.
• Never auto-apply; always reversible. Generations preview before they apply. Undo covers every hand edit, snapshots cover everything the AI does, and a bad result can never cost you your guide. Trust was designed in from day one, not bolted on.

• The reading surface is the editing surface (just like Notion). You rewrite a block where it sits, drag it into place, name it or unname it, send it to another tab. Underneath it is all markdown — that file is the artifact you own, and the blocks are a way of reading and rearranging it rather than a second copy of it.

• Search is the primary action. It sits centered in the top nav rather than buried in a toolbar, because a reference tool is only as good as your ability to find the one thing you need right now.

Open questions I am still sitting with

These are not roadmap items. They are honest questions about the structure I have already built, looking back at it as it stands.

• How much should the model decide at all? Retiring the type vocabulary moved one judgement from the machine to the reader. The open version of the question is where else that trade applies: how much structure should be proposed rather than imposed, and what is the smallest correction that makes a wrong proposal cost nothing.
• Is tab → section → atom the right shape for everything? It fits a reference manual cleanly. Does it fit a workflow, a process, a story — or am I forcing every domain into the shape that suited the first two I built for?
• How much automatic reorganisation is too much? Self-organisation is the magic, but it also means the structure can move under someone who thought they knew where things were. Does that build trust, or quietly break a user's mental model of their own guide?
• Where is the line between a threshold and a judgement? Merging fires above a similarity score. Set it high and obvious restatements pile up as duplicates; set it low and it fuses things that merely rhyme. There is no correct number, only a number that feels right to the person whose knowledge it is — which suggests it should not be my number at all, and I do not yet know what the alternative looks like.

Where I am taking it next

• Calibrate the merge. The mechanism works; the judgement is untuned. Real pastes against a real guide are the only thing that will tell me whether the threshold is close, and whether merging should be rewriting someone's words at all.
• Polish the front door. Make the component library as refined as it can be and attach a genuinely attractive landing experience. The tool should look as considered as it is.
• Make adding data frictionless. Adding a source should feel like adding a drop to a homogeneous mixture — instant, clean, self-organising, with no manual filing.
• Make search powerful. It needs to sift the whole guide and surface exactly what matters in the moment you are looking — fast, robust, and smart about meaning.
• Earn trust with other people's data. As people host their own handbooks here, I need to raise the bar on security and safety.
• Decide the economics. How much do I invest in providing the AI tokens that make the magic happen, and where is the sustainable line?