I ship a production marketing site from brief to live in three to five business days. Daily previews. Lighthouse 95 or better in every category before the first deploy. Structured data that validates. Indexed within hours of launch.
This is not a recipe post. The recipe would not help you much anyway, because the parts that make it work are decisions, not steps. What follows is the reasoning: what I standardized, what I refuse to hand to a model, and what this way of working is genuinely bad at.
Speed is a stack problem, not a corner-cutting problem
The usual framing is "fast or good, pick one." For marketing sites that is wrong, and it is wrong in a specific way. Most twelve-week site builds are not more careful than a five-day one — they are more coordinated. The weeks go to alignment, not to substance. Take the coordination out and the calendar collapses without anything being cut.
The corollary matters more than the claim. If you compress the schedule without changing the stack or the tooling, you do ship something worse. You have to change the inputs first; the calendar is downstream of them.
One stack, decided once
Every site I build uses the same primitives. There is no "let me research the right stack for this client" phase, because the answer is already settled.
- Next.js 16 App Router, static by default. Nothing renders dynamically unless it has to.
- Tailwind CSS 4 with a CSS-first theme block. Design tokens are CSS variables, so a new brand is a variable swap rather than a refactor.
- TypeScript strict, with Zod at every boundary where data enters the app. A typo in a content file fails the build instead of the page.
- Vercel for hosting, with production behind a deliberate promotion step rather than an automatic one.
- Content as typed modules in the repo by default. A CMS only when a non-engineer has to edit without me.
- No animation runtime, no icon package, no extra webfont. Each of those is something I have to argue my way past, and most of the time the argument fails.
None of this is exotic, and that is the point. The stack is the slowest thing to change and the easiest thing to standardize. Decide it once and you stop paying the decision tax on every project.
How a week actually goes
Three beats, in order, and the order is the part that matters.
Agree on the thing before building any of it. Who it is for, the one claim the site has to make, what has to be integrated, what the deadline actually is. Written down and confirmed. Nearly every blown timeline I have watched — mine included — traces back to skipping this and discovering the disagreement in week three, when it is expensive.
Get something clickable in front of the client early. Not finished. Clickable. Real routes, real navigation, rough copy, responsive on a phone. A client's reaction to a live preview is worth more than their reaction to ten pages of spec, and it arrives early enough to act on. If there is nothing to click by the middle of the build, the scope is wrong, and I would rather find that out then than at the end.
Everything after that is subtraction. Copy tightens, images get smaller, the layout stops fighting itself. This is where the time saved earlier gets spent, and it is the part clients actually notice.
Then the checks. Then live.
Where AI helps, and where I do not let it
Building something like this? Let’s talk →
Claude Code is my editor. It does not reliably write better code than I do. What it does is collapse the distance between deciding something and it being done: I describe a change, the right files get edited, the tests run. My attention goes to the decisions instead of the typing.
A handful of MCP servers do the reaching: Playwright for real-browser testing and accessibility trees, GitHub for pull-request work, Vercel for deploys and logs, Firecrawl when I need a site's actual content rather than my memory of it, an image pipeline for conversion and dimensions. The model orchestrates them. I say what I want at the level of intent.
For anything expensive to get wrong — architecture, a security boundary, anything a client will be held to — I get a second read from a different model family. Not a second run of the same model, which mostly agrees with itself. A different model family was trained on different things and misses different things, so it catches what the first one walked past. When the two disagree, that is the signal to slow down and look properly.
Three things never leave my hands:
- Architecture. Whether auth is a managed service or my own, where state lives, what is a build-time concern and what is a runtime one. These have consequences a model cannot see from inside a single prompt.
- Voice. Every sentence a visitor reads goes through me. The model drafts; I rewrite. A site sounds like one person because one person wrote it.
- Ship or hold. A model can tell me a page passes. Whether a site is ready to carry a client's name is not a metric.
The checks, which are not negotiable
The same checks run before every launch, and any one of them failing stops it. They are written down rather than remembered, because "good enough" creep is the default state of every project and memory is where standards quietly erode.
- Lighthouse 95 or better in every category on mobile, with accessibility and SEO at 100. Below that is a blocker, not a note.
- Structured data validates in Google's Rich Results Test. A page that does not validate does not ship.
- Accessibility: contrast, focus order, landmarks, form labels, alt text on every image.
- Every internal link resolves, and no page renders an error state on a normal path.
- No placeholder text, no lorem ipsum, no leftover model output. This one sounds too obvious to write down. It is on the list because the list has caught it.
The checks are also why five days is not reckless. Without a floor it would be. The bar underneath the schedule is the thing that makes compressing the schedule safe, and the bar is not up for discussion on a busy week.
Search is part of the build, not a phase after it
Most builds ship and then "do SEO." That is backwards: the first crawl is a crawl of the first deploy, and everything after it is remediation.
So the structure goes in from the first page. Semantic headings with exactly one H1. Schema types that match what the page actually is — an organization, a service, a place, a set of questions. Metadata and a canonical on every route. A sitemap generated from the routes rather than maintained by hand.
The newer half of this is writing for extraction. An answer engine quoting a page needs a passage it can lift: the question in the heading, the answer in the first few sentences under it, specifics instead of adjectives. That is the same discipline as writing a good opening paragraph, and it happens to be what makes a page quotable by a machine. Pages written that way read better to people too.
Submitting the URLs at launch is automated. Verifying them is not: I check that the canonical the site serves is the canonical it claims, on the live host, after redirects. That check is the subject of its own post.
What this approach is bad at
- Design that has to be unlike anything else. This way of working is fast at a well-made conventional site and slow at an unconventional one. If the brief is "nobody has seen this before," I am not the cheapest way to get there.
- Stacks that are not this one. Moving a site off WordPress is routine. Building a new one in PHP is not something I do.
- Long-lived applications with deep state. Marketing sites, directories and small products are the sweet spot. A complex multi-tenant backend is a different job on a different calendar.
- Consensus-driven teams. The cycle time assumes one person can decide. Add three approvers and the schedule is theirs, not mine.
- Onboarding someone into it. The conventions are dense and live mostly in my head and my docs. Ramp-up is real, and I would rather say so up front than let you discover it.
If you are trying to work this way
- Pick the stack and stop relitigating it. Every "what if we used X instead" is a context switch you pay for twice.
- Write the checks down as code. A standard that lives in your head is a standard that goes missing on a busy week.
- Use the model to skip typing, not to skip thinking. The moment you cannot explain why your own code is shaped the way it is, you have traded away the wrong thing.
- Get a second opinion from a different model family on anything expensive to get wrong.
- Expect the first few projects to feel slow. The compounding is real, but it is not immediate.
I'm looking for a remote role — AI automation, integration, or full-stack, full-time or contract. If your team wants someone who works like this, I reply within one business day.