Aethr Design: TasteLed turns a client brief into a website ready for review.

The product is the pipeline. The websites are what it produces.

TasteLed takes a client's brief to a website ready for their approval. A client configures their business details, content, reference direction and scope. The pipeline turns those answers into a specification, builds and checks the site, and stages it for sign-off. All nineteen client websites I've delivered came through this pipeline as it evolved, before it had the TasteLed name.

My design work is what makes that repeatable: what intake asks, what a specification may contain, what each check rejects and where a person approves the result. AI does most of the building. Across my own deliveries, engagements of similar scope now take three to four weeks, against about twelve when I built every site by hand.

Aethr Design carries the bespoke work from the same deliveries, and embedded engagements alongside it. In October 2026 I rebuilt its own site, aethrdesign.com, in code on the same system. Since August 2026 I've also worked inside Arca Wealth's growth team, where the same habits meet another team's codebase and review.

Every engagement started by working out the same decisions again.

Before TasteLed, I built each site by hand in Framer, and a full engagement ran about twelve weeks. Each one began with the same work: reading the client's requests and business context, then choosing a design direction. Most of that interpretation stayed in my head, so the next project needed me to work through it again.

The operations around the sites were hand-kept too. Each client had a Notion portal, and I kept my own notes beside it, so every status change was written twice. The practice could only grow as fast as my hours.

AI builds the site. I designed what it starts from and what it has to pass.

In this pipeline, directing AI means giving a model the same inputs, procedures and checks on every engagement. The quality of a build shouldn't depend on how one conversation happened to go.

It starts with structured intake. The brief replaces a discovery call: a client sets their business details, content, references and scope, and AI-led intake follows up on what is missing. The answers arrive in the shape the next stage expects, rather than as notes I have to interpret.

Each repeatable step, from intake follow-up to proposal drafting, then runs as an agent skill, so every new brief enters the same workflow.

The brief becomes a JSON specification before anything is built, and I wrote its format: 284 lines defining what each section accepts and requires. A services section takes a heading, an optional subheading and a list of items. Each item may carry an icon, and an unknown icon name falls back to a set default instead of failing. On a Figma canvas, I used to make choices like these by arranging rectangles and explaining them to a developer. Here they are written once and enforced on every build.

Two decisions stay with people. I review every specification before it builds, and the client signs off on the staged site before launch. Those are the two points where a model's confidence and mine can come apart.

The schema and the compiler catch different mistakes.

A specification is useful only if the build respects it. Before assembly, a schema checks the JSON and rejects section types the system doesn't support. After assembly, the TypeScript compiler checks the generated Next.js code and names missing required content by prop, file and line.

Real client copy tested the gates harder than the samples did. On the assembler's first run with an actual client brief, a double quote in a mission statement broke two of five pages; every sample had avoided quotation marks. Fixing the escaping solved the bug, and real client copy has been part of how I test the pipeline since.

The client portal renders the file I work from.

My earlier client portals were Notion pages, separate from my working notes. Moving a project forward meant updating both.

I replaced them with one markdown file per engagement. The portal reads the stage, documents and open items from that file, then renders a progress rail, links and an action list for the client. In the version shown below, I edited the file and ran an extraction step before publishing, so there was one record to maintain before TasteLed automated more of the process. The same record now feeds the proposal generator I use for bespoke engagements.

I moved aethrdesign.com off Framer and onto the same system.

In October 2026 I replaced the Framer site at aethrdesign.com with a static Next.js site on Cloudflare. It went live five days after the repository was created and brought the whole old site with it: 20 case studies with 89 fields each, 355 media files and every old address. A redirect map generated from the Framer export checks 73 old URLs on each deploy, so links already sitting in proposals, search results and client emails still land.

Agents did most of the building, as they do on client sites. I wrote the migration as a phased plan, each phase with success criteria it had to meet before the next began, and set the checks the site still runs. Every page is tested against the sitemap and its structured data before it ships. The case studies take their facts from the same engagement records the portal reads, and a deploy fails if any study on the site differs from its record, so a corrected date can't reach one surface and miss the other.

The contact page opens with a project scoper. A visitor describes the site they need, a model asks follow-up questions and points to similar case studies, then hands a summary to the inquiry form. Its knowledge base is generated from the site's own pricing, FAQ and case studies, and the deploy refuses to ship if any of those sources changed after the last build. A model will improvise a price if nothing stops it, so a probe sends adversarial questions to the live model and fails on any dollar figure the knowledge base doesn't contain, on a forbidden claim, or on a link it had to strip.

The home page embeds the real client portal, running on sample data that stays in the visitor's tab, so a prospect can step through a proposal, agreement and deposit before booking a call. The inquiry form posts to the portal as well, and the options it offers are a shared contract with a parity test.

Maxematics started with a site the client could respond to.

Maxematics, a private tutoring practice, used the pipeline from its original delivery. AI-led intake gathered the business context, then AI produced a high-fidelity MVP for the client to review. I set the direction and reviewed each feedback round; AI implemented every round of changes.

The engagement grew into a bespoke rebuild with a new identity. I generated candidate screens from the same template and content, changing one design variable at a time. That gave the client a specific choice to make: the photographic hero from one version, the footer from another. Both went into the shipped page.

The site went live at maxematics.org on 12 August 2026. A PageSpeed Insights check on 26 August measured performance at 99 on desktop and 91 on mobile, with 100 for accessibility, best practices and SEO on both. The identity study follows the logo work separately.

The pipeline kept changing after delivery. A later, recorded re-run of Maxematics verified the newer version through staging.

Other sites from the same pipeline, each with its own problem to solve.

Johnson Capital, Ruri Ohama and Rets AI came through the same pipeline with different demands: a firm with several services and audiences to separate, a creator's sales page built around one offer, and a SaaS product that needed motion to explain its workflow.

Ruri's site sells her Kaizen System productivity product. In a post-launch meeting, she told me her investment had paid for itself many times over.

Separately, the site's Google Analytics property, which runs on my account, recorded 54,000 active users and 108,000 new users from September 2025 through May 2026. Ruri also credits me publicly: one of her videos names me as her web designer and links to Aethr Design.

Inside Arca Wealth's growth team, my work went through their review.

At Arca Wealth, a venture-backed fiduciary wealth manager, I work within the client's growth team. I've been embedded through Aethr Design since August 2026, with an @arcawealth.com address, alongside Arca's designers and engineers. The team instruments its Framer site and tests landing-page variants as part of its campaign work.

Arca's lead flow sent visitors to a separate page with nine steps. I built a six-question form that sits directly on the landing page and connected its interaction states to Google Tag Manager. It shipped on the divorce-planning page. Its investable-assets question gave the growth team a useful signal: one keyword group was bringing in leads below Arca's minimum.

My contribution was the Framer implementation and frontend tracking support. Teammates coordinated the wider browser and server-side conversion tracking across Google Ads, Meta and LinkedIn; Arca's engineers own the form's backend logic. Together, those parts are designed to support optimization toward booked sales calls and preserve signals when browser tracking is blocked.

I also traced a first-load hero defect to its cause and shipped the fix, and consolidated 248 typography variations into 17 shared text styles. A stakeholder compared production with my staged branch and returned nine corrections, which I worked through on the branch.

The design work that mattered most here was not any single site. It was the set of decisions the pipeline now makes on every project: what to ask, what a section may contain, what to reject and who approves. Writing those down took more judgment than drawing a page, and it is why the sites come out consistently.

Real content is the test that counts. The samples passed and one client's quotation mark did not, so I judge the pipeline by the most ordinary copy a small business has. Arca applied the same habits inside someone else's team, where the acceptance criteria belonged to them.