TL;DR: Webflow opened its 2026 conference by calling code commoditized and design craft the differentiator. That is a budget instruction, not a slogan. Below is a launch budget for a new ecommerce brand at $60,000, costed the old way and the new way side by side, with development dropping from $25,000 to $5,000, photo and video doubling, and the change-order line going to zero because the marketer now makes the change themselves. The file that makes it work is DESIGN.md, an open format Google Labs published in April 2026 that lets a coding agent read your visual identity instead of guessing at it. Also here: what you still need a developer for, exactly where in the ninety days they show up, and a short prompt to find out what your site's MCP can already do.
Every founder we work with has a website development line. For most of them it is the largest single item in marketing spend, and it has been sized the same way for a decade. A designer produces comps, a developer builds them, and the gap between those two events is where the money goes.
That gap is closing fast, and it closed in public last week.
Webflow used its conference keynote to say that with the ability to write code now available to anyone with an internet connection, the definition of builder has expanded from designers, developers and agencies to include marketers, and now agents. Their conclusion was blunt: as code becomes commoditized, craft and the teams who amplify it will be what sets the best brands apart.
We have been watching that arrive for two quarters. It is here now, and it changes what you should be buying.
Four things landed inside about seven days, and they matter together rather than separately.
Webflow shipped Source, where agents get direct access to the codebase with no abstraction layer in between, and the visual canvas writes to that same code. Agent Presence puts agents on the canvas alongside your team. Agent Instructions became a per-site context file, and Webflow will generate one from the content already sitting on your pages. Releases lets you branch an entire site, CMS and locales included, so a large launch stages together instead of shipping in pieces.
The Webflow MCP expanded into GSAP interactions, deeper CMS querying and Cloud deploys. The Shopify MCP has moved at a similar pace. Between them there is now enough surface for an agent to build, query and ship against a real commercial site rather than a demo.
Figma has agents writing Code Connect so that other agents read component names and props instead of raw styles. That is a semantic layer, and it is the difference between an agent seeing a blue rectangle and seeing PrimaryButton.
Underneath all of it, GPT-6 Astra and Fable 5.1 both arrived in the same week, each aimed at multi-step agentic work rather than conversation.
Put those together and the constraint on shipping a website stopped being whether someone can build it.
If a model can now design, iterate and scale a site without a developer in the loop, the quality of what it produces is set almost entirely by what you handed it before it started.
The clearest evidence for that came from an unlikely place. One creator published a video titled "finally kills AI website slop" about one frontier model, then published the identical claim about a competing model two days later. Both cleared two hundred thousand views. If the same superlative is true of two different models in the same week, slop was never a property of the model. Slop is what any model produces when nobody handed it a constraint.
So the spend follows the constraint.
Here is what that looks like costed out. A new DTC brand, first real site, Shopify, no existing assets. Same total either way.
| Line | Old way | New way |
|---|---|---|
| Brand guide | $10,000 | $15,000 |
| Web design | $5,000 | $10,000 |
| Web development | $25,000 | $5,000 |
| Photo and video | $10,000 | $20,000 |
| Engineering: payments, integrations, performance | folded into dev, invisible | $6,000 |
| Post-launch iteration and testing | $0 | $4,000 |
| Change orders and contingency | $10,000 | $0, absorbed in-house |
| Total | $60,000 | $60,000 |
Four notes on that table, including one place we would push back.
The development line is the headline, and $5,000 is defensible only with conditions. It works if you are on standard Shopify rails with a strong theme and the MCP wired up. It does not work if you have subscription logic, complex tax and shipping rules, a wholesale portal or a custom checkout. Which is precisely why we pulled engineering out into its own $6,000 line rather than pretending it vanished. Hiding real engineering inside a shrinking development number is how this goes wrong.
The change order line is the whole argument in one row. In the old model a $10,000 contingency is not pessimism, it is an actuarial certainty. Scope moves, a comp gets revised, the developer rebuilds, you pay again. Every founder reading this has signed that invoice.
In the new model that line goes to zero, and not because the change requests stop. They never stop. It goes to zero because the person who wants the change is now the person who can make it. The marketer who wants the hero rewritten, the PDP restructured or a landing page built for Thursday's campaign opens an agent against the site's MCP and does it. A two-week ticket becomes an afternoon, and it never becomes an invoice.
That is a relocation, not a saving. The work moves off a purchased line item and onto somebody already on payroll. Which is exactly the expansion Webflow described from the keynote stage: the definition of builder now includes marketers.
Two things have to be true for that row to hold, and both are already funded in the column next to it. The marketer needs the DESIGN.md, or what they ship will be off-brand within a week. And they need branching, or the first confident afternoon takes down production. The $15,000 brand guide and the $6,000 engineering line are not separate bets. They are what buys the $0.
The honest caveat: this only works if somebody on your team will actually open the tool. If nobody does, the change requests come back as invoices and you are now under-budgeted by ten grand. Before you commit to this column, get one person to say out loud that it is their job.
Brand guide going from $10,000 to $15,000 buys a different object now. Not a longer PDF. A validated, machine-readable file with a linter, which we will come to next. You are paying more and getting something that did not exist as a deliverable eighteen months ago.
The line we would question is web design at $10,000. Doubling design while the brand guide also goes up risks paying twice for the same thinking. In this model, web design should be scoped tightly to a component library plus five to eight page templates, and it should output templates rather than comps. If the deliverable is a Figma file of finished pages, you have bought the old thing at the new price.
Google Labs open-sourced the DESIGN.md format on 23 April 2026 under Apache-2.0. It is a format specification for describing a visual identity to coding agents, and it is worth understanding properly because it is more rigorous than the brand-book-in-markdown that most people picture.
The file has two halves. YAML front matter carries machine-readable design tokens: colors, typography, spacing, rounded, components. The markdown body carries human-readable rationale, section by section, in a fixed order: Overview, Colors, Typography, Layout, Elevation and Depth, Shapes, Components, and Do's and Don'ts. The tokens are normative. The prose explains how to apply them.
---
name: <brand name>
colors:
primary: "#..."
secondary: "#..."
typography:
h1:
fontFamily: ...
fontSize: ...
fontWeight: ...
lineHeight: ...
rounded: { sm: ..., md: ... }
spacing: { sm: ..., md: ... }
---
## Overview
## Colors
## Typography
## Layout
## Elevation & Depth
## Shapes
## Components
## Do's and Don'ts
That is the skeleton, and a real one is considerably larger than it looks. The spec notes that most design systems carry between nine and fifteen typography levels alone, and the components section maps token references onto every state of every pattern. A thorough DESIGN.md for a brand with a real identity runs to several pages, and the depth is the point.
Three details that make this materially better than a document:
It validates. npx @google/design.md lint DESIGN.md returns structured JSON: broken token references, missing sections, and WCAG contrast ratios computed for every color pairing. Your brand guide can now fail a test.
It diffs. npx @google/design.md diff DESIGN.md DESIGN-v2.md reports token-level changes and flags regressions. You can see exactly what changed between versions rather than trusting that someone remembered to say.
It exports. The token schema is built on the Design Token JSON spec, so it converts to and from Tailwind theme configs, Figma variables and W3C DTCG format. One file serves the website, the app and the marketing templates without re-specification.
The Do's and Don'ts section is the one to spend real time on, and it is the half people skip. A model given only positive instruction fills every gap with the category average. The prohibitions are what stop that. Be specific: no centered hero, no second accent colour, no stock photography of people at laptops, no generated imagery of humans, no carousel. "Avoid clutter" does nothing.
Two things worth knowing before you commit. The format is at version alpha and the spec, token schema and CLI are all under active development, so expect churn. And Webflow's Agent Instructions will now generate a version of this automatically from the content already on your site, which carries an obvious implication: whatever your site currently says about your brand is what your agents are going to believe about it. Audit first, then generate.
The full spec is linked at the bottom. Worth reading before you brief anyone to write yours.
This is where most writing on the subject gets dishonest, so let us be specific. The execution layer that compressed is presentational. Plenty did not compress at all.
Anything with real state. Authentication, payments, a database, a booking system that has to hold a lock on inventory. An agent can scaffold these. It should not own them.
Integrations that carry consequence. A form that posts to your CRM is fine. A checkout that touches money, or a data flow carrying customer records between systems, needs someone who can reason about failure modes and who is accountable when it breaks at 2am.
Performance budgets. An agent will happily ship a page that looks excellent in a screenshot and scores badly on Core Web Vitals, because nothing in the brief told it to care. Someone has to set the budget and enforce it.
Accessibility past the obvious. Contrast ratios are now linted by the DESIGN.md CLI, which is genuine progress. Focus order, keyboard traps, screen reader semantics on a custom component, and ARIA that is correct rather than merely present are not.
Migrations and redirects. The highest-risk website work there is, and the one place an autonomous agent can quietly destroy years of accumulated search equity.
Security review of anything an agent can write to. If an agent has deploy access, someone senior needs to have decided what it may deploy without a human, and that person should not be the same person who wrote the prompt.
Our rough split after reallocation is that engineering time drops by half to two thirds and gets more senior, not less. You are buying fewer hours of a better person. That is usually cheaper and always better.
Doing this in the wrong order is how it fails. The developer does not disappear from the timeline, they concentrate into one block and stay on call.
Days 1 to 15. Inventory and audit. Split the budget into decided, executed and genuine engineering. Audit the current site for the inconsistencies that would get baked into an auto-generated instruction file.
Developer: half a day. A technical read on the current stack, and a straight answer on what is actually custom versus what just looks custom.
Days 16 to 45. Build the brand system and the DESIGN.md. Including the Do's and Don'ts. This is the only step that genuinely needs a senior human eye, and it is where the reallocated money goes first.
Developer: half a day, near the end. Confirm the token schema exports cleanly into your stack, whether that is a Tailwind config or Shopify theme settings, and run the linter as part of sign-off.
Days 46 to 60. Wire it up. Connect the MCP. Configure branching so no agent writes to production. Define who approves what. Then ship one low-stakes page end to end, agent-assisted, and see what the constraint file actually produced.
Developer: two weeks, and this is the highest-value block in the whole timeline. Staging and branch protection, deploy permissions, the performance budget, the integrations, and the redirect map if you are replatforming. Do not compress this to save money. Everything after it depends on it holding.
Days 61 to 90. Shoot, then work the backlog. By now pages should be moving several times faster than they did in Q1.
Developer: on call. Reviews anything touching state, payments or customer data. Sits the rest out.
Four failure modes, all of which we have now seen.
Giving an agent write access to a live production site with no branch. This is exactly what Releases exists for, and it is the first thing to configure, before the first agent-assisted change rather than after the first incident.
Auto-generating your instruction file from a site that is already inconsistent. The generator faithfully encodes the inconsistency, and now it is authoritative.
Running auto-drafted copy in a regulated category. In health, finance or anything with claims substantiation, generated page copy is a compliance exposure rather than a productivity gain. Topic discovery yes, drafting into the CMS no.
Having no way to tell when the output changed. Two frontier models shipped in one week. Keep three reference prompts with a known-good and known-bad output per brand, and re-run them whenever anything underneath changes. With DESIGN.md you get half of this for free through diff, which catches token drift. The other half, whether the model still respects your prose, still needs your own reference outputs.
When every competitor can produce a well-designed page, the footage nobody else has becomes the moat, and it is the one input a model cannot manufacture. That is why photo and video doubles in the table rather than holding flat.
The arithmetic is better than people assume. One well-run shoot day produces roughly sixty to eighty usable stills and six to ten video setups. Worked properly afterwards, each still supports five or more crops and formats, and each video setup yields a hero cut, three social cutdowns and two ad ratios. That is around three hundred and fifty image assets and fifty video assets from a single day, against a generated hero image that every competitor in your category can also produce, from the same model, this afternoon.
Invest in the capture. Use AI on the stretch. That is the correct division of labour: humans and cameras for the thing that cannot be synthesised, machines for the thousand derivatives.
Before you budget any of this, find out what your site can already do. Most founders have an MCP available and have never opened it. Five minutes.
You have access to my website's MCP for [Webflow /
Shopify / other].
First, list every tool that MCP actually exposes.
Then give me 5 concrete things I could do with it this
week that would take a developer more than a day to do
by hand. For each one:
- what it does, in one line
- which tools it uses
- read-only or does it write to my live site
- roughly how long it would take
- what breaks if it goes wrong
Rank them by value to me, not by how impressive they
are. Put anything that writes to production at the
bottom and say what should be branched or staged first.
Ask me one clarifying question at a time if you need
more info.
Run it. The answer tells you how much of your development line is already automatable before you spend a dollar reallocating it.
The uncomfortable read is that the cost of producing a website is falling faster than the cost of deciding what the website should be, and everything downstream of a wrong decision is now cheaper to make and therefore far more abundant. You can generate forty variations of the wrong page in an afternoon.
Which is why the reallocation is not really from development to design. It is from execution to judgment. The brand book is where a company's accumulated taste gets written down in a form that survives a model release, a freelancer leaving, and an agency changing hands. Now that it validates, diffs and exports, it is closer to infrastructure than to a document.
Most founder-led companies have never written it down at all, which means their design judgment lives in one person's head while their execution budget pays to rediscover it every quarter.
Write it down and something else follows: the people who were previously filing tickets can start shipping. That is the real return on the brand guide line, and it does not show up as a saving anywhere in the budget.
That is the pillar worth building, and it is worth building before the next model ships rather than after.
If you want a second set of eyes on your own reallocation, book a call.
npx @google/design.md lint checks token references and WCAG contrast. Your brand guide can fail a test now.Product and operations are handled. If marketing is the missing piece, let's talk.