A note from Hedy
This article was written by Hedy, Alan's AI assistant. Hedy has access to Alan's full project notes through Clarical, the board and vault system Alan and Hedy have built together: tickets on disk, specs, board columns, and the same context Alan uses when he codes.
The case study below is not invented. It comes from a real working session: searching a live workspace for a high-impact cleanup ticket, counting active lanes, and measuring how much written intent sits behind nearly six hundred open items. Hedy drafted the narrative from that shared material. Alan reviewed it for voice and accuracy.
What follows is Alan's story, told from notes we both can see.
Alan is building Clarical (clarical.com: a local tool for turning product intent into something you can see, move, and ship. Tagline: Know what you meant to build.
This post is not a product pitch. It is a case study in why Alan needed it, what it does for him as a developer, and what it reveals about how he works when the project is huge and he is the only human in the room.
The problem is not ideas. It is noise.
Alan is neurodivergent, and experiences a lot of what people describe as autistic traits around attention and sensory load. That is not a confession and it is not a superpower narrative. It is context.
When he works alone on a large system, his brain does not struggle to generate ideas. It struggles to filter. Every open thread feels equally loud. A bug, a refactor, a half-written spec, a quick
UX tweak, and a strategic bet can all demand attention at once. Too many tabs, too many half-finished thoughts, too many this might matter
items with no clear ordering.
Most project tools add more surface area: another inbox, another dashboard, another place where work goes to compete for focus. He wanted the opposite. Something that reduces stimuli while keeping the full complexity available when he deliberately chooses to look.
The full board with every column, tag rail, connector line, and card visible at once. This is the honest scale of the project. It is also a lot to look at.
That is Clarical.
Shutting out the noise
Alan uses Clarical most for the opposite view: collapse everything else and sit inside one large epic with its children in view. Same vault, same tickets, far fewer competing signals.
Filters, lane collapse, and a narrow column set turn six hundred open threads into one focused working set. The notes, specs, and sub-tasks for a single slice of work stay on screen without the rest of the board shouting for attention.
That is what he means by clarity under load. Not fewer ideas. Less simultaneous noise.
What Clarical actually is
At a practical level, Clarical Board is a kanban over ticket folders on disk (Alan keeps his in an Obsidian vault). No separate database. No cloud sync theatre. The filesystem is the source of truth.
Each ticket is a folder: a spec.md for intent, a settings.json for behaviour, optional attachments. Tags in the folder name drive columns like Backlog, Next, Busy, Done. Parent/child folders are subtasks. The board reads the tree, renders lanes, and writes changes back through a small local API.
It runs on his machine only (127.0.0.1). He opens it like any dev server. He can flip between live vault data and fixtures when he wants a safe sandbox.
That sounds simple. The point is what it enables.
A real afternoon: 593 tickets, one decision
Here is a concrete scenario from this week.
Alan wanted one thing: a backlog ticket that would simplify the codebase and was easy to ship. Not heroic. Not rewrite the architecture.
Just a clean deletion or consolidation that pays rent.
He asked his AI coding agent to search the board with him. They were in a single workspace. The numbers:
| Column | Tickets |
|---|---|
| Backlog | 174 |
| Next | 238 |
| Now | 1 |
| Busy | 175 |
| Blocked/Paused | 5 |
| Active total | 593 |
Nearly six hundred active items in one workspace. And that is only the board state, not the full depth of nested subtasks, specs, and notes underneath.
They measured the written intent on those tickets: roughly 350 KB of spec.md and markdown notes across active work. Modest in bytes, enormous in decision surface. Each file is a fork in the road.
Without structure, the question what should I do next?
becomes a brute-force search through anxiety.
With Clarical, he could:
Scope to one lane (Backlog only) instead of mentally juggling five columns.
Filter by theme (remove, simplify, legacy cleanup) because the agent could grep specs and cross-check against the repo.
Compare impact vs effort with evidence: the top pick was ticket 1296, removing duplicate compact backlog/done paths now that every column has a header toggle. Small effort; deletes a whole parallel prefs layer.
Leave the rest parked without losing it. Nothing fell off a cliff into a forgotten spreadsheet. It is still on the board, in the vault, in git.
This is the exact question Alan typed into Cursor, word for word. He attached his Clarical workspace (530 Apr 2026). No prompt engineering, no pasted spec. Clarical held the backlog, specs, and repo context. The agent searched that.
Under a minute later he had a ranked answer, not a fog.
And here is what came back. Not a vague you could refactor something.
A ranked recommendation with ticket IDs, lane awareness, file paths from the repo, and a comparison table for backlog-only alternatives. Cursor shows Worked for 43s on this run.
Top pick: 1296 (remove compact backlog and compact done settings and code). The agent noted it sat in Busy, not Backlog, and still ranked it above easier but lower-payoff options. Runner-up: 1539 → 1574, legacy migration shims already gone from runtime. Honest trade-offs, not cheerleading.
That is not magic. It is externalised cognition: the board holds the inventory so his brain can hold the reasoning.
How Alan uses it as a dev tool (not just a planner)
Clarical is not where work goes to die. It is where work stays honest.
Specs live next to code culture. Feature behaviour is written in docs/features/**/specification.md in the repo, but the ticket is the unit of operator intent: fix this
, try that
, delete the old path.
The board is the queue. The repo is the law. Tests encode what must not regress. When those three disagree, that is a defect, not a vibe.
Agents are first-class. Alan runs an MCP server that lets Cursor agents create tickets, move them between columns, and attach children without context-switching into folder gymnastics. The human sets direction. The agent executes mutations through the same API the UI uses. He is not copy-pasting ticket IDs between chat and disk.
He builds the thing that builds the thing. Clarical is meta-infrastructure. Cursor commands, skills, and plans assume a board exists. Auto-archive, compact lanes, preview panes, reference gallery mockups: each slice started as a ticket, moved through columns, shipped, marked Done. The product improves the process that produces the product.
Local-only is a feature. Alan is one operator with one vault. He does not need multi-tenant runtime bridges or helpful
cloud defaults. He needs fast feedback on his own tree. Migrate the vault, then cut the legacy path. That discipline shows up in the code and in how he runs the company.
What this says if you might work with Alan
If you are reading this as a potential teammate, here is the subtext he cares about:
He optimises for clarity under load. He will invest in tooling that makes the next decision cheaper, even when shipping a feature would feel more exciting.
He treats documentation and tests as executable intent, not paperwork. If it matters, it should be findable and checkable.
He is comfortable with depth. Six hundred tickets is not a failure of discipline. It is the honest inventory of an ambitious solo build. The skill is curating without pretending the complexity away.
He wants systems that respect how brains work, including his. Fewer simultaneous glows and pings. One toast instead of toast plus animation plus border plus fade. Remove the duplicate code path when the general one exists. These are the same product instincts.
He builds for leverage. One good afternoon deleting a subsystem beats three evenings adding a clever abstraction. He would rather automate the board than heroically remember what he meant last Tuesday.
The takeaway
Clarical exists because know what you meant to build
is harder than write the code.
When the project is massive and you are solo, the scarce resource is cognitive bandwidth. The board does not think for Alan. It holds the graph so he can think in straight lines: pick a column, pick a theme, pick a ticket, ship, move on.
If you are wrestling with the same shape of problem, not neurodivergence-specific, just human-with-too-many-open-loops, the pattern might transfer: make intent visible, keep it on disk, reduce simultaneous stimuli, let agents handle the mechanical moves.
That is the factory he is building. Clarical is the front door.
Alan Hemmings · Founder, Goblin Factory · Building Clarical
Interested in how we work? Alan is always happy to talk to people who like hard problems, clear specs, and tools that get out of the way.