On 7 April 2025, Framer approved me as an official Expert. Four months later I started rebuilding my practice so that a machine could do the building, and within a year the productized end of it had moved off Framer entirely — it now ships as TasteLed.
I want to be exact about the scope of that, because the tidy version is wrong. I didn't leave Framer. aethrdesign.com is a Framer site today, and so is a good deal of the bespoke work I'd actually show you. What moved was one tier: the productized build, where a structured brief compiles into a deployed site with no hand-authored pages in between.
The reason that one tier had to move is the part worth writing down, because it was never about whether the model was good enough yet.
A model can write a component. It couldn't write a page.
At the time, the assumption everyone around me was making — including me — was that going AI-native meant putting AI inside the tool you already had. Better prompts, faster iterations, same canvas.
Framer had a real code surface even then. You can write a code component in React and TypeScript, drop it onto a page, and give it property controls. I'd built plenty of them.
What the tool didn't have was a page you could write. A Framer project lives in a document you edit by pointing at it. There's no file on disk for a model to open, no diff to read afterward, and nothing that fails when the model gets it wrong. A code component is an island inside a page; the page itself was out of reach.
An autonomous build isn't blocked by the model's judgment. It's blocked by the absence of a place for the model to be wrong out loud.
What a machine needs is a boring medium
So the productized tier became code — TasteLed — and the design document became a file.
The build runs from a JSON spec validated against a schema and compiled into a typed Next.js codebase. Two things say no along the way, and they say no about different things. The schema knows what a section is: invent a section type that doesn't exist and the spec is rejected before anything is written to disk. The compiler knows what a section needs: omit a required prop and the build names the file and the line.
Neither of them is clever, and that's the qualification. I wanted the failures boring and reproducible, which is the opposite of what the canvas offered, where a wrong decision just sits there looking finished.
What I hadn't expected is that writing the spec format was design work, and a fair amount of it. Deciding that a services section takes a heading, an optional subheading and an array of objects; that each object may carry an icon; that an unrecognised icon name falls back to one specific default instead of failing the build. Those are the decisions I used to make by arranging rectangles on a canvas and then explaining them to a developer. Same judgments, different reader.
The full pipeline, including the two human gates I kept in it, is written up in the AethrDesign case study. I won't rebuild it here.
Framer caught up, and the split stayed anyway
Framer has since shipped an agent of its own: a command-line tool that edits pages, manages CMS content, writes code components and publishes deployments. It's installed on this machine and I use it. So the constraint I've just described — no file, no build, no failure — is no longer the whole truth about the tool.
The split survived that, which is how I know it was never really a tooling argument.
The bespoke tier is still Framer, still hand-built, and not as a hedge against the pipeline. Where a human is deciding at every step, direct manipulation is simply the faster instrument, and a canvas is the best direct-manipulation surface anyone has shipped for the web. Being able to point at a thing and change it is the correct interface for a decision you can only make by looking at the result.
Automatable and appropriate are different tests, and I had been quietly treating them as one.
What the expert approval actually bought
There's a version of this story where the approval turns out to be worthless: a credential in a tool the work has since walked away from. That isn't what happened, and the reason is a little unflattering to how I used to think about tools.
What the Framer years taught me wasn't Framer. It was what a page owes a reader: which sections a small business site genuinely needs and which ones are there because everybody has one, how much a hero can carry before people stop reading it, when a testimonial is evidence and when it's furniture.
Every one of those judgments is now written into a spec format that has nothing to do with the software that produced them.
Worth saying plainly: the machine's own output has still never shipped to a client. It stays local as the benchmark it was recorded as, and every site a client has paid me for went through a tier where I was deciding each step. The pipeline is real and it is not yet the whole story, and I'd rather hand you that distinction than let you infer the flattering version.
An expert in a tool is really an expert in a set of decisions. Those port. Not much else does, and I spent a while believing the reverse.