I did not start by building a platform. I started by trying to make the quickest useful thing I could actually run on a page.
The first version of A11Y Cat was very direct. It was a bookmarklet. No extension packaging, no background service worker, no complicated release packaging, no long setup story. Just click a bookmark, inject a script, run some checks, and put the results in a panel.
I still like that starting point because it says a lot about the original problem. I was not trying to build an accessibility management system. I was trying to make page audits easier to run while I was already in the browser. The earliest ARCHITECTURE.md says the quiet part out loud: zero install, fast feedback, actionable output, accessible UI. That is not a grand vision statement. That is a list from somebody who wants the thing to be convenient enough to use.
The first commit is also interesting because it was not tiny. The initial README.md already described axe-based checks, metadata checks, alt-text analysis, manual checks, a developer sandbox, a screen reader quick audit, dashboard stats, and exports. So even at the start, this was not just “run axe and dump the JSON.” The bookmarklet was already meant to be a working audit surface, with opinions about how results should be grouped and shown.
At that point I still seemed to think the bookmarklet delivery model might be enough. The original architecture literally says the bookmarklet injects bookmarklet.js from a static host and then loads axe-core from a CDN. That probably felt like the most lightweight version of the tool. And to be fair, for cooperative pages, it was. You do not need store packaging. You do not need to explain extension permissions. You can ship fast.
But the first architecture doc also contains the future problem almost by accident: target-site CSP can block loading external scripts. That line is small in the original doc, but later it becomes one of the reasons the whole project changes direction. I do not think the first version fully appreciated how much delivery constraints would matter on real pages. It reads more like, “yes, that can happen,” not “this will eventually force a second delivery model.”
I also think starting with a bookmarklet shaped the tone of the product in a useful way. It made the tool feel local-first from day one. The original README says everything runs locally in the browser and no data is sent anywhere. That line survives in different forms much later, even after the extension, tests, exports, and optional AI work arrive. The transport changes. The privacy instinct mostly stays.
There is something else I like in the early repo: it starts with real screenshots and a public package, not just code waiting for an explanation later. That makes it feel like the goal was always “usable thing on a page,” not “promising architecture with a demo someday.” The tool existed in public form right away, even if the surrounding engineering discipline had not caught up yet.
So this first stage feels very recognisable to me. It is the stage where the product idea is still simple enough to hold in your head. I want a thing I can launch quickly. I want it to be useful without setup pain. I want it to show issues in a nicer way than raw engine output. I am not pretending I have solved everything yet. I am just trying to make the browser do something more helpful than it already does.
Visual evidence
This phase has one direct reconstruction from a runnable historical state, plus the launch-era screenshots already committed in the repo:
What I was really learning here
I was learning that delivery choices are product choices. I thought I was choosing the quickest implementation path, which I was, but I was also quietly choosing a boundary: this tool would only work where pages tolerated the injection model. I do not think that had fully sunk in yet.
Evidence
- Commits:
1ef3d3c– initial public bookmarklet package2bdd52d– GitHub Pages URL added right after the first commit8102c02– branded landing page added at the start
- Files:
../../README.mdfor the current state, compared against the originalREADME.mdin1ef3d3c../../ARCHITECTURE.md, especially the original version in1ef3d3c../../bookmarklet.js
- Visuals:
phase-01-reconstructed-initial/landing-page.png– direct historical screenshot captured from a checked-out worktree at8102c02phase-01-bookmarklet-launch/overview.pngandphase-01-bookmarklet-launch/manual-checks.png– existing repo assets from the launch-era screenshot set
- Inference:
- The “I was choosing speed and simplicity first” reading is an inference from the first architecture goals and bookmarklet-only delivery model, not from a separate design note.
