Framer approved me as an official Expert on 7 April 2025. Four months later, I began moving the productized builds in my practice to code. That work now ships as TasteLed, where a client's structured brief becomes a specification, a build and a staged site.
The move was about the medium, not about leaving a tool I knew well. aethrdesign.com is still a Framer site. What changed was where the design intent for a productized build lives, and what can check it.
Where the decisions lived
On a Framer project in 2025, a design decision lived in a document I edited by pointing at it. Framer already supported code components in React and TypeScript, and I had built many. The page around those components was still something I arranged on the canvas.
That worked while I was the person making each change. It worked less well once a model was producing the first build from a brief. There was no page file to version, no diff to review line by line, and nothing that failed when a section was missing required content. A wrong decision looked just as finished as a right one.
A specification with two checks
In TasteLed, the build starts from a JSON specification. A schema defines which sections exist and what each accepts, and the specification is compiled into a typed Next.js codebase.
Those two steps reject different mistakes. The schema rejects an invented section type before any file is written. The compiler rejects a real section with missing props, and names the file and line. Both failures are ordinary and reproducible, which is what I needed from a process a model would run.
Writing that format was design work. I decided that a services section takes a heading, an optional subheading and a list of items, that each item may carry an icon, and that an unknown icon name falls back to a set default instead of failing. On the canvas, I used to make those choices by arranging rectangles and then explaining them to a developer. In the specification, they are written once and checked on every build.
The pipeline changed while projects shipped
The move happened inside a pipeline that was already delivering client sites. All nineteen of my delivered client websites came through it as it matured. Earlier projects ran on a less mature version of it, and not every intermediate version was recorded.
Maxematics shows the change. Structured intake gathered the business context, AI produced the high-fidelity MVP we iterated from, and AI implemented each round of feedback while I set direction and reviewed it. The current product keeps two human decisions: I review the specification, and the client approves the staged build. The AethrDesign case study covers that process in full.
Framer stayed useful
The tools did not stand still. In June 2026, Framer published a command-line tool for connecting AI agents to Framer projects, and I use it. The limitation I described above belongs to the period when I made the move.
The split between the tools stayed anyway, because it was never only about automation. For work where I am deciding at every step by looking at the result, direct manipulation on a canvas is still the faster instrument. For a build that starts from a brief and has to be checked before anyone reviews it, a versioned specification is the better medium. Custom work goes wherever it fits, which is why the Maxematics rebuild is code and my own practice site is not.
What carried over
The Framer years taught me what a small-business page owes its reader: which sections it needs, how much a hero can carry, and when a testimonial is evidence rather than decoration. Those judgments now sit in a specification format that does not depend on the tool where I learned them.