Building an operating system for a team of one

The problem

I had spent years building operating systems for product teams: planning cadences, lifecycle frameworks, knowledge systems, and the tooling around them.

Then I started running my own studio and lost all the scaffolding those systems quietly rely on.

The work included a website, blog posts, portfolio pieces, product listings, code, Claude skills, and eventually consulting work. Those things do not share a definition of done, but they were all competing for the same limited attention. The result was predictable: too many half-finished things, too much time deciding what to work on next, and a strong tendency for the newest idea to beat the thing that was already close to shipping.

A solo operating model also has an adoption problem that an organizational one does not. In a company, somebody is usually waiting on the other side of a gate. Alone, every gate is optional. I was the process designer, the user, and the person with complete authority to decide the process was annoying and quietly ignore it.

So I could not design for compliance. The system had to cost less attention than the friction it removed.

Designing one lifecycle for different kinds of work

I started with one shared vocabulary.

The lifecycle has six stages: Captured, Shaped, Drafting, Reviewing, Refining, and Shipped. Two additional states, Parked and Dropped, sit outside the main line as designed exits rather than failed work. A blog post, website page, Claude skill, piece of code, and consulting deliverable can all move through those same stages even though the work inside them looks different.

The most useful stage turned out to be Shaped. That is where an idea gets an audience, scope, definition of done, and enough thinking to decide whether it deserves a drafting session. It gives bad ideas somewhere cheap to die before I spend an evening making them look respectable.

Parked and Dropped both require a written reason. There is nobody auditing those decisions, but requiring a reason keeps the backlog from becoming a graveyard of things I technically still intend to do someday. Giving work a deliberate way out keeps the list honest enough that I still want to open it.

Making the human and AI boundary explicit

Claude is part of how I work, both interactively and through bounded autonomous agents. That made authorship and authority separate design questions.

Every lifecycle stage has a default working mode

• Solo is where the judgment needs to remain mine.
• Collaborative is me working with Claude in conversation.
• Autonomous is an agent executing a defined task inside explicit guardrails.

Capture stays Solo because the ideas are mine. Shaping and drafting are usually collaborative, while Reviewing is where autonomous agents are most useful because the checks are systematic and repeatable. Refining comes back to collaboration because deciding whether something actually feels right is still judgment.

For autonomous work, I also separated review from execution. An agent can identify an issue and propose a fix, but it does not apply that fix and then evaluate its own work. I make the next decision after I can see what it found and why.

Gates that compose across the work

The obvious approach would have been a different process for every deliverable type. That would also have given me seven processes to maintain, which sounds like an excellent way to spend all my time maintaining the system instead of doing anything in it.

Instead, I built three reusable gate sets

• Content gates cover voice, value, pillar fit, audience, brand alignment, and structure.
• Technical gates cover functionality, error handling, dependencies, security, code quality, performance, and accessibility.
• Agent safety gates cover scope adherence, stopping behavior, edge-case handling, and traceability.

Work pulls from those sets based on what it actually is. A blog post only needs content gates, a React component needs technical gates, a website page needs both, and agent work adds agent-safety checks. That lets me change a gate once without maintaining a separate version of the process for every deliverable type.

Turning the framework into a tool

I knew I was not going to keep checking a process document every time I sat down to work, so I built the tool that runs it. I wrote the framework on June 4, 2026, and by June 7 it was a password-protected React interface backed by Netlify Blobs, with local storage acting as a cache.

Inside the tool, stages became columns and each work item carried its type, pillar, next action, and last-touched date. Gate checklists were assembled from the item type and current stage, and an item could not advance until its applicable gates had been answered.

A daily log recorded what moved and whether the work was mine or an agent’s. The interface also surfaced the item closest to shipping, which means I do not have to reconstruct the state of everything before deciding where to start.

Designing for adoption

The framework was only useful if I kept using it. That meant designing around the predictable behavior of its only user.

The gate checklist makes not applicable a legitimate, recorded state. An irrelevant gate does not need to be quietly treated as passed just to make the checklist go away. Making the honest answer available matters more than making the checklist look complete.

The working cadence is intentionally modest: one 30 to 60 minute weekly session, a 15 minute monthly check, and a quarterly review of the framework itself. There are no publishing quotas. Progress is measured by work moving through the lifecycle, not by promising myself that Future Katerina will apparently become a content factory.

The weekly session starts with the item closest to Shipped. New ideas can still arrive, because realistically I was never going to design that behavior out of myself, but they go into Captured instead of immediately hijacking the session.

And the framework only gets redesigned during the quarterly review. Otherwise every bit of friction becomes an exciting opportunity to improve the process, which is suspiciously convenient when the alternative is finishing the thing already sitting in Reviewing.

Testing the system against itself

Three days after the pipeline went live, I ran the technical gates against the dashboard itself. The accessibility gate found contrast violations, and the brand-alignment gate found visual inconsistencies against my own design system. I fixed both.

That was the first time the framework caught something I might otherwise have left in a shipped tool, which was much more useful evidence than another clean pass. If every check comes back green forever, I do not actually know whether the gate is doing anything.

Extending without forking

Later, I needed a version of the process for portfolio case studies built from professional work. The constraint was confidentiality: I did not want employer files, screenshots, or exports moving onto a personal machine. I could have created a separate workflow for that work, but the existing structure was flexible enough to extend.

I added case-study-specific stages and a mockup approval gate. Before any final visual is built, I review a low-fidelity version containing the exact intended labels. Approval happens per visual, and silence does not count.

The final visuals are recreated from written descriptions rather than source material, so de-branding is part of the workflow from the beginning instead of something I have to clean up afterward. That let me add stricter controls for one kind of work without changing the core lifecycle or maintaining a second operating system.

What changed

One vocabulary became enough for very different work

The six lifecycle states now give me a consistent way to describe where work is, even when the deliverables themselves have little in common.

The distinction between Shaped and Drafting has been especially durable. Knowing which side of that line an item sits on tells me whether the next session requires thinking or making.

The framework became operational in three days

The written model went from document to running tool between June 4 and June 7.

That let the operating rules live in the interface instead of relying on me to remember them.

The quality gates found actual defects

Within the first week, the framework surfaced accessibility and visual-consistency problems in its own dashboard.

That was the first useful evidence that the gates were capable of producing signal rather than simply documenting intent.

The system supported later work

The lifecycle has since been used for this site, portfolio work, services content, case studies, and a personal Daily Brief application.

The Daily Brief moved from a Friday-evening specification to a live application pulling calendar data by Saturday morning. Its scope and definition of done had already been established in Shaped before implementation began.

Reflections

Some parts of the original framework have earned their place more clearly than others.

The stage vocabulary, designed exits, and composable gates are still useful every time I work. A few gates I wrote with great conviction have never caught anything. I have left them in place until the next quarterly review rather than changing the model reactively. If they continue to produce no useful signal, they should probably come out.

The human and AI boundary has also held up. The most useful rule is still separating review from execution. An autonomous agent can flag an issue and propose a fix, but the next decision does not automatically belong to the same agent that made the change.

And the weekly cadence has survived largely because starting it is cheap. I do not open the system and immediately face a blank question about what I should do with my life. The tool already knows which item is closest to shipping.

The project started as a way to bring the operating-system work I had done with teams down to a scale of one.

At that scale, there is nowhere for unnecessary ceremony to hide. If a rule makes the work easier to understand, finish, or evaluate, it stays. If it only makes the process look more complete, eventually it has to earn its way back out.