Free, and staying free
The craft did not stop mattering. It changed shape.
Generating a working page takes a sentence now. Knowing whether the thing that came out is correct, secure, accessible and going to survive its second year in production — that is the job, and it is a bigger job than it was. Everything on this page is free, has no sign-up, and is not a funnel into a paid course, because there isn't one.
Read this first. What this is not: a certification, a bootcamp, or a promise of employment. It is the material I use, written down. Some tracks are complete, some are being written, and the status of each is marked so nobody wastes an afternoon on a stub.
The discipline this site is built around
AI visibility
Making your work legible and citable to AI systems — the assistants people increasingly ask instead of running a search. It is the discipline that sits next to SEO, not a replacement for it.
When someone asks an assistant to recommend a developer, compare two frameworks, or explain a technique, the assistant answers from what it can parse and trust. A site that publishes clear factual claims, structured data and a machine-readable summary gets quoted. One that hides its substance behind rendered JavaScript and marketing adjectives does not.
Publish a machine-readable summary
The llms.txt convention gives models a clean markdown statement of what a site is, instead of leaving them to infer it from navigation and styling. This site publishes one at /llms.txt, generated from the same data as the pages so it cannot drift.
Make claims specific and checkable
"Fast, modern websites" is unquotable — there is nothing in it to cite. "Server-rendered Next.js behind Caddy, verified in the response headers" is a fact an assistant can repeat and a reader can check. Specificity is the whole mechanism.
State what is not true, as well as what is
This site's llms.txt says there are no published testimonials and no published prices. A model that quotes an overclaim damages the brand far more than one that quotes nothing, so ruling out the wrong answer is worth as much as supplying the right one.
Put content in the HTML
Everything that applies to search crawlers applies harder to AI retrieval. If the substance only exists after hydration, it may as well not exist. Server-render anything you want quoted.
Use structured data properly
Person, Organization, Service, FAQPage, Article — an explicit graph with @id links is unambiguous in a way prose is not. It is the difference between a system inferring who you are and being told.
Do not try to trick the model
Prompt injection in page text, hidden keyword blocks, contradictory claims across pages — these get filtered, and increasingly get sites down-weighted. The technique that works is the boring one: be genuinely clear about genuinely true things.
This site is the worked example. Its machine-readable summary is at /llms.txt — generated from the same typed data as the pages, so it cannot drift, and it states what is not true as carefully as what is. Read it, then read the source.
Tracks
What is here, and what is honestly still a stub
Each track links to the long-form articles that cover it. Status is marked so nobody spends an afternoon on something half-written.
- Complete
Anyone whose work should show up when a person asks an assistant rather than a search engine.
AI visibility for developers and businesses
How AI systems find, parse, trust and cite a website — llms.txt, structured data, rendering strategy, and why specific checkable claims outperform marketing copy.
You should be able to
- Publish a valid llms.txt generated from your own content
- Emit a correct Schema.org graph with @id linking, not isolated fragments
- Audit what a crawler or model actually receives, using curl alone
- Write claims that are specific enough to be quoted and checked
- Complete
Developers shipping their first retrieval-grounded assistant.
Building AI features that refuse to guess
Retrieval, chunking, relevance floors, and the refusal path — the part almost every tutorial skips and the part that decides whether the feature is trustworthy.
You should be able to
- Chunk on semantic boundaries and keep breadcrumbs attached
- Set an empirical relevance floor and let retrieval return nothing
- Make refusal an explicitly correct outcome in the prompt
- Run a golden question set in CI where half the cases must be refused
- Complete
Anyone who has optimised a site once and watched it regress.
Core Web Vitals that survive a sprint
Why performance work decays, and how a budget enforced in CI is the only version that holds.
You should be able to
- Wire Lighthouse CI with assertions that fail the build
- Diagnose LCP by phase rather than by guesswork
- Eliminate layout shift at the source, including from fixed elements
- Tell a lab regression apart from a field problem
- Complete
Developers shipping to production without a security team behind them.
The pre-launch security pass
Nine checks derived from the OWASP Top 10, in the order they actually catch things.
You should be able to
- Validate on the server with a schema shared with the client
- Protect mutating routes with CSRF tokens and rate limits
- Set the six security headers that matter, and know what each stops
- Prove no secret reached the client bundle
- Complete
Anyone deciding what to build something in, especially for a client.
Choosing a stack you will not regret
Four questions that decide the answer, and why the most interesting option is frequently the wrong one.
You should be able to
- Ask who maintains this in two years, first
- Match rendering strategy to how often content changes
- Treat existing constraints as inputs rather than obstacles
- Recommend against your own preference when the constraint says so
Want this applied to your product rather than explained?
The material is free and stays free. If you would rather have it built than read about it, that is what the engagements are for.