I was maintaining every engagement twice. My own notes said where a project stood, what I had promised and what the client still owed me. A Notion page said the same things for the client. By the end of most weeks, the two disagreed somewhere.
None of that upkeep was difficult, but it grew with every project. It set how many engagements I could hold before I stopped trusting my own records.
One file, two readers
I replaced both copies with one markdown file per engagement. Its frontmatter holds the stage and a status note. Below that are the documents the client can open and the items still owed on each side.
A build step reads every engagement file and regenerates the data the client portal serves. The stage drives the portal's progress rail, the document list becomes the client's links, and the open items become their action list.
What it removed, and what it did not
In that version, the portal was not live to my edits. I changed the file, ran the extraction, committed and pushed, and the portal caught up when that build was published. Between an edit and a publish, the client could still see the previous state.
What went away was the second update. There was one place to change a status, and the client's view came from it. The AethrDesign case study shows the same record as part of TasteLed, where later automation builds on it.
Repeatable procedures
The record made a second change practical. Once every engagement had the same structure, I could write fixed procedures around it: onboarding a new client, generating kickoff questions, drafting a proposal and triaging client mail. Each runs the same way every time.
The benefit was consistency more than speed. I stopped re-deciding how to do work I had already done, and a new engagement started from the same shape as the last one.
The limit that remained
With less upkeep, more engagements became manageable. The limit moved to decisions.
Each project still needs a direction for its brief, a view on whether a first draft is heading somewhere useful and a judgment about when work is ready for the client. In TasteLed, two of those decisions are fixed gates: I review every specification before it builds, and the client approves the staged site before launch.
That limit does not rise when tools improve. It depends on how many projects I understand well enough to make good decisions about.