Somewhere in the last year the shape of my week changed, and it took me a while to describe it correctly.
The easy description is that I got faster. That's true, and it's the least interesting part. What actually changed is how many separate things I can have open at once without any of them quietly rotting. A design practice. An embedded seat on a client's growth pod. This site. A public repository of my own tools. A year ago that list would have been one live item and a lot of guilt about the rest.
The reason isn't that making things got faster, although it did. The thing that had been capping me was never the making.
The work that never appears on a timeline
Every engagement carries a second job underneath the design work. Where does this project stand today. What did I promise on Tuesday. Which version is the one the client actually has. Where does the handover live, and does it still match what shipped.
None of that is hard. All of it is constant, and it's the part that decides how many engagements a person can hold. Design work has a natural stopping point. Bookkeeping doesn't — it just accumulates in the background until you stop trusting your own records, and then you slow down to protect yourself from being wrong in front of a client.
So that's the first thing I moved.
Every engagement now lives in one markdown file: stage, status note, the documents the client can open, the items still owed on both sides. A build step reads all of those files and regenerates the dataset the client portal serves. What the client sees is a render of my working notes, not a second copy of them kept in sync by hand.
I want to be exact about how automatic that is, because it isn't. I write the file, I run the extraction, I commit and push. What it removes is the drift, not the labor. The version before this lived in Notion, and every status existed in two places that disagreed by Thursday.
Around that sits a set of fixed procedures I wrote for the rest of it: onboarding a new engagement, generating kickoff questions, drafting a proposal, triaging and answering client mail. They're eight of the fifty-six agent skills I run — thirty I wrote, twenty-six installed, thirteen of mine published under MIT. The value isn't in any one of them being clever. It's that the same job runs the same way the second time, so I stop re-deciding how to do something I've already done.
None of that is design. All of it is what made design feel like it had a hard limit of one project.
Where the extra width is real
The pattern that works is boring: hand over raw material and enough context, get back a structured first pass, then spend my time arguing with it.
A data dump from a developer, a link to the designs, notes on what each screen is supposed to do, and a plain statement of what I'm trying to achieve. What comes back is a screen flow, an inventory of every field with its type, and a first attempt at the rules for which content appears when. It is always wrong somewhere. Some of it misreads what a field means; some of it invents importance for data I never intended to surface.
That doesn't matter much, because arguing with a wrong draft is a completely different activity from staring at an empty document. The wrong draft tells me what questions I hadn't asked yet. And what I end up with by the end of the day is a document the whole team can work from, which used to be a week of work I'd have been proud of.
And where it isn't
It extends me where I can already tell good from bad quickly. Nowhere else.
The typography on this site took six rounds of prototypes across two months. Almost every reaction I had turned out, once measured, to have a cause other than the obvious one — the face I thought was too small was actually too dense, the one I thought was unfamiliar set at exactly the same width as the familiar one. No amount of generated options would have shortened that. The work wasn't producing candidates. It was building enough calibration to choose between them.
That's the honest boundary. Breadth follows judgment, and it doesn't substitute for it. Ask for width in a domain where you can't evaluate the answer and you don't get width, you get volume, plus a confident tone that makes the volume harder to check.
Which is why the productized end of my practice — where a structured brief compiles into a deployed site — still has two gates I refuse to remove. I read and edit every spec before it builds, and I review every build before a client sees it. Not because I distrust the pipeline. Because those are the two points where its confidence and mine come apart.
The part nobody warned me about
Take away the production tax and what's left is deciding, all day.
That's a different kind of tired. Making has a rhythm to it, and some of the hours are quiet. Deciding has no quiet hours. Every thread comes back holding something that needs a verdict, and the threads don't take turns.
So the ceiling moved rather than disappeared. It used to be hours. Now it's how many things I can hold well enough to have a real opinion about, and that number is smaller than I'd like. It also doesn't improve when the models do.
The job I have now is less making and more deciding what's worth making, in what order, and whether the thing that came back is any good. That's a narrower job than it sounds like. It's also the only part of it that was ever mine.