AethrDesign: One file per client, and the delivery system that turns it into shipped work.

One person can carry team-shaped scope, and it survives contact with a real team.

The ground under digital product work has shifted. The parts of an engagement that used to demand headcount — production design, front-end build, revisions at volume — are exactly the parts AI now executes well, if someone architects the context it works inside. That someone is the new job. AethrDesign is my working test of that argument: one person carrying an agency's full surface (positioning, design, engineering, client operations) by directing AI through every build and keeping human judgment at the points where it actually matters.

The easy version of that claim is that the leverage replaces a team. It doesn't, and I'd stop believing my own argument if it did. The harder and more useful version is that the leverage travels: the same way of working that lets one person run an agency also lets that person hold a seat inside an engineering org at a scope the headcount wouldn't otherwise buy. Since August 2026 I've been embedded on the growth pod at Arca Wealth — a venture-backed fiduciary wealth manager with its own designers and engineers — working assigned tickets on their board, in their Slack, from a production fix in their Framer codebase to a site-wide type system to the first-year client experience itself. Not a project I scoped and handed over. A seat, ongoing.

This study is organized as evidence, not memoir. The claims in it are countable and inspectable: repositories you can open, sites you can visit, analytics I own the instrument for, and deliverables running live in this page.

Below is the first one. These four cards are not a recording of the deliverable. They are the shipped "How Rets Works" animation set I delivered to Rets AI, the same vector files the client's site serves, playing here through their own runtime. Click one and it pauses. A screenshot can't do that.

Hand-built on Framer, twelve weeks at a time.

Before the rebuild, AethrDesign worked the way most small studios do. Every site was hand-built in Framer, and a full engagement — discovery, design, build, launch — ran on the order of twelve weeks. The business itself lived across Notion and Google Drive: client portals, kickoff checklists, deliverable trackers, handover docs, each maintained by hand.

That operation was real and it worked: clients across SaaS, e-commerce, creators, and professional services, an approval as an official Framer Expert in 2025, and posted public pricing rather than quote-on-request. But every part of it scaled with my hours and nothing else.

I build my own instruments, and iterate on them the way I iterate on client work.

What makes the practice AI-native isn't that AI writes code. It's that the operation itself is tooled. I run a 56-skill agent operation: 30 skills I authored, 26 installed from the ecosystem, with 13 of my own published open-source under MIT. Each skill is a deterministic, versioned procedure, and the value isn't the prose: it's that the same job runs the same way every time. The whole graph is visualized interactively in my lab.

The part the public repository deliberately withholds is the AethrDesign lifecycle cluster: eight private skills that carry a client from first contact to handover: onboarding, kickoff questionnaires, proposal generation, client email drafting and triage. Those skills produce real client-facing artifacts, and the section after this one opens one of them.

This study was itself produced by that tooling. The map below is the actual planning graph the work ran on: twenty-one tickets orbiting one destination, worked one decision at a time.

The client's portal is a render of the file I keep the engagement in.

Every engagement lives in one markdown file. Stage, status note, the documents the client can open, the items still owed on both sides: that file is what I work from, and it is the only place any of it is written down.

A build step reads all of those files and regenerates the dataset the portal serves, so what a client sees is a render of my working notes rather than a second copy of them kept in sync by hand. None of that is automatic in the sense the word usually carries. I write the file, I run the extraction, I commit and push. What it removes is the drift, not the work: the Notion portals earlier in this study were the previous version of the same job, and every status lived in two places at once.

Below is one engagement, both halves. The frontmatter's stage drives the progress rail. The Documents list becomes the client's links. The todos become their action items. The page on the right is a real client portal, frozen mid-engagement at the date this study describes and served without the access token the live route requires, so you can open it yourself. That engagement has since closed; the snapshot is kept at the stage that shows the rail doing its work.

The part where AI does the work, and the two gates I kept.

For small service businesses, I productized the build itself as TasteLed: a $500, one-time tier where a structured brief becomes a deployed site. The machine is a spec-driven assembler: a JSON spec validated against a schema, compiled into a typed Next.js codebase, built and deployed through standard staging.

The middle of that pipeline is built and verified; the intake and QA ends are still process I run by hand, wired to tools that already exist. I've deliberately kept two human gates: I read and edit every spec before it builds, and I review every build before a client sees it.

What makes the machine trustworthy isn't one validation layer, it's two, each catching what it's actually good at. The schema knows what a section is: hallucinate a section type that doesn't exist and the spec is rejected before it touches the codebase. The compiler knows what a section needs: omit a required field and next build names the missing props, the file, and the line. Neither gate duplicates the other's work, and both failures are reproducible on demand.

A machine isn't finished until real copy has been through it.

The sample specs all passed. The real brief didn't, and that's the point.

The first time the assembler ran actual client copy, a mission statement containing an ordinary double quote generated a syntax error and two of five pages failed to compile. Every sample spec had been quote-free, so the defect was invisible until real content arrived.

It's fixed, and it permanently changed how I judge the tier. A testimonial, a quoted phrase, the most ordinary content a small business has: that is the real test suite.

The run below is the full pass on the Maxematics brief: five pages assembled from one spec, TypeScript green, nine routes prerendered.

One brief, three levels of autonomy.

Maxematics — a private tutoring practice — is the same brief resolved at three levels of machine autonomy, and the clearest picture of how the tiers relate.

v0 is the assembler's own output: the recorded run above, competent and correctly themed, kept local as the machine's benchmark. v1 is the $500 TasteLed build: hand-directed AI, custom-coded, and the site the practice ran on until the rebuild replaced it. v2 is where the engagement went next: the client upgraded to a bespoke rebuild with a branding revamp, including a focused logotype study whose recommendation they approved in August 2026. The rebuilt site went live at maxematics.org on 12 August, replacing what the practice had been running on.

A client who bought the entry product and grew into bespoke work is the tier structure doing exactly what it was designed to do. The engagement closed in August 2026 and the work is still moving: a motion pass is built and waiting on my review, and a visual-direction round is still open with the client. Delivered is a date on a stage log, not the end of the file.

The design that shipped was chosen by comparison, not by preference. Each candidate cut is generated from the same template.html and content.json as the production page, so the copy is identical across all of them by construction and exactly one design variable moves: one cut changes the footer, one introduces the light-bulb motif, one recomposes the first screen around it, one swaps the rendered bulb for a photograph. A comparison where two things move at once cannot tell you which one you are reacting to.

The client did not pick a version. They picked the photographic hero from one cut and the footer from another, and both were promoted into the template — so the page that shipped is none of the candidates. The cuts are frozen on staging rather than deleted, because a comparison is only auditable if you can still see what lost. The result is a static hand-built page: on 26 August it measured 99 on desktop and 91 on mobile for performance, with 100 in accessibility, best practices and SEO. It is a public URL, so that is re-runnable by anyone.

The branding work is where the practice's client-facing method is most visible. Rather than sending a grid of logo options and asking which one feels right, I ship the decision as a document: the question restated, the constraints that actually bind it, every treatment rendered at the size it will really be used at, and for each one what it achieves and what it costs, including the options I don't recommend. The client answers one question instead of adjudicating ten.

Assigned tickets, in someone else's codebase.

Arca Wealth is a venture-backed fiduciary wealth manager: Series A, $64M raised, twelve to fifteen people including eight engineers. Since August 2026 I've held a design-engineering seat on their growth pod, contracted through AethrDesign, with an @arcawealth.com address and tickets assigned to me on their board. Their marketing site runs on Framer, and the work arrives the way work arrives anywhere: a backlog item with a section, a type, and a status I don't set.

That backlog is the most honest description of the role I can give. Six items spanning a production bug in the hero, a site-wide design-system audit, blog SEO structure, a new services module, an inline lead-form test, and paid landing pages: front-end engineering, design systems, content strategy, and conversion work on one board. It is the reason the contract says design engineer rather than designer or developer.

The first ticket was a load bug that had resisted several attempts. On a cold visit — worst in incognito — the homepage hero exposed its flat fallback fill before the image finished decoding, then snapped in.

The diagnosis was the part that mattered: it wasn't a broken image URL, it was a load-order and compositing problem. Five layers render independently — background fill, hero image, dark overlay, typography, and Framer's own mount lifecycle — and each became visible on its own schedule.

The fix is a scoped React override on the hero. It gates the reveal on two conditions — the hero image finishing decode, and document.fonts.ready resolving — and holds the unfinished composition under a brand-dark veil until both land, fading it away over roughly 680 milliseconds.

The two escape hatches matter more than the effect. Anyone who prefers reduced motion gets the hero immediately, and a 2.2-second fail-safe guarantees it can never stay blocked waiting on a resource that never arrives. Every font declaration and the global navigation are left untouched: an earlier fix for font streaming was already in place, and degrading it to fix the image would have traded one bug for another.

It shipped, with a written technical handoff, so the next engineer inherits the reasoning rather than the patch.

The second ticket was a design-systems job on a codebase I didn't build. The site had been made fast and through many iterations, and had accumulated 248 exact typography permutations with almost no shared styles behind them.

I audited it, proposed the consolidation, and migrated it: 17 semantic text styles — twelve core roles and five for CMS article headings — now carrying 3,711 direct references across live pages, reusable canvas components, and four custom code components, with 93.8% of live, non-archive text moved onto shared styles. A second pass removed 42 redundant presets the first one had left behind, taking the text-style panel from 59 down to 17.

What was not touched is the more useful half. Palette, spacing scale, grid, navigation, motion, and copy were declared out of scope and left alone; ten trial-italic instances were kept as approved exceptions rather than bulk-replaced.

Then it went through their review, not mine. A stakeholder compared production against the staged branch at roughly a 900-pixel breakpoint and came back with nine specific corrections: badge alignment, heading sizes, an inverted text style for advisor profiles. That round is the part I'd point at first: inside someone else's system, the acceptance criteria are theirs.

The ticket that isn't a website

The clearest sign of what an embedded seat actually buys is the one non-web item on my plate: a proposal for the first-year client experience. It maps the cadence of touchpoints a new client receives over their first twelve months — which are a call, which are a note, and which the firm's own agent should drive without an advisor touching them.

That is service design, not web design, and it only reaches me because I sit on the pod rather than delivering a site from outside it.

Three of six are blocked

Half the board is stalled, and not on engineering. The SEO strategy, the How It Works outline, and the lead-form design each read {{{MISSING}}} in the ticket where the input should be.

I'm leaving that visible on purpose. A clean list of completed items would be a less honest picture of this job than a board with three items waiting on someone else, and none of it is work I scoped, priced, or could have chosen, which is exactly the test.

The argument in this study was never that one operator replaces a team. It's that the way of working holds when the team is someone else's — and that it started in engagements I did scope, which are below.

The proof, across three disciplines.

Three engagements carry the range: a SaaS product's motion system, a creator's conversion platform, and an e-commerce brand's storefront.

Rets AI: motion as product explanation

Rets AI abstracts commercial leases into structured data. For a product whose value is a workflow, the marketing site's job was to make that workflow legible in seconds, so the centerpiece became the four-step "How Rets Works" sequence: one continuous narrative from template selection to export, built as four coordinated animations. That's the set running live at the top of this page; below is where it ships in the wild.

A creator site that became a conversion platform.

Ruri Ohama is a YouTuber with 1.47M subscribers; the engagement rebuilt her web presence around selling her Kaizen System productivity product. My role was visual design plus the AI-assisted business side — positioning, page structure, conversion flow — over a twelve-week engagement in 2025.

This is the one client outcome in this study backed by an instrument I own: the site's Google Analytics property runs on my account. From September 2025 through May 2026 it recorded 54,000 active users and 108,000 new users. Her investment paid for itself many times over. Here's the traffic, and here's her saying so.

Platform range: Shopify, developed like software.

Live Love Pop is a healthy-snacking brand whose storefront runs on Shopify. The engagement was theme development done with a local CLI toolchain: versioned, previewed, and shipped like any other codebase rather than edited live in an admin panel. It's the smallest unit in this study, and it's here for exactly that reason: the practice's range runs from vector motion systems to e-commerce plumbing without changing how the work is run.

What I hand off changed.

The compression is personal, not mechanical. Engagements that ran twelve weeks when everything was hand-built now run one to four, and the cause isn't the pipeline. It's that I got better at directing AI: tighter briefs, better context architecture, faster judgment about what to accept and what to redo. The machine section above automates one tier; the capability curve belongs to the operator.

The clearest artifact of that shift is the handoff itself. I used to annotate Figma canvases for a developer: screen labels, dev notes, ready badges, a vocabulary built for a human reader. Now the densest document in the practice is a 284-line spec format written for a model to read: constraints, vocabularies, prop contracts. Same job, transferring intent without loss. Different reader.

A TasteLed customer has already come through: Maxematics bought the $500 tier, and v1 above is that build. What hasn't shipped is the machine's own output — the automated run stays the local benchmark it was recorded as, not a client's site. I could have left that distinction out; the study is stronger with it in. The argument here was never that automation has already replaced the team. It's that one person, directing AI with judgment and keeping the gates that matter, can now do team-shaped work at agency quality. Everything above is that argument, running.