Course

AI Engineering for Web Studios: Build Your Own Tools

A skill, an MCP server, a monitoring agent, an eval harness and guardrails you wrote.

Seriously hardWeb design

0/1010 stops · about 3 hours · final quiz · certificate

Start course Sign in to save progress

Start with

• AI at Work: FoundationsStart from zero and finish with three things you can actually use.
• AI for Web DesignersDiscovery to launch: the freelancer's site build, with Claude in every step.
• AI for Web Studios: Claude Code, Automation and RetainersTwenty client sites, three people: the build pipeline and the retainer machine.

Who this is for

Studio owners and developers who want to build the tools their studio runs on, with tests and guardrails. Every example follows Dany, who runs a web studio with one developer, Mo, and twenty-five retainer clients, and is moving the client list out of a spreadsheet into a database the studio's own tools read.

You will be able to

• Write a Claude Code skill that encodes the studio's standards and prove it changes output
• Build a read-only MCP server over the studio's client and site inventory and connect it
• Ship a nightly site-monitoring agent that checks, diagnoses and files findings without touching a site
• Build an evaluation harness with a thirty-case test set and a scoring rubric, and run it on every change
• Add a guardrail layer to any tool that writes: allowlists, dry run, approval, log
• Track cost and usage per client and per tool, and decide what stays

Stops

1. 1 Secrets, sandboxes and the write ruleOne private repository for the studio's tools, keys that live outside it, three sandboxes, and the one sentence that governs every tool in the other nine stops. Set once
2. 2 A skill for Claude CodeThe studio's front-end standards written as a SKILL.md, installed where Claude Code finds it, and a checker that proves the same brief comes out different with the skill on. Weekly
3. 3 The inventory in SQLiteTwenty-five clients out of a spreadsheet into five tables, a numbered migration you read line by line before it runs, and a test that builds the database from nothing. Weekly
4. 4 A read-only MCP serverFour tools over the studio inventory, a database handle opened read-only, a row cap, and a test client you drive by hand before Claude ever sees it. Weekly
5. 5 The monitoring agentForty sites checked every night as an anonymous visitor, a diff sent to Claude for diagnosis, findings written to the studio database, and the list of things the agent may never do. Weekly
6. 6 Findings to ticketsThe one write the studio's tools are allowed: a ticket on the studio board, behind an allowlist, a dry run by default, an approval step and an append-only log. Daily
7. 7 The evaluation harnessThirty frozen cases with expected answers written from rows, a runner that scores them on three axes, and a gate that stops a change merging when the score drops. Weekly
8. 8 Guardrails as codeOne forty-line module every writing tool calls: allowlist, target check, append-only log, dry run by default and approval for the actions that need it, with six tests on the guardrails themselves. Weekly
9. 9 Cost and usage ledgerOne wrapper that records tokens per tool and per client, a dated rates file the studio types by hand, a weekly report with the denominator that matters, and the question that kills a tool. Weekly
10. 10 Dany's capstoneThree schedules that run the studio's tools without anyone watching, then the graded capstone: one tool you built, with tests, guardrails, an evaluation score and a cost line, out of a hundred. Weekly

Final quiz