Most of this site runs itself, but only because every part of it has had its job clearly defined. Drag-and-drop website builders give you a templated page. AI-built websites give you a templated page assembled differently. What I tried instead was a stack of small, sharp tools that each do exactly one thing well, glued together by a few hundred lines of plain English instructions. The result is the site you are reading.

I am writing this page for three kinds of reader. The first is the AI-curious person who has heard claims about what AI can do and wants to see a real example wired up end-to-end. The second is another non-developer thinking about something similar. The third is the technically literate reader who wants to know exactly how this is plumbed. The page tries to serve all three without dumbing down for any of them.

Why this exists in the first place

The guide started as a Word document. That is where most writing begins. It was a linear front-to-back manuscript covering the AI tools I use, what they are good for, and how to start. The problem with a Word document is that it is a terrible format for content that changes every fortnight. Pricing changes. Models get retired. New tools appear and become essential in weeks. Every time something changed, I had to find the right paragraph, edit it, save a new version, and email the file. There is no link to share, no way to update it for everyone at once, and no navigation for readers who only want one part.

The obvious answer was a website. Not so obvious: that I, a non-developer, could now build and run one without learning JavaScript or paying a developer. The first version went live in about four part-time days in March 2026. It has grown by feature accretion since.

What is actually running

To make the rest of the page concrete, here is the site as it stands today.

The static pages are the bulk of it. The dynamic features are smaller in count but disproportionately interesting: a chat widget on every page, a Persona Explorer where readers compare three AI personalities answering the same question, a curated tool list that refreshes itself fortnightly, and a reader-questions pipeline that turns inbound email into draft answer pages. Plus a hidden multi-lingual training course (twenty modules, two languages) that lives at the same domain but is unlinked from the public navigation.

None of this required me to write code that I could not have written by saying it out loud. That is the core of what changed.

The cockpit: Cowork

If there is a single piece of software that made this site possible, it is Cowork. Cowork is Anthropic's desktop application for non-developers. It looks like a chat window and is, in fact, a chat window. The difference is that the chat is connected to your computer's filesystem and a sandbox shell. You describe what you want, Claude does the work, and you see the file changes happen in real time.

I use three Cowork features more than any other.

Chat mode is the everyday workspace. I describe a change ("rename the Top 100 page to AI Tools Worth Knowing, update the homepage card and the SEO meta tags"), Claude inspects the codebase, makes the edits, and shows me what changed. If I do not like it, I say so. If I do, I run a deploy command and the change ships. There is no separate IDE, no terminal-juggling, no copy-pasting between windows. The conversation IS the workspace.

Projects are persistent contexts. A Project is a folder full of files plus the rules and notes you want Claude to follow whenever you work in that context. The whole site lives in one Project. The Project's `CLAUDE.md` file holds my voice rules ("Australian English, no em dashes, no marketing words"), my deploy discipline ("paths relative to site-v4, single-line commit messages, never drag the folder into Netlify"), and the workflow for the fortnightly tool refresh. Every Cowork session in this Project starts with those rules already loaded. I do not have to remind it of the conventions every time.

Scheduled tasks are the feature that turned this from a one-person hobby project into something that runs on its own. A scheduled task is a saved instruction set with a timer attached. Cowork fires it on the schedule, the task wakes up, reads its instructions, does the work, and goes back to sleep. I have two of these running. They earn their own section below.

The mental model that helped me most: Cowork is a colleague who lives in the codebase. You can ask them anything, hand them a job, or set them a recurring duty. They are competent within the scope of what you have told them and they ask before doing anything destructive. Working with them is closer to managing than to programming.

The stack

Cowork is the cockpit. Everything else in the stack is one of the controls or one of the engines.

That is the entire stack. Six pieces. None of them are mysterious. Each one does its single job well. The skill is not in any individual piece, it is in the seams between them. When the seams are right, the system runs itself.

The two automations that earn their keep

Most pages on most websites are static. Words, images, links. The interesting question is what happens when something needs to change and you do not want to be the one updating it. There are two such cases on this site.

The reader-question pipeline

A reader emails a question through the site's "ask" link. Cloudflare forwards it to Gmail. Every hour between 6 a.m. and 10 p.m. Sydney time, a scheduled task wakes up, scans Gmail for new questions, classifies each one (legitimate, spam, off-topic, abusive, promotional, borderline), and for the legitimate ones drafts an anonymised question-and-answer page in the site's `_drafts/` folder.

It is anonymised end-to-end. The reader's name and email never appear on the public site. The processor uses a one-way SHA-256 hash of the email address to track senders for rate-limiting purposes (no one sender can dominate the queue), but it never stores the raw address. The drafted answer is written in the site's voice, grounded in existing pages where possible, and follows a short answer-shape spec (250 to 500 words for a standard question, up to 1500 for a deep dive).

I review every draft before it ships. The processor saves its drafts to a folder I open in the morning, I edit anything that needs work, move the file to the publish folder, and push. About five minutes of my time per question instead of an hour. The end-to-end experience for the reader is that they email a question and a few days later it appears as a published answer on the site, properly anonymised.

The fortnightly Top 100 chain

The Top 100 list is the part of the site most likely to go stale. AI tools change every few weeks. New ones launch. Old ones get acquired or shut down. A list written once and updated by hand falls behind quickly. So the list refreshes itself.

The Top 100 chain is a single scheduled task that does twelve category refreshes back-to-back, then schedules its own next run for fourteen days later. It works one category at a time on a ten-minute cron tick: chat assistants, then writing tools, then research, image, video, audio, code, productivity, business, learning, browsers, and specialist. For each category it surveys aggregator sites, builds a fresh consensus list, fact-checks every claim against the vendor's own documentation, writes the new descriptions in the site's voice, and stages the result without touching live data. After all twelve are staged it builds a single master review HTML for me to skim before applying.

The chain produced 108 tool entries on its first proper run, all four-part structured (the take, what people are saying, who I would recommend it for, two pluses and two negatives), and zero pricing leaked into the descriptions. None of that was supervised; the rules were in the task's instructions. That is the leverage point. A long-running task is only as good as the rules you write for it. The rules took me a day to draft and refine. They will run for years.

The most important rule, written after a single failure: the task fact-checks every claim about what a tool can or cannot do against the vendor's own capability documentation in the same run. Carryover claims from the existing data are not trusted. The cautionary tale is when an early version of the task said Claude had no real-time web search, which had not been true since May 2025. The rule now bans absence claims that cannot be verified against vendor sources within the run. That single rule is worth more than the previous month's manual content audits combined.

The rules that keep it honest

Saying "Claude does the writing" is technically true and practically meaningless. What Claude actually does is follow a set of rules I have written down and refined over months. Those rules live in three canonical files.

The first is the project's `CLAUDE.md`. This is the working contract for any Cowork session in this codebase. It defines the voice (Australian English, no em dashes, no marketing words, plain prose, opinionated, honest about limitations), the deploy discipline (single-line commit messages, paths relative to `site-v4`, never drag the folder into Netlify), and the rules of thumb for when to escalate ("if a Top 100 tool decision feels arbitrary, ask before applying"). Every session inherits this file automatically.

The second is `reference/tool-review-style-guide.md`. This is the canonical voice and structure spec for every AI-tool review on the site. It defines the four-part entry shape (the take, what people are saying, who I'd recommend it for, two pluses and two negatives), forbids dollar amounts anywhere, forbids version numbers unless they convey a functional change, and codifies the vendor-feature verification rule. The chain task reads this file at the start of every category. Any future tool-review work, whether by an agent or by me, is required to follow it.

The third is the per-task SKILL.md. Each scheduled task has its own canonical instruction set, which is what the task reads when it fires. The Top 100 chain's SKILL.md is about three thousand words. It is more important than any code I have written, because it determines what the task actually does each fortnight without my supervision.

If there is a single insight that came out of building this site, it is that the leverage in working with AI is not in the prompts you write, it is in the rules you put on the shelf so the prompts of the future can read them.

The deploy discipline matters too. Every change to the production site goes through the same path: edit on a sandbox branch, push to GitHub, Netlify auto-deploys the branch to a preview URL where I can verify, then merge to `main`. Netlify rebuilds and ships to the live site within about a minute. Sandbox is `https://sandbox--myaibook.netlify.app`. Production is `https://myaibook.net`. I can revert any commit if something looks wrong on production. I have done this exactly once.

What it costs

The honest answer is "it depends". The Anthropic API charges by tokens used, which means costs scale with how active the site is on a given day. Heavy days (the chain task running, the email processor doing real work, plus the public chat widget seeing traffic) cost more than quiet days. Here is the shape of the bill in ranges, not exact figures, because the figures shift with usage.

Item	What it is	Monthly cost (range, AUD)
Anthropic API	Chat widget, Persona Explorer, scheduled tasks	Low single digits to low double digits, depending on activity
Netlify	Hosting, deploys, serverless functions, branch previews	Free tier (the site does not approach the free tier limits)
Cloudflare Email Routing	Mail forwarding for the question form	Free
Pagefind	Site search	Free (open source, runs at build time)
GitHub	Code repository	Free (private repo on the free tier)
Domain registration	The myaibook.net domain	About a dollar per month, paid annually
Cowork	Anthropic Max plan covers Cowork plus Claude	Mid double digits monthly. The same plan I would have for personal use.
Total running cost	Everything above, on a typical month	Low double digits per month, plus the Anthropic Max subscription I would pay anyway

Two things are worth saying about that bill. First, the API cost is the only line that can spike. If the chat widget got viral attention I would notice. Cowork's cost is fixed (it is part of the Max plan). The hosting cost is free unless the site got dramatically more traffic, in which case Netlify's paid tier would still be reasonable. Second, none of this is on a startup-pricing curve. These are mature services with predictable bills. I am not waiting for a "free during beta" period to end with a surprise.

What I would do differently, and what is next

Three things, in order of how strongly I feel about them.

Write the rules earlier. The first version of the Top 100 chain was scheduled to refresh the list every fortnight, but the rules it followed were thin. The first run produced output with several factual errors (a tool that had quietly been retired was still listed; a popular tool's pricing tier was wrong) plus a strong drift toward marketing language. Each error was fixable, but each fix was also an instruction I should have written into the task at the start. The task is now noticeably more reliable than my own manual content reviews used to be, because the rules forbid the failure modes I kept making myself. If I were starting again, I would write the rules first and the automation second. The rules are the part that earns its keep.

Be louder about what readers can do, sooner. The site spent its first month being mostly informational. The interactive features (the Persona Explorer, the chat widget, the question form) came later. With hindsight I would have wired in the question form on day one, even if it just collected questions for me to answer when I had time, because reader questions turn out to be the single best source of new content ideas. The site's most-read pages are not the ones I planned, they are the ones I wrote because someone asked.

Stop trying to prevent things I should be tracking instead. An early version of the email processor tried to strictly distinguish between "real" questions and spam, with a strict per-sender rate limit. The result was that I missed a few genuine questions because the system was too suspicious. The current rules are softer: classify, log, and let me see the borderline cases rather than making the call automatically. Most of the failure modes in this stack came from trying to fully automate decisions that should have been semi-automated.

What is next is not architectural. The stack is solid. What it lacks is content depth on a few specific topics, which is the more boring but more valuable next step. I have a content backlog file (it is checked into the repo) listing the pages worth writing in priority order. The chatbot does not yet know about the Top 100 catalogue when readers ask it for tool recommendations, which is the single biggest UX upgrade waiting in the wings. And there is a Manus-related rewrite waiting across about a dozen pages, because the geopolitics around that particular tool changed dramatically while I was building the site.

None of those are scary. They are evenings of work, not weeks. The hard part of building a website like this is no longer technical. It was never technical for very long. It is knowing what you want to build, watching what your readers actually do, and writing down the rules for the next person (or the next AI) so they can carry it forward.

First version built in four part-time days starting March 2026. Continues to grow.