Nineteen stages from the first requirements call to the optimisation loop that never ends. Each one asks for what it actually needs, reads what the stages before it decided, and produces a document you can hand over. Nothing is marked complete by ticking a box.
| Project | Workbench, a local client website workbench |
|---|---|
| Type | Independent product development |
| Role | Product design, architecture and development. Everything on this page and in the tool. |
| Problem | A website build is thirty decisions made over two months by four people, and the record of them is a spreadsheet, a chat thread and somebody's memory. By launch nobody can say whether the thing agreed at kickoff was ever built. |
| Approach | One stage per real piece of work, each reading what the stages before it decided. Status is derived from the data rather than declared, and every stage ends in a document rather than a tick. |
| Stack | Node and Express, SQLite, React with Vite, no build tooling beyond that. The Claude API for optional assistance, through your own key. |
| Scope | Requirements, research, sitemap, content, wireframes, design, build, responsive, CMS, SEO, analytics, performance, QA, review, infrastructure, launch and the growth loop afterwards. |
| Scale | 19 stages, 6 phases, 4 platforms, and a wireframe builder with 19 section types and 35 element kinds. |
In the order the work actually happens. Each stage reads the ones before it, so a decision made in week one is still load-bearing in week nine.
Requirement gathering, competitor research, sitemap creation, content planning. The KPIs agreed here are what stage 18 reports against, nineteen stages later.
01 — 04Wireframing and UI design. A free-positioning canvas with per-breakpoint overrides and linked sections, then real colour and type applied over the same blocks.
05 — 06Website development, responsive development, CMS integration. Page, component and integration trackers, all drawn from the sitemap and the wireframe.
07 — 09SEO, analytics, performance and QA. Configured versus verified, event recommendations read off the wireframe, and a benchmark table that colours itself.
10 — 13Stakeholder review, domain and hosting, pre-launch testing, deployment. The launch decision reads six gates live from the stages that own them.
14 — 17Post-launch monitoring and continuous optimisation. The only stages that never finish — one observes, the other acts, and the loop feeds back into the build.
18 — 19One path through the tool, with each stage reading what the one before it decided.
Objectives, audience, offerings and the KPIs that will judge the site. The KPI table is strict here on purpose — it is the thing stage 18 answers against, and a target agreed at kickoff in the client's own words is a real commitment.
Every page gets a path, a purpose, a primary keyword and a CMS flag. Those four fields go on to populate the content plan, the wireframe page list, the build tracker, the metadata table and, a year later, the ranking table.
Sections on a canvas with free positioning, pin constraints and per-breakpoint overrides. Stage 06 applies real colour and type to the same blocks, checks contrast against every background a colour actually sits on, and exports working HTML.
Framer, Webflow, WordPress or custom. Thirteen stages read that choice: the task lists, the CMS vocabulary, the deployment steps, whether hosting is managed or yours to provision. Switching platforms loses nothing, because ticks are kept per platform.
SEO carries two ticks per page. Configured means you entered it; verified means you opened the published source and saw it. Only verification counts toward the stage, because the gap between the two is where SEO quietly fails.
QA, stakeholder sign-off, mandatory revisions, infrastructure, SEO verification and performance — read live from the stages that own them. A red gate cannot be cleared from the launch page. There is no override, because an override would be used.
Every status is computed from what you actually recorded. Nothing can be marked done without the work behind it existing somewhere in the data.
Nineteen section types and thirty-five element kinds, with free positioning, snapping, pin constraints, auto-layout stacks and overrides per breakpoint. Save a section and every instance of it follows.
Three widths, one sourcePalette, type scale and spacing land on the wireframe rather than beside it. Contrast is real WCAG arithmetic against every background a colour is actually placed on, and a failure is not softened.
Exports working HTMLGeneric tasks are translated into the platform's own words, with a table showing the mapping. Thirteen stages change with the choice, and your own added tasks survive a switch.
Ticks kept per platformA form produces form_start and generate_lead. A section with no button, form or decision point says plainly that it needs no event, because forty events nobody reads is the common failure.
Rules, not a modelLoops and chains are invisible from a single row, so the whole table is walked. A chain built by two people on different days looks correct twice over.
Caught, not listedThe value column is deliberately left empty. A guessed A record will be accepted because it looks right, and a wrong one produces a site that resolves to nothing with no error anywhere.
Honest about not knowingA two-proportion z-test on your experiment numbers, with sample adequacy checked before significance. Eight conversions against three can clear 95% while telling you nothing, so it refuses to call it.
Four verdicts, no eyeballingQA, stakeholder review and optimisation all separate the work being finished from someone confirming it. Only the second clears a gate, because the alternative is the same feedback arriving twice.
In three stagesEvery stage ends with checks computed from its own data, each saying why it matters rather than only that it failed. A warning is surfaced and left alone; only genuine errors fail.
Nothing ticked by handNineteen documents assembled from what you recorded, previewable in place, copyable as Markdown and printable to PDF. Several also export CSV for the spreadsheet somebody will inevitably ask for.
19 documents, 6 CSVsSixty steps of history, including the cross-stage writes where a design change edits the wireframe underneath it. One keystroke, one undo, both ends restored.
Ctrl+Z across the toolA model can suggest changes to a page's sections and copy, through your own key. It never produces a status, a finding or a check, and every suggestion is one undo away from gone.
Suggests, never decidesEach closed a door deliberately. The costs are as interesting as the benefits.
The problems that took longest, and what each one turned out to be.
A design override in stage 06 writes to a block owned by stage 05. Snapshots were being read inside a React state updater, which meant the history pointer had already moved and undo restored the state you were trying to leave. Capturing synchronously before the updater fixed it.
Overrides per breakpoint, constraints resolved at the preview width, and stacks laid out before constraints apply. The comparison view then had to scroll each column rather than the page, which needed a grid that can shrink below its content.
Checking adequacy before significance is the whole value. With small numbers the maths produces confident nonsense, and the honest verdict on a site with a few hundred visitors a month is usually that it cannot be called.
Generating a plausible A record, a title, or a test case would all have been easy and all would have been accepted because they look right. Every one of those is a place where being unhelpful is correct.
Not a criticism of the trackers, which do several things this cannot. A different trade: you give up the integrations and the team features, and keep a record that understands what a website build actually involves.
| A project tracker | Workbench | |
|---|---|---|
| Where the project data lives | Their server | Your machine |
| Knows what a website build involves | ✗ | ✓ |
| Each stage reads the ones before it | ✗ | ✓ |
| Status derived rather than declared | ✗ | ✓ |
| Produces client deliverables | ✗ | ✓ |
| Wireframing and design built in | ✗ | ✓ |
| Changes with your build platform | ✗ | ✓ |
| Multiple people editing at once | ✓ | ✗ |
| Notifications and assignment | ✓ | ✗ |
| Time tracking and invoicing | ✓ | ✗ |
| Mobile apps | ✓ | ✗ |
| Seats, tiers and account limits | Yes | None |
A tracker is the better answer if several people need to work in it at once, or if the same tool has to handle invoicing. This is the better answer if you want the build itself understood, and the record to still be true at launch.
No. It runs the process around the build and produces the documents, and the wireframe and design stages export working HTML you can take into your platform. The site itself is built in Framer, Webflow, WordPress or your own code.
Because a percentage gets rounded up to "basically done" and a completion toggle gets ticked by whoever wants to move on. Each stage derives its status from its own data, and tells you the specific things outstanding instead.
Node 18 or newer. SQLite comes with it, there is no database to set up and no account to open. Install once in each folder, run two commands, and open the page it gives you.
Not yet. Numbers are entered by hand in the performance and monitoring stages. A read-only fetch would fill a real share of four stages and is the clearest next piece of work; it is deliberately not a write integration.
No. Stakeholders do not log in — somebody on the team records their feedback into the review stage. That is a real limitation, and building a review portal would change what this is.
In two places, both optional and both through your own key: suggesting changes to a page's sections in the wireframe and design stages. It never produces a status, a check or a finding, and every suggestion is a single undo away from gone.
One person at a time. There is no concurrent editing, no assignment and no notifications. It is a workbench, not a workspace.
Unzip it, install once in each folder, run two commands, and open the page it gives you. One client per workbench, all of it on your own disk.