A 30-minute walkthrough of using Claude to design and ship in days, not months. From blank canvas to live site — and every step in between.
That's the talk. The next twenty-eight minutes are the why and the how.
Read the full talk ↓AI is going to replace designers. Or AI is going to make designers ten times more productive. Or some other twitter-thread-sized take. Most of it's wrong.
Here's what's actually true. If you know how to use it — really use it — Claude doesn't replace the work. It removes the parts of the work that were never the interesting part.
The wireframe nobody wanted to draw. The schema you procrastinated on. The fifteenth version of marketing copy. The empty-state designs you always promised to finish.
What's left, after Claude eats all of that, is the part you were always good at. Just more of it. Faster. With better tooling on the boring stuff.
In the next thirty minutes I'm going to walk you through the exact process we use at Mullin Agency for shipping work — start to finish — on two kinds of projects. A piece of functional software. And a marketing landing page. I'll show you the steps, the tools, the moments where Claude earns its rent, and the moments where Claude is the wrong answer.
At the end I'll give you three rules. If you remember nothing else from this talk — three rules. They'll get you eighty percent of the value.
Let's start.
Every project — software or marketing — passes through these stations. The order is roughly fixed. What changes is the depth at each station and which Claude surface you reach for.
Record the call. Drop the transcript into Claude Chat. Get structured intake in 90 seconds.
You're building a SaaS dashboard. An internal tool. A B2B admin panel. Anything where the deliverable is a system that has to actually work — not just a beautiful surface. This is the harder case. So I'll start here.
You're on a Zoom call with the founder. They're describing their problem. Half of what they're saying is "Salesforce won't do this thing" and the other half is "I want it to feel like Linear."
The old way: scribble notes. Write a recap. Hope you got the gist. Send the recap a week later. Wait for the founder to correct you.
The new way: record the call. Drop the transcript into Claude Chat. Ask: "What are the actual problems being described? What are the stated requirements? What's emerging from between the lines?"
You get a structured intake document in ninety seconds. The founder hasn't even left the call.
The intake document becomes the spine of the whole project. Stakeholders. Constraints. Success criteria. Vague aesthetic preferences. Competitive landscape. The "we tried this once and it failed" landmines.
Drop it in Claude Cowork. From now on, every conversation about this project starts with that context already loaded. No more rebriefing yourself every Monday.
You'll add to it as the project unfolds. Decisions get logged. Open questions get tagged. By week three the document is the project — everything else is a derivative.
Most intakes fail by being either too thin (vibes only) or too sprawling (a hundred edge cases, no priorities). A great intake is structured around four pillars. Each one has 3–4 components. If any pillar is missing, your output will be generic at exactly that pillar.
A static brief in a Notion page is fine. A brief in Claude Cowork is something else entirely — it stops being a document and becomes a working partner. Here's what changes the moment your intake is loaded.
Once the intake lives in Cowork, every downstream conversation — wireframes, schema, copy, code review — starts with full context already loaded. You never re-brief. Decisions get logged automatically. New person joins on day 14? Drop them into the conversation; they're caught up in 30 seconds. The intake stops being a document and becomes the project's living memory.
Drop your draft intake into Claude and ask: "What's missing? What questions haven't I asked the founder?" Claude finds the blindspots — at machine scale, with no ego. The "we never thought to ask" trap that kills projects in week six? Solved before you commit to a direction.
Claude challenges every claim. Surfaces the fragile assumptions before they sink the project. Makes you defend the parts you skimmed past. It's the senior partner you can't always afford — at 3am, on demand, with no fatigue.
Same intake document. Claude reformats it for any audience: an engineering spec, a board update, a sales positioning paragraph, a designer's brief, an investor one-pager. One source. Many derivatives. All in sync. No more four documents that say almost the same thing but contradict each other in week six.
Discovery surfaces references — competitor sites, the founder's LinkedIn and Substack, industry articles, the moodboard URLs, the audience's social presence. Claude crawls, parses, and synthesizes all of it in minutes. Every downstream decision sits on a research foundation no human team could assemble at this speed — and that competitive teardown that used to take a junior two days now takes Claude two minutes.
Below is a real-shape intake document for a fictional project called Loopstack — a sales-ops internal tool. Notice how short it is. Notice how each section is opinionated, not exhaustive. Notice how every word would change Claude's output.
This is where most people misuse Claude. They prompt: "create a moodboard for a fintech dashboard." They get something generic. They get frustrated. They go back to scrolling Dribbble.
What works: collect eight to twelve actual reference screenshots yourself. Real products you actually like. Paste them all into Claude Chat. Ask: "What's the visual grammar here? What do these have in common?"
You'll get specific, useful observations. Color palette tendencies. Type pairings. Density choices. The role of negative space. The treatment of data viz.
Now you have a brief for the visual system. Grounded in things you like — not in the average of the internet.
"What do these have in common" is too broad. Ask Claude to analyze each reference across these eight dimensions, then summarize the shared rules. The summary becomes your design brief.
Don't just collect hex codes — note which colors are canvas, which are accents, which are decoration only.
Serif/sans/mono mix. Display + body pairing. Italic usage. Letter-spacing on labels.
Negative space ratio. Hero height. Content max-width. Padding scale.
Reveal style on scroll. Hover behavior. Page transitions. What's animated and what's not.
If photo: editorial vs product vs lifestyle. If illustration: line vs flat vs textural. If none: what fills the visual moments.
Stroke weight. Joins (rounded vs miter). Whether icons sit in containers or stand alone.
Column structure. Symmetry vs intentional asymmetry. Magazine vs SaaS vs portfolio layouts.
Sentence case vs Title Case. Punctuation habits. Numerals vs words. Length of microcopy.
The exact prompt we use at Mullin Agency. Reusable across every project. Notice how specific the output format is — that's what gets you a usable analysis instead of a paragraph of vibes.
A film still (Wes Anderson, Lynne Ramsay). A magazine spread (Apartamento, The Gentlewoman). An album cover. An architectural photo. Pure-design references converge toward an average. Non-design references break you out of the SaaS gravity well.
"What are these references deliberately avoiding?" The answer is where your taste actually lives. "No carousels. No drop shadows. No 'AI magic ✨' decoration." Knowing the no's matters more than knowing the yes's.
The Loopstack moodboard analysis, derived from 8 references plus 3 non-design ones. Note how it ends with a copy-pasteable design tokens block — directly handoffable to Station 10 (mockups).
Combine the intake document with the moodboard analysis. Have Claude draft the product brief. One page.
It contains: the positioning, the audience, the three things the product must do, the three things it explicitly will not do, the rough scope and timeline.
Read it. Edit it. Send it to the founder. Get written sign-off before you've designed a single screen.
This step alone saves two weeks downstream. Most projects don't fail because of bad design. They fail because the team disagreed about what they were building, and the disagreement didn't surface until week six.
The brief is not a long-form document. It's a contract. Six tightly scoped sections, ~250 words total. If a section can be deleted without changing the project — delete it.
The constraint is the magic. Notice the word cap, the format requirement, and the "every sentence must change the project" test. That's what produces a brief instead of a slide deck.
Force three. Not five. Not ten. THREE. The constraint is the magic. When you allow ten, you get ten generic capabilities that mean nothing. When you force three, you get the three that actually matter — sharply argued because they had to fight for the slot.
Have someone unrelated walk by and read it. Ask: "What is this product?" If they can't say it back to you in one sentence — the brief is wrong. Edit. Repeat. A great brief survives a stranger reading it cold.
The Loopstack brief — drafted from the intake (Station 02) and the moodboard (Station 03), one page, locked, signed. The third document in the artifact chain. Notice how every sentence carries weight; nothing is filler.
For internal software, brand is usually thin. Logo, color, type, voice. Maybe a small icon set. For marketing or external products, the brand is most of the design — and most of the conversation with the founder.
Either way, the move is the same: react to options instead of starting from blank. I use Claude Cowork to generate four to five distinct directions, then refine the one that lands. Ten minutes from the moodboard analysis to having a real direction in front of the founder.
A "direction" is not a logo and three colors. A real direction is a system you could hand to another designer and have them build something coherent. Six components. Each one defensible.
The default failure mode of a brand prompt is getting five variations of the same idea. The fix is structural: force the output format, ground every direction in the moodboard, and demand defensibility.
Most people start with the logo. Don't. The logo is the last 5%, not the first 50%. The brand SYSTEM — color, type, voice, signature pattern — is what makes a brand recognizable. The mark is the cherry on a brand that already works without it. Build the system first. The mark almost designs itself.
When five directions sit in front of you, the safe one is forgettable. The direction that makes you slightly nervous is almost always the right one. It's the one with a point of view. The one that risks being wrong. The one a stranger would describe back to you in their own words. Safe brands die quietly. Risky brands get remembered.
The Loopstack brand-directions document — five truly distinct concepts, each defensible against the brief. Then the SELECTED direction (Editorial) expanded into the full system. Continues the artifact chain: intake → moodboard → brief → brand.
"A private trading desk. Ink, focus, one bright signal."
"A trade publication, not an app. Read this seriously."
"Warm and approachable. Sales is human work."
"Quiet competence. Built by adults, for adults."
"Pure utility. Zero decoration. Just the work."
This is where I always used to procrastinate. Sitting down in Figma and drawing boxes that represent screens. Day three of any project, I'd still be staring at an empty canvas.
Now: I describe the product to Claude Chat in a paragraph, hand it the brief, and ask for the full information architecture. I get a tree, edit it, and within an hour have a real map.
I get a tree. I edit the tree. The tree becomes the source of truth for everything downstream. Every wireframe will reference it. Every screen will live somewhere in it.
A real UI map isn't just the tree of screens. It's six layers stacked on top of each other. Skip any one and you'll discover the gap in week eight, when the engineer says "wait, what happens if there's no data here?"
:id paramsThe default failure mode is getting back a tree without states, or routes without flows. Force all six layers in the same prompt. The output becomes a real spec, not a mind map.
Before the polished hero, before the populated table — design the day-one moment. Most products die in the empty state. A blank table. A "no results" message. An awkward "add your first item" button. Get this right and the rest of the product feels mature. Get it wrong and the whole thing feels half-finished, no matter how good the populated state is.
Every screen in your map must be reachable from at least two other places. Nav link plus a contextual link. Breadcrumb plus a back button. Orphan screens become bugs you find in week eight — the "I clicked something and now I can't get back" moment. Audit the map. Find the orphans. Add the second route.
The Loopstack UI map — six layers, ready to hand to engineering. Continues the artifact chain: intake → moodboard → brief → brand → UI map. Each artifact tighter and more concrete than the last.
| Role | Dashboard | Quotes | Customers | Settings | Team | Billing |
|---|---|---|---|---|---|---|
| Admin | full | full | full | full | full | full |
| Manager | full | full | full | view | view | none |
| Rep | own only | own | own | none | none | none |
| Logged-out | none | none | none | none | none | none |
Old way: open Figma. Draw boxes. Move boxes. Three days later, have wireframes.
New way: have Claude Code generate raw HTML wireframes of every screen in your UI map. Black borders. Gray fills. System font. No design.
Why HTML and not Figma? Because HTML is real. You can click through it on your phone. You can put it in front of the founder on day three.
The wireframes are throwaway. But the act of building them clarifies the product. "Wait, why does this require three nested modals to do?" is the kind of question you only ask once you've tried to wireframe it.
Most wireframes are theatre. They look like wireframes but they don't do the job — they don't surface the real product questions. A great HTML wireframe forces you to confront six things that Figma lets you skip.
list.html + list-empty.htmlNotice the demand for both states, semantic HTML, and a deployable repo. The wireframes aren't a deliverable — they're a working environment.
Lorem ipsum makes every screen look the same length, the same density, the same vibe. Use REAL copy — drafted from the brand voice — and three problems surface immediately: a header that's too long, a label that's confusing, a button that says nothing. Real copy turns wireframes from theatre into truth-tellers.
Then walk around with it for 10 minutes. Try to do the primary task. Find every awkward tap, every missing back button, every place you have to pinch-zoom. Fix them before the founder ever sees the wireframes. Desktop hides too many sins. The phone is the ultimate stress test.
The Loopstack wireframes — a deployable repo with one file per route, both states for every list, real copy, real data. The sixth artifact in the chain: intake → moodboard → brief → brand → ui-map → wireframes.
Here's where most designers tap out. Database schema isn't a designer thing.
I'm going to push back. Even if you don't build the schema yourself, draft it. Because your design will live or die based on what data exists and what the system can return.
Have Claude Code write a schema. Have it explain the relationships. Push back on what doesn't make sense. Edit it. Make it match the actual product.
Most "design problems" are actually data problems wearing a wig. The act of getting the schema right is the act of getting the product right.
Schemas calcify the second they ship. The decisions you make in the first hour become the constraints engineering lives with for years. These six are the ones that, if missed, cost weeks of migration pain.
created_at — when this row first existedupdated_at — when it last changeddeleted_at — soft delete, never hardWHERE deleted_at IS NULL)Notice the explicit constraints — Postgres syntax, UUIDs, snake_case, soft deletes, and the demand to explain every table's purpose. Without these, you get a schema that looks right and falls apart at scale.
Tortured tables. Polymorphic relationships. Enums that should be tables. JSON columns where structure should be. The schema is the X-ray. When the schema feels muddy, go back and re-read the brief. The product is the muddy thing — not the schema.
created_at, updated_at, deleted_at. No exceptions. They cost nothing now, weeks later. Soft deletes prevent the "oh god, we lost the data" incident every product has at least once. The audit fields are insurance you don't realize you needed until you do.
The Loopstack schema — seven tables, multi-tenant, soft-deleted, indexed for the actual queries the UI needs. Annotated for engineering review. The seventh artifact in the chain: intake → moodboard → brief → brand → ui-map → wireframes → schema.
Have Claude Code generate the API specs from the schema. Endpoints. Request/response shapes. The auth model. The error states.
You're not committing to these specs forever. You're using them to test your design assumptions. "If the API can only return X, can the dashboard show Y?"
If the answer is no — redesign now, while you're still in HTML wireframes. Not after you've built three weeks of high-fidelity mockups that the system can't actually populate.
Most API specs are a list of endpoints and a happy-path JSON example. That's not a spec — that's a sketch. A real spec defines the contract for everything that can happen, including the failures, the slow responses, and the requests that retry.
/quotes/:id)/quotes/:id/send)Idempotency-Key header required on every unsafe method{ "data": ... } envelopemeta with request_id, timestamps, pagination?cursor=...&limit=N (max 100, default 25)meta.next_cursor?sort=field,directionNotice the per-endpoint requirements: which roles can call it, which UI screens use it, which most-likely error to return. Without these, you get an endpoint list. With them, you get a contract.
Have Claude generate a mock server from the spec — using the example responses. Now designers wire wireframes to real fetch() calls instead of hardcoded stubs. Engineers build the real backend in parallel against the same spec. Both halves of the team work at full speed for two weeks instead of one. When the real API ships, swap the base URL. Done.
Most APIs treat errors as an afterthought. {"message": "failed"} is a UX disaster — you can't show the user anything specific. A great error envelope has code (machine-parseable), message (human-readable), field (which input failed), request_id (so support can trace it). The error UX is half the product.
The Loopstack api-spec.md — auth model, standard envelopes, cursor pagination, full Quote endpoints with real JSON. The eighth artifact: intake → moodboard → brief → brand → ui-map → wireframes → schema → api-spec.
Authorization header.Idempotency-Key header.
| Code | HTTP | Meaning |
|---|---|---|
| validation_failed | 422 | One or more inputs invalid (see field) |
| not_found | 404 | Resource doesn't exist (or not in your org) |
| unauthorized | 401 | Missing or invalid token |
| forbidden | 403 | Token valid but lacks scope |
| conflict | 409 | Resource state prevents action (e.g., editing a sent quote) |
| rate_limited | 429 | Retry after meta.retry_after seconds |
| internal_error | 500 | Server failure — retry with exponential backoff |
request_id for support tracing. When a customer reports an issue, the request_id resolves it in 30 seconds instead of 30 minutes.Now you design.
But notice what's different. You're designing with full knowledge of what's possible. The IA is locked. The schema supports what you're drawing. The API can return what you're showing.
You're not designing in a vacuum and then asking engineering "can you build this?" — you ARE engineering. The translation problem evaporates.
I use Claude Cowork to draft initial mockups as HTML. Then round-trip to Figma where pure visual decisions are easier. Then back to HTML to ship.
The line between "polished wireframe" and "real high-fi" is whether the screen composes from a system. These six are the difference between a Figma file you'll throw away and a design system you'll ship.
By Station 10 you have the full chain — brief, brand, ui-map, wireframes, schema, api-spec. The prompt's job is to make Claude USE all of it. Tokens from brand. Routes from ui-map. Data shapes from api-spec. States from ui-map.
Build the design tokens (colors, spacing, type scale) before any screen exists. Every screen then composes from the system. When the founder says "can we make all the buttons a little bigger?" you change one variable instead of editing fifty files. The token layer is what separates a design system from a pile of mockups.
Use HTML for layout, system, and interaction decisions. Use Figma for one-off visual moments (the hero illustration, an ad creative, a presentation deck). Don't fight the medium. Each tool is good at what it's good at. The mistake is doing layout work in Figma — that's where the translation problem you eliminated comes back.
The system handles 95% of the interface. The other 5% — hero illustrations, marketing imagery, brand visuals, OG cards, motion clips — needs custom generation. Here's how to get great results without spending three days in Midjourney.
Generates clean, structured SVG for icons, brand marks, simple illustrations. The output is code — color-tunable, scale-perfect, instantly editable.
Reach for it when: you need vector output you can hand-tune to brand tokens
Atmospheric, cinematic, magazine-quality imagery. The undisputed leader for "feeling-driven" hero shots and editorial imagery.
Reach for it when: the brief calls for "mood" — not specifics
The only image generator that handles text reliably. Posters, badges with copy, typographic compositions where the words have to be readable.
Reach for it when: the image needs words that aren't gibberish
High-realism photography. Product on backdrop, lifestyle scenes, technical accuracy. The successor to SD3 for "this needs to look like a real photograph" briefs.
Reach for it when: the result must look like a photograph, not an illustration
Vector illustrations that hold visual consistency across a series. Train on a few brand examples, then generate dozens of on-brand pieces.
Reach for it when: you need a series of brand-consistent illustrations, not a one-off
4–10 second video clips. Hero loops, ambient motion, animated brand moments. Image-to-video for turning a still mockup into a marketing GIF.
Reach for it when: the hero needs motion, not a static image
Image-gen prompts have a structure. Composition, palette, style anchors, lighting, aspect ratio, negative prompts. Claude writes them better than most humans because the structure is the easy part — the hard part is the brand context, which is already loaded.
Build one paragraph that locks the visual identity — palette, type, lighting, mood, surface. Paste it into every image-gen prompt for the project. The same style key across 30 generations is what makes a brand visually coherent. Skip it and every image looks like it's from a different company.
Image generators default to a "house style" full of clichés. Negative prompts are how you escape it. "No drop shadows. No gradients on text. No AI sparkles. No oversaturated colors. No stock-photo lighting. No watermark. No text in the image." Specificity wins.
Don't try to one-shot the perfect image. Generate four variants. Then ask Claude: "Which of these best matches the brief? What would you change in the prompt to push the strongest one further?" Two passes beats ten one-shots. The critique step is where the brand calibration actually happens.
The Loopstack design system — real rendered components built from real tokens. The dashboard wireframe from Station 07 upgraded to high-fi using this system. The ninth artifact: intake → moodboard → brief → brand → ui-map → wireframes → schema → api-spec → design-system.
Claude Code is the right tool here. Component by component. Page by page. The hi-fi mockup from Station 10 isn't a picture — it's a spec. Hand it to Claude as the source of truth and start building against it.
The discipline is what changes. Small commits. Frequent reviews. Visual sanity checks at every step. Don't let Claude write five hundred lines without you reading them. Don't let Claude touch components you haven't seen rendered. The biggest failure mode in Claude Code isn't bad code — it's too much code, too fast, in directions you didn't sanction.
Ship to staging early. Ship to staging often. The "demo Friday" mindset is back — except every Friday is now every commit. The founder gets a URL. The URL changes. They tell you what's wrong. You change it.
Break any one of these and the session degrades. Break two and you're spending more time untangling than building.
One commit, one component, one mental model. "Add KPI card" not "build dashboard." If the diff doesn't fit on one screen, the commit is too big. Squash later if you want — but commit small now.
The non-negotiable gate before git commit. Not skim. Read. Claude makes its worst decisions in files you didn't open. The five seconds of friction here saves the five hours of debugging later.
Render → screenshot → eyeball → next. The tests pass and the page looks broken — that's the most common failure mode. A 2-second screenshot catches what a 200-line test suite misses.
Push to staging on every commit. The founder shouldn't ask "is it ready?" — they should refresh the URL and see. Vercel preview, Netlify branch deploy, fly.io app — pick the one your stack already supports.
Playwright on the brittle paths — auth, payment, the 3 user flows that actually matter. Skip the unit tests for pure-render components. Skip the snapshot tests entirely. They lie.
Every commit message says what changed and who wrote it. Co-Authored-By: Claude in the trailer. Six months later you'll want to know which lines came from where. Tag now, thank yourself later.
Anchor every Claude Code session to three artifacts: the design system, the API spec, and the wireframe. Then end with a hard stop.
Build the MRR sparkline card for the dashboard.
CONTEXT
- Design tokens: design-system/tokens.css
- Component library: design-system/_components.css (use existing Card, Skeleton, Sparkline)
- API contract: api-spec.md → GET /v1/metrics/mrr returns { points: [{date, value}], delta_30d }
- Hi-fi mockup: design-system/dashboard.html → .kpi-card[data-metric="mrr"]
- Existing pattern: see ARR card at src/components/cards/ARRCard.tsx
REQUIREMENTS
- States to render: loading (skeleton), empty (no data), populated, error
- Responsive: full-width on mobile, 1/3 width on desktop
- Numbers: format with Intl.NumberFormat (currency, no cents over $10K)
- Trend arrow: green if delta_30d ≥ 0, tomato if < 0
- A11y: aria-label includes "MRR, $X, up Y% over 30 days"
DELIVERABLES
1. src/components/cards/MRRCard.tsx
2. src/components/cards/MRRCard.test.tsx (Playwright — populated + error states only)
3. Wire into src/pages/Dashboard.tsx (replace the <PlaceholderCard metric="mrr" />)
STOP CONDITIONS
- After writing the files, render the dashboard locally and screenshot it.
- Stop. Show me the screenshot. Wait for sign-off before touching anything else.
- Do NOT refactor neighboring cards. Do NOT modify the design system.Every prompt ends with a hard stop. "Render. Screenshot. Wait." Without it, Claude Code will keep going — refactoring neighbors, adding tests you didn't ask for, "improving" the file structure. That's where sessions go off the rails. The stop is non-negotiable.
When something feels wrong, the cheap move isn't to debug — it's to git reset --hard HEAD and re-prompt with sharper context. Untangling Claude's "almost right" code costs more than re-rolling it. Treat each commit as cheap. Your time isn't.
Paste the screenshot back into Claude with the hi-fi mockup. "Here's what you built. Here's what it should look like. List every difference, then fix only what you listed." Forces Claude to commit to a list before changing code — cuts scope creep to zero.
Adds the MRR card spec'd in design-system/dashboard.html. Loading, empty, populated, error states. Wires into the dashboard grid; removes the PlaceholderCard.
Test discipline
Most teams using Claude end up with the wrong test pyramid — top-heavy on unit tests Claude wrote because they were easy, light on the e2e flows that actually break in production.
Production deploy. Real users. Feedback loop opens. The page goes from "the thing we're building" to "the thing they're using" — and that flip changes everything downstream.
The thing that's actually different now: feedback comes in, and you can iterate the same day. Not "let me schedule a sprint." Not "we'll get to that next quarter." Same. Day. A founder messages at 11:42. You push at 12:04. They refresh and it's there. That's the new tempo.
The relationship with the founder changes too. You're not a vendor delivering on a six-month contract anymore. You're a co-designer iterating in real time, and your pricing model has to catch up to that — which we'll get to in a moment.
"Ship faster" without these is just "break faster." Wire each of these up before the first production deploy and the cycle stays clean.
A unique URL per branch. Vercel, Netlify, Render — they all do it free. The founder lives at pr-47.staging.app while you build, not at "let me schedule a demo."
The new version goes live next to the old one. Switch traffic. If something explodes, switch back. Three seconds, not three hours. Confidence to ship comes from confidence to roll back.
Every risky change behind a kill switch. New checkout flow? Flag. Redesigned onboarding? Flag. Ship dark, toggle to 1%, watch, expand. The flag is the difference between shipped and shippable.
Sentry for errors. Plausible (or PostHog) for behavior. A tiny status page on a subdomain. You should know about a broken page before the founder does. Wire it in before launch, not after the first incident.
Real domain, real TLS, real name on the door. A page on app.loopstack.com reads as shipped. A page on loopstack-prod.fly.dev reads as still cooking. Treat the URL as part of the launch.
Release notes live on a public page. Users see what changed. Founders forward them around. Investors notice the cadence. The changelog is marketing — and it's free if you wrote conventional commits in Station 11.
Tagging, changelog generation, release notes, Slack post — all of it is mechanical. Claude handles it in one prompt and you stay focused on the work.
Ship a new release.
CONTEXT
- Repo: github.com/loopstack/app
- Last tag: v0.6 (3 days ago)
- Convention: semver, conventional commits, releases live in /releases
- Slack channel for announce: #loopstack-ship (use the pre-configured webhook)
DO IN ORDER
1. List commits since v0.6. Group by type (feat / fix / chore / flag).
2. Decide the bump: feat → minor, fix → patch, breaking → major.
Show me the version + reasoning. Wait for "go" before tagging.
3. After "go": create the git tag. Generate releases/v{X}.md with:
- Headline (one sentence, plain English — what the user gets)
- Highlights (3–5 bullets, founder-readable, not engineer-readable)
- Behind-the-scenes (anything technical worth surfacing)
- Flags toggled (if any) and rollout %
4. Push the tag. Trigger the deploy via the GitHub Action.
5. Post to #loopstack-ship: version, headline, link to release notes,
link to staging diff. Tag @founder.
STOP CONDITIONS
- Stop after step 2. Show me the bump + draft notes. Wait for "go."
- If any commit message looks ambiguous, ask before grouping it.Same env, same secrets, same deploy path. Only the URL differs. Bugs that only show in prod are bugs you didn't catch because stage was lying to you. If your stage has a SQLite shim and prod has Postgres, you don't have a stage — you have a placebo.
Once a month, deliberately roll back something benign on a Friday afternoon. Not in response to an incident — as a drill. Confidence in rollback IS confidence in shipping. If the team flinches at the rollback button, the cycle is fake.
The new payment provider, the new dashboard, the redesigned onboarding — all flagged. Default off. Toggle to internal users first, then 1%, then 10%, then everyone. Shipping isn't binary anymore — it's a dial. Use the dial.
compact_kpi_grid flag shipped dark — internal only. Will roll out next week.claude/mrr-range-toggle opened. Preview URL live at 11:51.Twelve stations. Discovery to deploy. The work didn't get smaller — the cycles did.
That's the technical case. Functional software, shipped continuously, with a founder in the loop and a changelog as the receipt. Now the soft case — because the page that sells the work is its own discipline, with its own twelve.
Part Two · The marketing pageNow the soft case. No backend. No database. The page has to do one thing: convince someone to click the button. The cycle is shorter, the tools are different, the judgment moments are different.
For marketing, discovery is not about extracting product requirements. It's about extracting the founder's actual voice. The way they describe what they do to a friend at dinner — not the way they write for their homepage. Those are two different people. The dinner version is the one that converts.
Record them talking. Transcribe it. Drop it in Claude Chat. Then ask Claude to build a voice profile — a structured, referenceable artifact that every piece of copy you generate from here forward gets grounded in. Not vibes. A document.
This one move kills the most expensive failure mode in marketing copy: the generic SaaS voice. "We help businesses scale their digital transformation journey." Nobody says that out loud. Nobody. So nobody should write it.
Don't ask Claude for "their voice" in the abstract. Ask for these six specific outputs. Each becomes a section of the profile you'll reference for the rest of the build.
30+ minutes of the founder talking unscripted. Not a meeting. Not a Zoom panel. A conversation. Whisper it to text and paste the whole thing in. Volume matters — five minutes isn't enough to find a pattern.
The phrases they reach for repeatedly. "Look, the thing is…", "basically what we do is…", "weirdly enough." These are speech tics — and they're the single fastest way to sound like the actual person.
Words this founder would never use. synergy. leverage. solutions. seamless. The list is short but load-bearing — it's the guardrail Claude needs to not slip back into corporate voice on the next prompt.
Three to five lines so specific to them they almost double as branding. "We're not the next Salesforce." "One thing to work." Pull them verbatim. These will show up on the homepage, in the footer, in the OG card.
The two or three anecdotes they fall into when explaining the thing. The customer who said the weird thing. The moment they realized the old way didn't work. Stories > claims. One real anecdote outperforms five bullet points.
Who they're talking to, and who they're talking against. A founder who says "engineers who are tired of building the same dashboard" just told you both the audience and the enemy. Pull both — copy needs the contrast.
Paste the transcript. Ask for the six outputs explicitly. Don't accept "their voice is direct and friendly" — that's vibes, not a profile.
I'm building a marketing site for the founder below. I need a voice profile
I can hand to a copywriter (or to you, in a future prompt) so every word
sounds like this person — not like generic SaaS.
TRANSCRIPT
[paste 30+ minute transcript of the founder talking unscripted]
OUTPUT — a voice-profile.md file with these six sections:
1. TONE DESCRIPTORS — 3 adjectives that fit this person specifically.
Not "professional and approachable." Words their friends would use.
2. IDIOM INVENTORY — 8–12 verbatim phrases they reach for repeatedly.
Quote them exactly. Note frequency where useful.
3. BANNED WORDS — 6–10 words they would never use, with one-line
explanation of why. Be ruthless about corporate words they avoid.
4. SIGNATURE PHRASES — 3–5 lines so specific they could be on a t-shirt.
These are headline candidates. Quote verbatim, don't paraphrase.
5. STORY BANK — 2–3 anecdotes they tell. Customer name, situation,
what made it interesting. One paragraph each.
6. AUDIENCE READ — Who they're talking TO (1 paragraph) and what
they're talking AGAINST (1 paragraph). Both matter.
CONSTRAINTS
- Quote verbatim where you can. Paraphrasing kills the voice.
- If the transcript doesn't support a section, say so — don't invent.
- Every signature phrase has to appear in the transcript. No new lines.Zoom voice ≠ real voice. Founders perform on Zoom — they slip into pitch mode within thirty seconds. Call them on the phone. Or sit across from them with a coffee. The voice you want shows up in the third minute, when they've stopped explaining and started talking.
Best shortcut in the business. If the founder has been on any podcast, the host already did the warm-up for you. Pull the YouTube transcript. Skip the first five minutes (intro). Use the next forty. Free, real, unscripted, 60 minutes long.
Direct. No hedging, no "kind of," no "we're working on." She says the thing.
Self-aware. Names what they're not. "We're not the next Salesforce" appears 4 times.
Slightly impatient. Cuts off her own sentences when she's already moved to the next thought.
She uses scale exactly once in 42 minutes — and only to mock it: "everyone says they help you scale, what does that even mean."
"We built the thing you were going to hire two engineers to build."
"We're not the next Salesforce. We just want one thing to work."
"It's not a platform, it's a tool. There's a difference."
The first customer. A logistics co-op in Oakland — 9 dispatchers, no engineering team, was running on three Google Sheets and a prayer. Bought Loopstack on day two of the trial. Maya tells this story in every sales call.
The Salesforce demo. She sat through one as a customer, in 2022, and walked out swearing she'd never build software like that. The talk literally started "I want to tell you about a really bad demo."
Who she's talking to: ops leaders at 20–80 person companies who are one engineer short of building the internal tool they actually need. They have spreadsheets that have outgrown spreadsheets. They've priced Retool and felt poor.
What she's talking against: the "platform" pitch. Anything that takes six months to onboard. Anything that needs a Solutions Engineer. Anything sold by someone in a quarter-zip.
"Loopstack is a low-code platform that empowers operations teams to seamlessly scale their internal tooling and unlock new efficiencies."
"We built the thing you were going to hire two engineers to build. It's a tool. Not a platform. There's a difference."
The most important sentence on a marketing page is the first one. Not the headline. The first sentence. The one that decides whether anyone keeps scrolling. Get it right, the rest of the page has a chance. Get it wrong, none of the rest matters.
So I ask Claude: "Here's the company. Here's the voice profile from Station 01. Here's the audience. Give me ten different first sentences. The kind where, if your ideal customer read it, they'd immediately know whether to keep reading or close the tab."
Then I pick the one that makes me most nervous. The one that scares me a little. Almost always the right one. The safe ones are forgettable — and forgettable means the page bounces. The scary one earns the click.
If a candidate sentence fails two of these, kill it. Three, and you're being polite — kill it harder. The winning sentence passes all six and still makes you nervous.
The reader should know in word three whether this is for them. "For ops leaders at 20-person companies" wins over "for modern teams." The page that tries to talk to everyone gets read by no one.
"Hire two engineers" beats "build internal tools." A number, a name, a concrete object — anything you can see. Vague claims are bounce fuel. Specifics earn the next paragraph.
Either there's a cost to ignoring this or there's a payoff to clicking. Often both. The reader should feel a small pull at the end of the sentence. No pull = no click.
Subject. Verb. Object. Punctuation. Taglines feel like ad copy. Sentences feel like someone talking to you. The page is supposed to be a person, not a poster.
"Built," "replaced," "killed," "saved." Skip "empower," "enable," "unlock," "leverage." If you wouldn't use the verb in a sentence to a friend, don't use it on the page.
The best first sentences menace the status quo just a little. "You were going to hire two engineers" implicitly says "you were about to make a $400K mistake." Threat is what makes the safe option feel expensive.
Don't ask for "the right" first sentence. Ask for ten — including bad ones. The bad ones are how you find the good one.
Generate 10 candidate first sentences for the Loopstack marketing site.
CONTEXT
- Voice profile: brand/voice-profile.md (use the signature phrases &
banned-words list — if a candidate uses a banned word, mark it red)
- Audience: ops leaders at 20–80 person companies, one engineer short
of building their internal tool
- Against: the "platform" pitch, six-month onboarding, Solutions Engineers
REQUIREMENTS
- All 10 must be ONE sentence. Subject + verb + object + period.
- Mix of registers: 3 safe / 4 specific / 3 risky.
- For each one, also draft the natural second sentence — so I can see
where the page actually goes from there. (Sentence 1 sets up sentence 2.)
- For each one, give a one-line gut-read: who it lands with, who it loses.
OUTPUT FORMAT
01. [sentence]
Then: [the natural next sentence]
Reads to: [who it lands with] Loses: [who it loses]
CONSTRAINTS
- No taglines. Every candidate has to be a complete sentence.
- No "we help" openings. They're banned this round.
- Don't tell me which one is best. I pick. Just generate.Read the candidate sentence out loud, the way you'd say it to a friend across a table. If it makes you cringe — good, that means you'd never say it. If it sounds like something you actually would say, ship it. The page is a conversation, not an announcement.
Could Linear's homepage use this sentence? Could Notion's? If the answer is yes, kill it. The good first sentence is one your closest competitor literally cannot say. Either because they don't believe it or because their lawyers wouldn't let them.
Read the top three candidates to the founder. Watch their face. The one that makes them flinch — "oh god, can we really say that?" — is almost always the right one. Their flinch IS the conviction the customer needs to feel.
Audience: "you were going to hire two engineers" lands in 6 words for the exact ops leader Maya described. Specific: a number — two — not "an engineering team." Stakes: implies the reader was about to spend $400K. Sentence: subject + verb + object + period. Verb: "built" — concrete, past tense, done. Threat: the safe alternative (hiring) just got expensive in 14 words.
Maya flinched when she read it. We shipped it.
Same flow as functional software. Faster, because marketing has fewer constraints. You have a homepage — not a system. No accessibility matrix, no dark mode, no permission tier. Just a page that has to feel like the founder.
That's the only real rule for a marketing brand: it has to feel like the founder. Internal software can have a sterile brand and survive. Marketing can't. People buy from people they trust, and trust comes from voice — not from a 60-page brand guideline that never gets opened again.
Keep the references human. Pull from their LinkedIn posts, podcast appearances, the books on their desk, the way they describe themselves to friends. That's the brand. Then ask Claude to generate three directions and pick the one that feels most like the person — not the one that looks most like the category.
The logo is the smallest decision in this list. The biggest is the references. Get those right and the rest falls out.
The voice profile from Station 01 IS the brand voice. Don't rebuild it for the visual layer. The way the founder talks dictates how the type sets, how the words punctuate, how the buttons sound. Visual brand is voice rendered.
If your moodboard is full of other SaaS sites, you'll build another SaaS site. Pull from magazines, museum sites, restaurant menus, indie bookstores. The brand that stands out in a category came from outside the category.
Don't open Coolors. Open the references. Eyedrop the colors out of the photograph that made you feel something. Palettes pulled from the real world have weight that Dribbble palettes never do.
One serif with mood (Fraunces, Tiempos, Source Serif). One clean sans (Inter, Söhne, Mona). Optional mono. The italic of the serif is the personality. If the italic doesn't have a voice, change the serif.
How does it move? Snappy or slow? Easing curve? Hover style? Motion is half the brand on a marketing site and almost no static moodboard captures it. Write a one-paragraph "feel" description before the first CSS line.
The most underrated brand artifact. No gradients. No stock photography. No emoji bullets. No floating screenshots at a 7° angle. The "no" list is shorter than the "yes" list and saves three review rounds.
Asking for "the brand" is a trap — you'll get the safe, average direction. Ask for three with deliberately different center-of-gravity. The act of comparing forces the choice.
Generate 3 brand directions for the Loopstack marketing site.
CONTEXT
- Voice profile: brand/voice-profile.md
- Positioning: brand/positioning.md (the chosen first sentence: "We built
the thing you were going to hire two engineers to build.")
- References (NOT competitors): the New Yorker, A24 film posters, the
redesigned Pitchfork, Sibyl bookshop in Brooklyn, McSweeney's print
- Audience: ops leaders, 20–80 person companies, allergic to "platform"
OUTPUT — three named directions, each with:
1. NAME & ONE-LINER — direction name + one sentence of feel
2. PALETTE — primary, secondary, accent, neutral, ink. Hex codes.
Pull colors from the references where possible — say which ref.
3. TYPE — display + body + mono. Why this pairing fits the voice.
4. MOOD — one paragraph. Imagine the homepage scrolled past.
What does the reader feel in 2 seconds?
5. NO-LIST — 4–6 things this direction is NOT.
6. RISK — what's the case AGAINST this direction? Be specific.
CONSTRAINTS
- Each direction has to be DIFFERENT — not three flavors of the same idea.
- One direction should make me nervous. The other two should be safer.
- Don't recommend. I'll pick. Just present.If you reference Linear and Vercel, you'll build a worse Linear. If you reference the New Yorker and A24, you'll build something a SaaS site has never looked like before. The reference shelf is the brand. Curate it like a museum.
Open the photograph that made you feel something — the one you saved to a Pinterest board you'll never open again — and eyedrop. Real-world palettes have temperature. Screenshot palettes have RGB. Temperature wins.
Before you commit to a direction, render it as a tiny hero card — palette, type, one sentence. If it doesn't have presence at thumbnail size, it doesn't have presence at full size. The hero card test is 10 minutes and saves a week of "something feels off."
Reads as "Linear, but louder." High contrast, mono-heavy, lots of monospace numbers. Confident but starts to feel like every other dev tool by row two.
No · feels like the categoryCream paper. A serif with an italic that sings. Klein blue as accent, ochre as warning. Reads like a magazine spread that happens to sell software. Pulled from the New Yorker + Sibyl bookshop.
Yes · doesn't look like SaaSA wholesale invoice that became a website. All monospace, sage + maroon, raw grid lines, table-like layouts. Bold but might tip into "design portfolio" — too edgy for the audience.
Maybe · risky for ops buyersA marketing wireframe is just a section list in order. Hero. Social proof. Three benefits. Featured work. FAQ. CTA. The hard part isn't the list — it's the order. Reorder these six sections badly and the page reads like a catalog. Order them well and the page reads like an argument.
Have Claude Code generate the structure as raw HTML — no styling, no images, no CSS. Just blocks of text in correct hierarchy. Then read the whole page out loud, top to bottom, in one breath. If you stumble, the structure stumbled. Fix it before you write a single line of CSS — because every CSS commit you make on a broken structure is a commit you'll throw away.
This is the cheapest review round in the whole pipeline. Five minutes. No design. No code. Just words. And it catches problems that would cost you a week to fix later.
If a section breaks one of these, it's probably the section that's about to get cut. Test each one before you commit.
If a section is making two promises, it's two sections. "We help you ship faster AND we have great support" is two sections. Pick one promise. The reader's brain only holds one per scroll-screen anyway.
The page is a one-act play. Hook → believe me → here's why → here's proof → here's the ask. If you can swap two sections and it still works, your structure's too loose. Order matters because argument matters.
Write the job in one sentence next to the section name. "This section convinces them we've done it before." If you can't name the job, the section is decoration. Decoration is the enemy of conversion.
Every section has to land on its own. "Here's what we'll cover next" is a tell that the order is wrong. The reader is scrolling, not reading a syllabus. If a section needs the next one to make sense, swap them — or kill one.
Once at the top (low commitment), once mid-page (after proof), once at the bottom (high commitment). Not the same CTA. Top is curious. Middle is convinced. Bottom is decided. Tailor the language to the moment.
Out loud, top to bottom, no skipping. If it takes longer than 90 seconds to read, it'll take 5 seconds to bounce. Everything past the 90-second mark is for the convinced — not the converting.
No images, no styles, no CSS classes. Just <h2>s and <p>s. Force the words to do the work — that's the whole point of this stage.
Generate the section structure for the Loopstack marketing site as raw HTML.
CONTEXT
- Voice profile: brand/voice-profile.md
- Positioning: brand/positioning.md (first sentence: "We built the thing
you were going to hire two engineers to build.")
- Brand direction: Editorial Workshop (per Station 03)
- Audience: ops leaders, 20–80 person companies
OUTPUT FORMAT
A single .html file. No CSS. No images. No <div>s for layout.
Each section is just:
<section>
<!-- JOB: [one-sentence job for this section] -->
<h2>[section headline as written copy]</h2>
<p>[supporting copy, 1–3 sentences]</p>
[optional: <ul>, <blockquote>, <a class="cta">CTA text</a>]
</section>
REQUIREMENTS
- 6 to 8 sections, no more.
- The HERO section uses the chosen first sentence verbatim.
- One section is social proof (logos, customer quote, or number).
- One section is "what makes this different" — be specific, not abstract.
- The CTA appears 3 times, with DIFFERENT copy each time
(top = low commit, middle = post-proof, bottom = decided).
- Each section's job comment is mandatory. If you can't write the
job in one sentence, that section is wrong.
THEN
Read the whole file top to bottom as if you're reading aloud.
At the end, tell me where it stumbles. I'll fix from there.Better than reading it to yourself: read it to someone who has never seen the product. Your partner. The barista. The friend who asked what you're working on. Watch their face. Where their face goes blank is where your structure goes blank.
Every wireframe Claude generates has at least three sections that are secretly all "about us." Process. Mission. Team. Story. Pick one. Cut the others. The reader doesn't want to be friends with you yet — they want to know if the thing works.
Open a stopwatch. Read the whole page out loud at normal speed. If it's over 90 seconds before you hit the bottom CTA, the page is too long. Cut the longest section. Re-time. Repeat until you're under. The page that reads in 60 seconds outperforms the page that reads in 3 minutes — every time.
"We built the thing you were going to hire two engineers to build. See it or try it free."
"Oakland Logistics Co-op ships 12 dispatcher tools on Loopstack. So do these four other teams you've heard of."
"You almost hired two engineers. You almost bought Retool. You almost built it on three Google Sheets. We've watched all three."
"One: ship in a week. Two: no engineer required. Three: we don't sell platforms — we sell tools."
"Here's Oakland Logistics. Here's what they were doing before. Here's what they shipped on Loopstack. Eight days, no engineer."
"What if it breaks? How is this not Retool? Can we self-host? What's it cost? Why's it called Loopstack?"
"Start a 14-day trial. No card. We'll help you ship the first tool by Friday."
Drop in: the voice profile, the positioning, the brand directions, the section structure. Ask Claude to draft the copy for every section in the chosen voice. It will give you something OK. Don't ship the OK. The OK is scaffolding.
The Claude draft is never the final draft. Your job — the part that earns the retainer — is what comes next: cut forty percent, replace clichés with specifics, replace passive voice with active, replace "we help businesses grow" with "we built the thing you were going to hire two engineers to build."
The pattern is always the same. Draft → cut → re-render. Your edits are the product. Claude wrote the bones. You write the voice.
Run these in order on every section. The first three are mechanical — Claude could do them but you'll catch more. The last three are taste.
Not 10. Not 20. Forty. The first draft is always over-explaining. The reader doesn't need the warm-up paragraph. Delete it. They got to the page already convinced they had a problem — your job is the verb.
"Lightning-fast" → "loads in 200ms." "Loved by teams" → "used by Oakland Logistics, Field Co, and 1,200 others." Every cliché has a number, name, or noun underneath it. Find it. Use it.
"We help teams ship faster" → "You ship faster." Or just "Ship faster." The reader doesn't care what you do — they care what they get. "We" is the most expensive word on a marketing page.
One concrete number lifts a whole section out of the abstract. "In a week." "$0 to start." "Used by 3 of YC's W25 batch." The number is the anchor that the rest of the section earns its credibility from.
If the adjective could be removed without changing the meaning, kill it. "Powerful platform" → "platform." "Beautifully designed dashboards" → "dashboards." Every adjective you keep should be doing work. Most aren't.
Same test as Station 04. After every edit pass, read the section out loud. If you trip on a word, your reader will too — they just won't tell you, they'll just leave. The mouth is the most honest editor.
Specificity in the prompt is everything. Tell Claude the voice profile, the section job, the word budget, and the banned words. Then accept that the draft is a starting point.
Draft the marketing copy for the Loopstack site, section by section.
CONTEXT
- Voice profile: brand/voice-profile.md (load it. Use the signature
phrases. Avoid every word on the banned list.)
- Positioning: brand/positioning.md (the chosen first sentence is canon —
do not paraphrase it. Use it verbatim.)
- Wireframe: site/marketing-wireframe.html (every section has a JOB
comment — that's the brief for that section)
OUTPUT — for each section in the wireframe:
HEADLINE — 4–10 words. Has to land out loud.
BODY — 2–4 sentences max. ~50 words.
CTA — 2–4 words. Different per section.
CONSTRAINTS
- No banned words. None. Not even once.
- No "we help." Banned this round.
- One concrete number per section minimum.
- The hero section uses the canonical first sentence verbatim.
- Each section serves the JOB comment from the wireframe — if your
draft doesn't, rewrite before showing me.
THEN
After each section, do a self-edit pass:
- count words
- flag any banned words you slipped past
- flag any sentence that wouldn't read out loud cleanly
- cut 20% if possible without losing meaning
Show me the original draft + your self-edited version side by side.
I'll do my own pass on top.For every sentence, ask: can I delete a word and have it still mean what it means? If yes, delete. Repeat until no. Most marketing copy carries 40% pure scaffolding. Hemingway pass strips it. The remaining sentence is denser, faster, and louder.
Hold every sentence up against the founder's voice profile. Would Maya say this in a Slack message? If no, rewrite. The test isn't whether the sentence is grammatically correct — it's whether the founder would recognize themselves in it.
Before you tweak a clunky sentence, try deleting it entirely. Read what's left. Half the time, the page is better without it. If you genuinely need it, it'll be obvious — and the rewrite will be easier because now you know what work it has to do.
Loopstack is a powerful low-code platform that helps modern operations teams seamlessly build the internal tools they need to scale, without hiring engineers or waiting months for IT to deliver.
Loopstack is a powerful low-code platform that helps Build modern operations teams seamlessly the internal tools you need — build the internal tools they need to scale, without hiring engineers or waiting months for IT to deliver.
We built the thing you were going to hire two engineers to build.
Lightning-fast development cycles let your team iterate quickly and respond to customer needs in real time, dramatically reducing time-to-market for critical internal tools and dashboards.
Lightning-fast development cycles let Ship a tool your team iterate quickly and respond to customer needs in real time, dramatically reducing in a week. time-to-market for critical internal tools and dashboards. Most ship by Friday.
Ship a tool in a week. Most ship by Friday.
Start your free 14-day trial today. No credit card required. Our team is here to help you get up and running with Loopstack as quickly as possible.
Start your free 14-day trial today. Start a 14-day trial. No credit card required. Our team is here to help you get up and running with Loopstack as quickly as possible. We'll help you ship the first tool by Friday.
Start a 14-day trial. No card. We'll help you ship the first tool by Friday.
Now the visual layer. You're a designer here — but you're not designing in Figma and translating to code. You're designing in Claude Cowork. Building real HTML, real CSS, real type, real grid, all in the medium the page will ship in. The translation step is gone. The Figma → code tax is gone. The "well, in design it looked like…" conversation is gone.
The three Claude surfaces blur into one workflow. Chat for the big-picture thinking — "what would Pentagram do here?" Cowork for file-aware iteration — "rev v1 of the hero, here's the brand brief." Code for "wire up the smooth-scroll on the CTA." Different surfaces, different moments, same project context.
This is the unlock that took me longest to internalize: the Figma comp is no longer the deliverable. The HTML is the comp. Once you accept that, the cycle compresses by an order of magnitude.
Each one removes a translation step. Stack them and the whole "comp → spec → build → review" pipeline collapses into one continuous edit.
Open the .html file. That's your canvas. There's no "design phase" before this. The first thing you push to the file is a section structure with placeholder copy — and you iterate from there.
Load the actual webfonts on the first commit. Don't design with Helvetica and "swap later." Type sets the rhythm of every other decision — getting it wrong on day one means redesigning on day five.
Your grid is CSS Grid or flex — not a 1440-wide artboard. It responds the moment you resize the browser. You can't "design responsive" — you can only build responsive and watch it.
DevTools replaces the Figma inspector panel. Tweak padding live, see it instantly, paste the value back into the file. The inspector is the tool, not a separate step. No more "let me update the comp."
Save hero-v1, hero-v2, hero-v3 as actual files (or branches). You can pull up all three side-by-side in the browser at full fidelity. Try doing that with Figma frames at production type-scale. You can't.
Figma → code is where 30% of the design dies. Spacing changes. Type tightens. Cursor states get forgotten. If you design in code, none of that loss happens. The thing you saw at v3 is the thing that ships.
The blur isn't sloppy — it's specialization. Use the right surface for the right moment and the whole project moves faster.
For marketing pages, skip Figma entirely. Open Cowork, ask Claude for the section structure as raw HTML, then style it live. You'll be at hero-v3 in the time it would have taken to make the first Figma frame. The fidelity gap closes immediately because there is no fidelity gap.
When you DO need Figma — and you sometimes do, for moodboards or client review decks — keep it upstream of code, never downstream. Figma for thinking, never for handoff. The handoff is the thing being shipped, and the thing being shipped is the HTML.
For ops teams, 20–80 people.
Try Loopstack →Loopstack is the internal-tools layer your ops team is one engineer short of building. 14-day trial. No card.
Start a trial →Internal tools, in a week. No engineer required. Most teams ship the first one by Friday.
Start a trial →Same shape as Part 1, way faster, because there's no backend, no database, no migration. Drag the folder to Netlify. Connect the domain. Set up Plausible. You're live. The whole final-mile is half a Tuesday afternoon — if you've kept the polish list close.
The founder shares the link with three friends. Three pieces of feedback come back in the next hour. You incorporate two of them by lunch. Push the update. The friends see version two by dinner. That's the whole loop. That's the new tempo.
This used to be a quarter of work. Now it's a Tuesday. The page that took 9 weeks last year takes 6 days this year — and the thing that broke loose isn't the design, isn't the code, isn't even the AI. It's the cycle.
The difference between a page that bounces and one that converts is rarely the headline — it's whether the polish list got run before launch. Run it.
The page exists in the browser tab and on every social share. If your favicon is the default globe and your OG card is broken, the page is unfinished — no matter how good the hero is. Both take 20 minutes. Do them.
The page should feel instant. Inline the critical CSS, defer scripts, preconnect the font CDN, ship a single self-contained HTML where you can. Marketing pages live or die on first paint — get it under 200ms or you'll lose the impatient half of the audience.
From any scroll position, the reader should be one swipe away from the next CTA. Sticky footer button, repeated mid-page CTA, big bottom one. Friction kills conversion. Make the click cheap.
Not "responsive in Chrome's DevTools." On an actual phone, on actual 4G, ideally on the founder's actual phone. The desktop preview lies. The phone tells the truth. Test on the phone.
Drop the URL into Slack, X, iMessage, LinkedIn. Does the preview card make you proud? The OG image is the first impression on every share — bigger reach than the homepage itself, in most launches.
Alt text on every image. AA contrast on every text-on-color combo. Keyboard reachable. Skip the perf flex on Twitter and run axe instead. A page that fails contrast is a page some of your buyers literally can't read.
Generating the OG image, drafting the announce post, wiring analytics, posting the changelog — all mechanical. Claude does it in one prompt while you stay focused on the page itself.
Ship the Loopstack marketing site.
CONTEXT
- Site files: /site/
- Brand: brand/marketing-brand-directions.md (Editorial Workshop)
- Voice: brand/voice-profile.md
- Domain: loopstack.com (registered, DNS TBD)
- Hosting: Netlify (drag-deploy from /site/)
- Analytics: Plausible (acct already created, site needs adding)
DO IN ORDER
1. PRE-FLIGHT — run through the polish checklist:
favicon · OG image · TLS · 404 page · robots.txt · sitemap ·
alt text · color contrast · mobile breakpoints · sticky CTA
For each: pass / needs work + one-line note. Stop. Show me.
2. After "go": generate the assets.
- favicon.svg (use the M lockup, on cream)
- og-image.svg (1200×630, headline + brand mark + URL)
- apple-touch-icon.png
3. WRITE the launch posts (don't post yet, draft only).
- LinkedIn (Maya's voice, 4–6 sentences, 1 link)
- X/Twitter thread (4 posts max, no hashtags)
- Customer Slack post (warm, direct, 2 sentences)
4. Wire Plausible + verify the snippet renders.
Confirm the test ping shows up before you call it done.
5. Generate releases/v1.0.md as the public changelog entry.
Use the same format as the Loopstack app releases.
STOP CONDITIONS
- Stop after step 1. Show the polish checklist. Wait for "go."
- Don't post anything live. Drafts only.
- Don't change the DNS. I'll do that by hand.Open the page on your actual phone, on actual cell data, ideally not on your home Wi-Fi. The Chrome responsive-mode preview is a lie. The phone has the real font rendering, the real touch targets, the real scroll feel, the real loading speed. Half the bugs you'll fix at this stage are bugs the desktop hid.
Take a screenshot of the hero. Would you actually send this to a friend? Would the founder send this to their friends? If no — the polish isn't done. The screenshot is the share unit, not the page. Optimize for the screenshot.
For most launches, the OG card gets seen 10–100× more than the homepage. Every Slack share, every X post, every iMessage preview, every LinkedIn embed. Spend an hour on the OG image. It's the single highest-leverage asset on the page.
Seven stations. Voice to launch. The work didn't get smaller — the cycles did. Again.
That's the soft case. A marketing page that used to be a quarter is now a Tuesday — and the page that's retainer-priced is a page that stays alive instead of going stale. Now: what nine weeks looks like next to six days, side by side, with the same humans on both sides of the comparison.
Before / After · same humans, different tempoSame humans. Same brand quality. Different process. Let me make this concrete.
Discovery call to live deployment. Three rounds of stakeholder review. Three rounds of design iteration. One round of "wait, can we redo the hero?"
Time to shipDiscovery to live. One round of review. Zero stakeholder fights — because the brief was so sharp the stakeholder agreed before we'd designed a single screen.
Time to shipWhat changed? The unglamorous middle of the project collapsed from weeks into hours. Which freed up time for the parts that need a human — the strategy, the taste, the "is this the right thing to ship" moments.
They'll get you eighty percent of the value. The other twenty percent is taste, and that's on you.
Claude is a master of inference. It is not a parser of descriptions.
If you want it to design like Pentagram — don't describe Pentagram. Paste five Pentagram projects. If you want it to write like Stewart Butterfield — don't describe Stewart Butterfield's voice. Paste a Stewart Butterfield essay. If you want it to build a dashboard like Linear — don't describe Linear. Paste a Linear screenshot.
Words are lossy. Examples are perfect.
The corollary: if you're getting generic outputs from Claude, the problem is almost always that you gave it generic inputs. The fix is upstream of the prompt.
Bad prompt: "Can you help me build a dashboard?"
Good prompt: "Build a dashboard with three cards in the top row showing MRR, churn, and active users. Below: a chart of weekly signups over the last twelve weeks. Use Tailwind. Match this attached design. Use this data shape."
Specifications get specifications back. Questions get hedging back.
The exception: if you don't know enough to spec it — write the spec with Claude. But write it. Don't ask "what should I build?" Ask "given X, Y, Z, here's my draft spec — push back on what's missing or wrong."
You're the senior. Claude is the smart junior. Smart juniors are great when you bring a brief. Smart juniors are useless when you bring a vibe.
Most people use Claude wrong because they use one surface for everything. There are three. They are not the same.
Claude Chat is for thinking. Exploration. The early generative work. The "what if" conversations. Use it for ideation, for analysis, for talking through tradeoffs.
Claude Cowork is for files. For iteration in the middle of a project, when you have artifacts you're working with. Use it for writing, design files, brand kits, marketing copy — anything where the work product is a file on your computer.
Claude Code is for the engineering. For shipping. For actual code, in a real project, with version control. Use it for the build phase — the parts that go to production.
Using Chat to write production code is leaving leverage on the table. Using Code for moodboarding is using a hammer to hang a poster.
Match the tool to the moment. The match itself is most of the skill.
The three rules are the structure. These are the texture — small habits that, after a year of doing this every day, separate the people who get a lot out of Claude from the people who get a little.
If something exists, paste it. Screenshots, code, references, voice samples. Claude is a master of imitation — not interpretation.
Start it, never restart it. Long context compounds. Each new turn builds on every previous one. Restarting throws away accumulated knowledge.
"Give me three different takes on this." Claude does best when it can show range. Pick the strongest — or combine the best parts of each.
Generate the output. Then ask: "What are the three weakest parts of this?" Then fix those. Two passes beat one, every time.
Chat is for figuring out WHAT to build — the spec, the architecture, the tradeoffs. Code is for building it. Don't try to do both in one tool.
When Claude hedges, demand a position. When it over-explains, say "less explanation." Train it to your taste mid-conversation. Don't be polite.
When you nail an output, save the prompt to a personal library. Reuse. Remix. Most great prompts are riffs on past great prompts.
Before shipping anything Claude wrote — copy, design, code — ask: would this fit at Linear? If no, iterate. Don't let "AI did it" be a quality excuse.
None of these are obvious on day one. All of them are obvious on day three hundred. The point of this talk is to skip you forward.
Because the boring middle of any project — the schema, the deployment, the integration — is no longer a wall.
Because "let me come back next Tuesday with mockups" becomes "let me come back in twenty minutes with mockups."
Because lockups, rules, components, documentation — all of that takes hours instead of weeks.
Because the marginal cost of polish dropped tenfold. Hover states, empty states, designed loading skeletons. All in.
The bottleneck is no longer time. It's clarity of vision.
If you're a designer — or you work with designers — and you're not using these tools the way I just described, you're competing against people who are. They're shipping five times faster than you.
The work doesn't get smaller because Claude got better. The work gets bigger — because the floor on quality rose for everyone. Now we compete on taste, on speed, on judgment. Which is what we always wanted to compete on anyway.
Thank you.