Value before spectacle
Begin with a visitor problem; add the weird, beautiful details when they make something clearer.
FIELD GUIDE 001 / PUBLIC WORKSHOP / 24 OCT 2026
MAKE IT.
BREAK IT.
VERIFY IT.
An independent creator’s guide to building websites with AI without mistaking a convincing answer for a working product.
Fourteen practical lessons. A six-stage release simulation. Tiny experiments you can actually run. No account, no tracking, no secret magic.
14 illustrated lessons6 release decisions0 external JS libraries
WORKBENCH / 01
01<!-- the brief -->
02<main>
03<h1>Build something useful</h1>
04<button>Test it</button>
05</main>
06// evidence > enthusiasm
✦ IDEA⌘ BUILD◈ AUDIT
NOT A
MAGIC
BUTTONIt only ships if it works.
MAGIC
BUTTONIt only ships if it works.
01 / THE FIELD GUIDE
An idea is not a deployed site.
The exciting moment is when a machine generates code. The meaningful moment is when an actual visitor can use it.
“The model says done. Your browser gets the deciding vote.”
AI changes the economics of making a prototype. It does not abolish responsibility for accuracy, accessibility, security, or usefulness. Faster drafts can make more experiments possible; they can also multiply undetected errors.
This is a field guide rather than a claim of laboratory validation. Its exercises are teachable design and software practices, not proof that any one creative workflow consistently outperforms another.
Skip straight to the playable labEvidence before confidence
Verify outside claims at the original source. An AI-generated footnote is a clue, not a citation.
Tests before shipping
Run the site, break its assumptions, record what passed, and preserve a way back.
KNOW WHAT YOU ARE READING
DOCUMENTED Linked to original guidance
INTERPRETATION Reasoned editorial position
HYPOTHESIS Needs empirical testing
FICTION Deliberate invented scenario
02 / THE METHOD
A release is a sequence of decisions.
One useful loop, not one miraculous prompt.
- 01DEFINEWho benefits?
- 02SPECIFYWhat counts as done?
- 03BUILDDoes it run?
- 04CRITIQUEWhat could fail?
- 05TESTWhat actually works?
- 06RELEASECan we recover?
Two approaches can both be reasonable: AI-assisted static-first sites favour low maintenance and auditability. Hand-authored sites or a framework can be preferable for deeper control, repeated interfaces, user accounts, or complex state. Choose technology to fit the problem—not to win an argument.
03 / YOUR CURRICULUM
Fourteen lessons. No shortcuts disguised as expertise.
Read in order or enter where your work is currently stuck. Each chapter includes a test, a practical exercise, and a contrasting view.
WORKSHOP INDEX
The curriculum is visible even if JavaScript is disabled. Every chapter has a permanent anchor.
0 of 14 exercises attempted this session
01Briefing
Define the problem, not the page
The failure mode is to begin with a colour palette before knowing whose problem is being solved. A homepage for everyone is usually a homepage for no one. Write down a concrete visitor, the situation they arrive in, what they need to understand, and one useful action they should be able to take. An independent creator might want an impressive constellation of microsites; the visitor may simply need a clear explanation. Both goals can coexist, but the visitor gets first place.
An audience is not a demographic label alone. “A curious first-time visitor on a phone who wants to learn how to publish a safe website” is more actionable than “students and entrepreneurs.” Separate the user problem from a business goal: clarity is a user outcome; inquiries are a possible organisational outcome.
✓ ACCEPTANCE TEST
A stranger can finish this sentence: “This page helps ___ do ___ without ___.”
↳ EXERCISE
Write a one-sentence promise, a realistic audience situation, and one task that can be completed in five minutes.
Prompts & the counterargument
Prompt to adapt. Try: “I am building for [visitor] who needs [outcome]. Critique what remains vague. Ask for no personal data.”
The other side. A site that is striking but opaque may earn attention without helping anyone. A boring but useful page may be the better prototype.
02Planning
Prompt as a specification
A useful prompt is neither a magic incantation nor a character-count competition. It is a testable specification. Describe the desired outcome, the environment, constraints, files to produce, things not to invent, and the criteria for accepting the result. Give the model permission to report uncertainty. Requesting “10/10 everything” without an observable standard tends to produce confident prose rather than evidence.
Keep facts and tastes separate: “No backend, only HTML/CSS/JS” is a technical constraint; “playful but readable” is a design direction. Demand a files manifest, explicit assumptions, and a record of what was actually tested. Ask for the smallest working version before adding animation.
✓ ACCEPTANCE TEST
A human can judge the output against a written acceptance criterion without trusting the model’s self-assessment.
↳ EXERCISE
Write a prompt that names exact files, three viewport sizes, two keyboard journeys, and one security failure to avoid.
Prompts & the counterargument
Prompt to adapt. Try: “Return code and a verification table. If you cannot execute a test, mark it untested, not passed.”
The other side. More detailed prompts can constrain useful surprises. State goals firmly but leave room for alternative designs.
03Structure
Design the information architecture
Information architecture is the art of making choices findable. Organise the page by visitor questions: What is this? Why should I care? How does it work? What can I try? Where can I verify the claims? A visitor who lands from a search result should not have to learn the author’s private vocabulary to navigate. Give every section a descriptive heading and an addressable anchor.
A sprawling project directory can be a legitimate creative form, yet discovery costs rise as destinations accumulate. Provide a start-here path, a complete index, and meaningful labels; do not force a search box to compensate for an unlabeled maze. A related-work map should explain relationships, not inflate authority by linking everything to everything.
✓ ACCEPTANCE TEST
Every major section can be reached by a normal link and makes sense with JavaScript disabled.
↳ EXERCISE
Sketch five page sections on paper. Hand the labels to someone unfamiliar with the project and ask what they expect to find.
Prompts & the counterargument
Prompt to adapt. Try: “Group these 12 topics by the questions a newcomer would ask. Justify every group name in plain language.”
The other side. Artistic ambiguity can be valuable inside the experience; it is expensive in the navigation.
04Foundation
Build meaning with semantic HTML
HTML is already an interface language. A real button communicates intent, supports keyboard interaction, and exposes a name to assistive technology. An anchor points to a destination. A label gives an input meaning. Start with headings, landmarks, forms and content that work before JavaScript arrives. CSS should decorate meaning, not manufacture it.
Use one primary h1, ordered section headings, descriptive link text, and explicit labels. Do not make a div impersonate a button unless absolutely necessary. Screen-reader friendly design is not simply adding aria-label everywhere; native elements often have the strongest built-in behaviour.
✓ ACCEPTANCE TEST
Tab through the page; links and controls can be understood and operated without a mouse.
↳ EXERCISE
Replace a clickable div with a button. Test Tab, Enter and Space; inspect focus appearance.
Prompts & the counterargument
Prompt to adapt. Try: “Audit this HTML for correct element choice, heading order, labels and keyboard operation. Quote exact selectors.”
The other side. Semantics do not guarantee usability; names and journeys still require human testing.
05Visual language
Create a CSS system, not a pile of patches
Define a small set of design tokens for surfaces, ink, accent, spacing, radius and type scales. Let responsive layout follow the content instead of assuming one device. Fluid typography, CSS grid, flexible measures and carefully chosen breakpoints help pages survive beyond your own monitor. Decorative code art is worthwhile when it supports hierarchy, not when it blocks the reading path.
At 360 pixels, menus must remain reachable and code must scroll within its own container. At 768, two columns may work for short cards but not for long instructions. At 1440, limit line length; a twenty-word sentence should not stretch across the screen. Test zoom and system reduced-motion preferences.
✓ ACCEPTANCE TEST
No horizontal page overflow at 360px, 768px, or 1440px; long code scrolls inside its block.
↳ EXERCISE
Set a max-width for paragraphs, then zoom the browser to 200% and check all controls.
Prompts & the counterargument
Prompt to adapt. Try: “Give me the smallest token system that preserves #081725, #E8FAF7 and #56E5C5, with contrast reasoning.”
The other side. Design consistency is not visual sameness; a deliberate exception can highlight an important concept.
06Interaction
Add JavaScript only where behaviour is needed
Start with a page that reads well without scripts. Then add behaviours that change something real: a preview, an export, a simulation, a check. A button that only flashes “success” is not useful. Write state transitions explicitly: what happens initially, with empty input, with invalid input, after success, and after reset? Deterministic, small behaviours are easier to audit than a large opaque animation engine.
Use addEventListener and safe DOM properties such as textContent for user-supplied strings. Avoid turning input into executable code. Reconcile what the interface claims with what it does: an export must produce an actual file; “send feedback” should open a mail composer if there is no server.
✓ ACCEPTANCE TEST
All interactive controls have a visible outcome, clear empty states and a repeatable reset path.
↳ EXERCISE
Make a button update an aria-live result. Test empty input, long input and repeated clicks.
Prompts & the counterargument
Prompt to adapt. Try: “List every state and transition in this form. Write a minimal test for each; do not skip error cases.”
The other side. A no-JS page is often excellent. Interactivity is not a moral requirement.
07Inclusion
Make accessibility part of the design
Accessibility is a design constraint and a method of seeing what your interface assumes. Keyboard access, visible focus, readable contrast, logical headings and clear status messages help more people than one imagined “average” user. WCAG 2.2 supplies testable criteria, but meeting a checklist is not a substitute for usability with people who use assistive technology.
Use actual labels and legends; do not rely on colour as the only cue. Respect prefers-reduced-motion. Keep animated decoration out of the reading order. Test content reflow and focus at 200% zoom. An iframe preview should have a title. The controls here deliberately remain visible with CSS animations disabled.
✓ ACCEPTANCE TEST
Complete one task with the keyboard alone and understand the status message without seeing a colour change.
↳ EXERCISE
Turn off the mouse: traverse navigation, submit a form and reset the workflow.
Prompts & the counterargument
Prompt to adapt. Try: “Identify violations against specific WCAG 2.2 success criteria. Separate probable issues from confirmed issues.”
The other side. Passing an automated accessibility scanner can catch only a subset of real barriers.
08Editorial integrity
Track content provenance and uncertainty
The most dangerous citation is one that looks plausible but was never checked. Treat an AI-produced URL, quotation, statistic or attribution as an unverified lead. Ask where a claim comes from, inspect the original source, and distinguish observation from interpretation. A creator can describe their own project as an experiment without claiming that its model was scientifically validated.
This workshop uses four labels: documented fact, interpretation, hypothesis and fiction. Documented facts deserve source links; interpretations need reasoning; hypotheses need tests; fiction needs an unmistakable frame. When no source can be inspected, omit the claim or label it uncertain instead of laundering a guess into a footnote.
✓ ACCEPTANCE TEST
Every factual technical statement can be traced to a live, relevant original source or marked for verification.
↳ EXERCISE
Take three claims from a draft. Find their first-party documentation. Remove one unsupported flourish.
Prompts & the counterargument
Prompt to adapt. Try: “Mark each sentence F=verified fact, I=interpretation, H=hypothesis or X=fiction; flag every unsourced F.”
The other side. Personal experience can motivate a question. It rarely establishes a universal causal claim.
09Safety
Think like a security reviewer
Static websites remove many server-side risks, not all risks. A malicious script can still be introduced through unsafe DOM methods, dependencies, browser storage, third-party widgets or careless preview code. Prefer no dependencies, no secrets in source, and no personal data collection by default. If you offer a live HTML preview, sandbox it, restrict external fetches and explain its limits.
Use textContent to display user input, not innerHTML. Restrict script and network sources with Content Security Policy where practical. Never store private API tokens in downloadable JavaScript. Security headers reduce exposure but are not proof of safety. A sandboxed srcdoc document deserves special caution: test that scripts cannot run and that it cannot access the parent.
✓ ACCEPTANCE TEST
Pasted markup cannot execute scripts in the preview or access the parent page; no hidden network requests are introduced.
↳ EXERCISE
Paste a script tag into the preview. It should not execute. Inspect the Console and Network panel for violations.
Prompts & the counterargument
Prompt to adapt. Try: “Threat-model this static page: inputs, sinks, network egress, dependencies and browser storage. Propose proportionate fixes.”
The other side. A strict CSP can break legitimate features; verify the policy against the actual page.
10Discovery
Build honest search foundations
SEO is not a switch marked “rank first.” Search-ready foundations begin with useful, crawlable content, descriptive titles and headings, a canonical URL when appropriate, and links that accurately describe destinations. An XML sitemap is an invitation to crawl, not a promise of indexing. A single deeply useful lesson can be more durable than a hundred near-identical keyword pages.
Avoid keyword stuffing and repeated templated filler. Give the homepage a specific promise, meaningful metadata and content that is readable without rendering scripts. Distinguish the source website from preview aliases. The workshop includes a canonical URL and a sitemap, but actual indexing depends on crawlers, DNS and site quality after deployment.
✓ ACCEPTANCE TEST
The visible title, description, canonical link, sitemap and page content describe the same page accurately.
↳ EXERCISE
Open View Source and verify metadata; submit the live sitemap only after the custom domain resolves.
Prompts & the counterargument
Prompt to adapt. Try: “Critique this page for search intent, thin content, unsupported claims and navigation—not magic ranking scores.”
The other side. High-quality SEO often produces less content, not more.
11Review
Use multiple models as critics, not juries
A second AI opinion can surface missed failure modes: poor labels, brittle layouts, code smells or suspicious claims. It can also introduce new mistakes. Independence of critique matters more than whether a particular model wrote the first draft. Ask a second model to cite exact lines and produce reproducible counterexamples instead of granting a quality score by intuition.
Give both reviewers the same acceptance contract, but different roles: one examines semantics and interactions, the other searches for security and evidence problems. Reconcile their findings by running tests. Where models disagree, neither vote count nor confidence is enough; build a minimal demonstration and inspect it yourself.
✓ ACCEPTANCE TEST
A proposed fix is accompanied by a before/after test and does not break an already working journey.
↳ EXERCISE
Ask one model for a two-minute keyboard audit and another for a malicious-input audit. Test both suggestions.
Prompts & the counterargument
Prompt to adapt. Try: “Be an adversarial reviewer. Return file path, selector, expected, actual, severity and a reproducible test.”
The other side. Agreement between models is not independent empirical validation; common training patterns can yield common errors.
12Verification
Test reality, not self-confidence
“Production-ready” is a conclusion supported by observed behaviour. At minimum, check that every file exists, relative paths resolve, JavaScript parses, forms validate, code downloads, links point somewhere meaningful, layout survives small screens, and the Console has no unexpected errors. Automate what is cheap, then test the things machines routinely miss: clarity, hesitation, focus and perception.
Keep a verification ledger with three columns: tested and passed, inspected but not fully tested, and not yet tested. Distinguish an HTTP 200 from an interaction that works. Preview aliases and public domains can diverge. A page that opens on your laptop has not been tested under mobile touch and real-network conditions.
✓ ACCEPTANCE TEST
A tester can reproduce the stated result using documented steps and identify the untested areas.
↳ EXERCISE
Perform a cold reload, tab through a full journey, trigger validation, export a file and inspect console errors.
Prompts & the counterargument
Prompt to adapt. Try: “Write a smoke-test matrix at 360/768/1440 pixels for keyboard, touch, empty states, links and performance.”
The other side. One excellent smoke test does not replace full browser or accessibility testing.
13Release
Deploy with a rollback path
Separate local work from public deployment. Make a ZIP whose root contains the actual site files, upload it to a staging Pages project or preview deployment, and check the deployed URL before attaching a public domain. Preserve the previous known-good ZIP. Cloudflare Pages supports preview deployments and production rollbacks, but a preview deployment is not the same thing as a production version eligible for rollback.
After staging passes, connect the desired custom domain and verify DNS, TLS, the canonical URL, headers and sitemap. Never replace a working homepage solely because an AI said “this is finished.” If you use Direct Upload, learn its Git integration limitations before choosing that project type.
✓ ACCEPTANCE TEST
A staging link can be inspected independently; the production version and rollback method are documented.
↳ EXERCISE
Deploy to a non-production Pages environment, record the deployment ID, inspect response headers and confirm the 404 behaviour.
Prompts & the counterargument
Prompt to adapt. Try: “Write a release checklist with rollback conditions. Treat any untested critical user journey as a blocker.”
The other side. Rollback restores site files; it will not reverse unrelated DNS or third-party configuration changes.
14Stewardship
Maintain the thing you shipped
A website is a publication with software-shaped responsibilities. Links rot, browsers change, user needs evolve and once-correct statements become stale. Schedule periodic review of external sources, broken destinations, keyboard interactions and performance. Keep source notes so a future editor knows what is first-hand, interpreted or provisional. A small, maintained resource often serves visitors better than a vast archive of abandoned experiments.
When adding another feature, ask whether it improves a visitor outcome or merely demonstrates technical possibility. Maintain a changelog; use descriptive version names; preserve tested backups. Invite corrections without pretending they have been implemented. This is the point where authorship becomes custodianship rather than launch theatre.
✓ ACCEPTANCE TEST
Another creator can understand, update and redeploy the site without asking what each button secretly does.
↳ EXERCISE
Write a maintenance note: what to recheck monthly, what would trigger an urgent fix, and how to roll back.
Prompts & the counterargument
Prompt to adapt. Try: “Audit this site as if the author disappeared for six months: what is brittle, unclear, costly or unsupported?”
The other side. Not every project needs indefinite maintenance. An intentionally archived experiment should say so.
04 / THE INTERACTIVE LAB
Open the workshop bench.
Everything below runs in your browser. Inputs are not transmitted to our servers; the plan export downloads a file to your device.
EXPERIMENT 01 / RELEASE SIMULATOR
Six decisions between an idea and a working site.
Select the strongest next action. A bad choice does not fail your character; it exposes a risk worth understanding.
- 01 Define
- 02 Specify
- 03 Prototype
- 04 Audit
- 05 Fix
- 06 Ship
A teaching scenario, not a model of real software risk.
STAGE 01 / 06
Loading the first decision…
Choose an answer to inspect its consequences.
EXPERIMENT 02 / BUG HUNT
Which detail breaks the promise?
Four deliberately broken fragments, drawn from common development mistakes. Choose the primary bug, check, and read the reasoning.
FOUND0 / 4
The button that goes nowhere
<a href="#">Start learning</a>The invisible keyboard action
<div onclick="save()">Save</div>The risky greeting
result.innerHTML = visitorInput;The copy-pasted identity
<link rel="canonical" href="https://other.example/">Score counts cases correctly solved, not attempts.
EXPERIMENT 03 / SAFE(ER) STATIC PREVIEW
Change the HTML. See the result.
Edit a tiny document and render a restricted subset of HTML and inline CSS. Scripts, forms, embedded media, external links and unsafe attributes are removed; this is not an online code execution service.
The sample is static; controls inside have no scripted behaviour.
Security boundary: The preview allows only selected HTML elements, removes active content, uses an iframe with no sandbox permissions, and adds a restrictive CSP. Browser isolation is complex: never paste secrets or rely on this tool as a full security scanner.
EXPERIMENT 04 / PROJECT PLAN EXPORT
Turn a vague wish into a testable brief.
Fill only what you want to keep; nothing is uploaded. Export produces an actual Markdown file. Prefer a non-sensitive example.
EXPERIMENT 05 / COPY, ADAPT, QUESTION
Three prompts worth keeping in your toolbox.
Templates are starting points, not a replacement for understanding the output.
01 / The build contract
Build a static, accessible website for [visitor] who needs [outcome]. Use semantic HTML, one CSS file and vanilla JS. Supply complete files, exact file paths, source notes, working error states and a testing checklist. Do not invent facts, citations, deployment status or test results. Mark uncertainty explicitly.
02 / The adversarial code review
Inspect this site as a skeptical reviewer. Look for broken paths, unsafe DOM sinks, keyboard traps, focus loss, contrast problems, missing labels, fabricated sources, incorrect metadata and CSP incompatibilities. Report a reproducible test and a minimal fix for each issue. Distinguish verified failures from suspicions.
03 / The release checklist
Create a go/no-go release table for Cloudflare Pages: local files, preview build, Console, Network, keyboard, 360/768/1440 responsive checks, 404, canonical, sitemap, headers, DNS, TLS, backups and rollback. Only mark a check as passed when supplied with observed evidence. Output blockers separately.
Copy uses browser clipboard access when available.
05 / LIVE CONTEXT, LIMITED CLAIMS
Four windows into the Sahilverse experiment.
These pages were publicly accessible when checked on 24 October 2026. Their appearance is not evidence that every feature has passed an independent audit.
Sahilverse main atlas ↗
A sprawling directory of questions, modes and experimental worlds. A useful case for asking whether an expressive visual system can still provide an obvious first step.
Audit question: Can a stranger find one relevant project without learning the creator's vocabulary?
ADHD Tools Lab ↗
A public concept page that clearly labels an AI life-RPG idea as exploratory rather than a launched or validated intervention.
Audit question: Can visitors tell what exists today, what is proposed, and what evidence is missing?
The Hearsay Department ↗
A fictional reporting scenario about observation, narrative and institutional response. It illustrates how a speculative interaction can be clearly presented as fiction.
Audit question: Does the fictional frame prevent users from mistaking the simulation for empirical research?
Sahil Tayal Studio ↗
A web-design service page that makes an offer to visitors. Its stakes differ from an art experiment: contact paths and service promises need to be especially clear.
Audit question: Can someone understand the work offered and contact the maker without friction?
Method note: “publicly accessible” above means content could be retrieved, not that accessibility, security, performance or code authorship was independently verified. These are editorial case studies, not endorsements or audited certifications.
06 / THE EVIDENCE SHELF
Verify the source, not the vibe.
Original references and official manuals that inform these lessons. All were checked for existence; none is claimed to validate this workshop as an intervention.
Original documentation
- W3C — WCAG 2.2Accessibility success criteria and conformance.
- MDN — iframe elementSandboxing and embedded content behaviour.
- MDN — srcdoc security considerationsWhy unrestricted previews can be dangerous.
- OWASP — DOM XSS PreventionSafer DOM updates and untrusted strings.
- Google — SEO Starter GuideFoundations without guaranteed rankings.
- Cloudflare — Direct UploadStatic deployment methods and caveats.
- Cloudflare — custom headersRules for the root-level _headers file.
- Cloudflare — rollbacksRestore an eligible previous production deployment.
A study, not a sweeping verdict
A 2024 comparative analysis by Hamer, d'Amorim and Williams examined security vulnerabilities in a curated set of Java snippets from ChatGPT and Stack Overflow. Its relevant lesson here is narrower than “AI is unsafe” or “AI is safer”: copied code from either source requires testing and security review.
INTERPRETATION
What the sources do not establish
None of these sources proves that this specific AI-assisted workflow is the best way to learn to program, that Sahilverse sites were independently coded, or that this site has passed a formal WCAG conformance audit.
Mini glossary
- Acceptance criterion
- An observable condition that must hold before work counts as complete.
- Progressive enhancement
- Make the core page useful first; add richer behaviours on top.
- Semantic HTML
- HTML elements that describe meaning and expected interaction.
- Content provenance
- A record of where a claim, quotation or asset originated.
- Sandbox
- A restriction boundary limiting what embedded content can do.
- CSP
- Content Security Policy, a browser control limiting resource loading and script execution.
- Rollback
- Restoring a known-good earlier production deployment.
- Canonical URL
- The preferred address a site nominates for a page.
07 / ABOUT THE WORKSHOP
Built in public.
Open to correction.
This is a self-directed educational resource by Sahil Tayal, an India-based interdisciplinary writer and creator who experiments with AI-assisted publishing and web design. Sahilverse supplies the live context, but this tutorial does not assume the author personally hand-coded every referenced site or that his broader research has been externally validated.
AI can lower the cost of trying an idea. It can also lower the cost of publishing a mistake. The interesting skill is not just producing more; it is learning to tell the difference between what a machine can generate and what the world will actually support.
What we know: established web standards and official platform guidance are cited above. What we interpret: verification is a valuable creative habit. What we hypothesise: this style of teaching may help some new creators build better judgment. What is fictional: the simulator and bug cases are constructed lessons, not observations about particular individuals.
What would change in your work if “I shipped it” always meant “I can show you what I checked”?
Email opens your mail application. This website does not send messages or receive submitted data.