The AI-native design stack: what actually ships client work in 2026
A practical look at the tools, models, and pipelines that now sit inside production client work — and the ones that don't make the cut.
AI is now production infrastructure, not a demo. Every client site we ship touches three or four models, a half-dozen tooling layers, and a human review gate at each step. The stack below is what made it through a year of real client work.
Foundation: Astro, Tailwind, TypeScript
The site itself is boring on purpose. Astro 5 for static output, zero JS shipped by default, islands only where they earn their weight. Tailwind 4 via the Vite plugin. TypeScript strict. Content in Zod-validated MDX and YAML, no CMS.
Boring infrastructure is what lets AI tooling run wild without breaking production. Every AI-generated asset lands in a typed collection, gets validated at build, and fails loudly if a frontmatter field drifts. Without the guardrails the speed gain from AI collapses into debugging.
Image generation: Gemini for source, Sharp for delivery
We use Google Gemini 2.5 Flash Image for generation. It wins on prompt adherence and on getting product and lifestyle shots that feel directed rather than stock. Midjourney produces prettier output in isolation but loses when the brief is specific — a product on a specific surface with specific lighting that matches a specific brand palette.
Generation is step one of three. Step two is human art direction: we treat Gemini output as source material, not final. A designer crops, color-grades, and composites. Step three is Sharp at build, producing AVIF and WebP at six sizes per asset, served from the same origin as the site. Third-party image CDNs add latency and cost without buying anything the build pipeline can’t already do.
Writing: Claude for drafts, human for voice
All long-form copy on client sites runs through Claude for first draft and structural editing. Claude is the best at holding a brief and a voice guide at the same time without reverting to generic agency-speak. GPT-4.1 is better at raw reasoning but worse at voice preservation. For marketing copy, voice is the product.
Every draft still goes through a human editor. The human pass is where brand voice actually gets enforced — Claude can mimic a style guide but it can’t tell you when the sentence is boring. That judgment is still the writer’s job.
Design-to-code: Figma MCP, not generic exports
We use the Figma Model Context Protocol server directly. Claude reads design context through the MCP, pulls component structure, tokens, and screenshots, and produces Astro components that match the spec. This replaced the old workflow of screenshotting Figma frames and pasting them into an AI chat, which lost half the metadata on every handoff.
The MCP approach is not automatic. The AI-generated component is a reference, not final code. A developer adapts it to the project’s existing patterns and component library. What we get is roughly a 3x speedup on converting a new design to working components, not a 10x. Anyone selling you 10x on design-to-code is measuring wrong.
Content pipelines: typed collections, not CMS
Every site runs on Astro content collections with Zod schemas. Adding a blog post is a new MDX file in a folder. Adding a case study is a new entry in the projects collection. The schema rejects malformed entries at build, which means an AI-generated draft can’t deploy broken content — the build fails first.
We evaluated Payload, Sanity, and Contentful and rejected all three. Each one adds a database, an admin UI nobody wants to maintain, and a runtime dependency that defeats the point of Astro’s static output. For sites where content volume is hundreds of entries, not millions, the CMS is overhead.
Deploy and monitor: Coolify, Umami, SerpBear
Hosting is Coolify on Hetzner. Per-client cost is low enough that the savings over Vercel and Netlify pay for a month of retainer by the second billing cycle. Analytics is self-hosted Umami. SEO rank tracking is SerpBear. Uptime is Uptime Kuma. All of it runs on the same box as the site for small clients, separate for larger ones.
The point is ownership. Every piece of the stack is something we control, can export, and can move. That’s not ideological — it’s operational. Vendors change pricing, deprecate APIs, get acquired. A stack you own doesn’t.
What we don’t use
We don’t use Framer, Webflow, or Wix for production. We don’t use V0 or Lovable for final code. We don’t use generative UI tools that write their own component libraries on every page. These tools are fine for prototyping; they collapse at scale because the output is unowned and unmaintainable. If we can’t read the source, we can’t ship it.
More from the blog
The seven-day brand sprint: how we do in a week what agencies do in a quarter
A week is enough to rebuild brand, site, and launch assets if the process is designed for speed. Here's how the sprint actually runs, day by day.
Why your brand is losing to challenger competitors (and what to do about it)
Incumbent brands lose to challengers because their brand systems were designed for a market that no longer exists. Here's what actually needs to change.
Brand identity systems vs. logos: the shift every founder gets wrong
Founders keep buying logos when they need systems. Here's what the difference actually costs you in the year after launch.