Building an operating system for a team of one
I spent years building operating systems for product teams. When I started running my own studio, I built one for myself, shipped the tool that runs it three days later, and found its first real defect in its own dashboard. Every piece of work since has moved through it, including this case study.
The setup
Building an operating system inside a company comes with scaffolding you stop noticing: a team, a mandate, a tooling budget, and other people whose job it is to tell you when the process has stopped working. I had all of that for years, and I built planning cadences, lifecycle frameworks, and knowledge systems on top of it.
Then I started building my own thing, and the scaffolding was gone.
The work was a website, a blog, a portfolio, product listings, a set of Claude skills, and eventually a consulting practice. Seven deliverable types with almost nothing in common. A blog post and a React component and an Etsy listing do not share a definition of done. They barely share a definition of started.
The failure mode of solo creative work isn’t a shortage of ideas. It’s a pile of half-finished things and no reliable way to tell which one is closest to shipping. Every session opened with twenty minutes of re-deciding what to work on, and the newest idea kept winning against the one that was almost done.
I had watched teams solve exactly this. I had never solved it for a team of one.
Where I came in
I was the whole org chart. The person who set the strategy, the person who did the work, the person the process was supposed to hold accountable, and the person who could quietly delete the process at any time with no consequences.
That last one is the real design problem, and it’s the thing most process writing ignores. In a company, a gate holds because someone is waiting on the other side of it. Alone, every gate is optional by construction. So I couldn’t design for compliance. I had to design for a person who could walk away from this at any moment and would, the first week that got hard.
Two more constraints shaped everything.
Energy is the scarce resource, not time. A system that costs more attention than the friction it removes gets abandoned, and abandonment is expensive, because it takes the good parts with it.
My main collaborator has no stake in the outcome. I work with Claude constantly, both in conversation and as autonomous agents. Claude is fast, tireless, and genuinely useful. It also has no independent judgment about what matters to me or where my voice lives. That’s not a complaint, it’s a requirement. The process had to say out loud where a machine decides and where I do, because if I left that boundary implicit I would drift across it on tired days.
What I built
Six stages and two exits
The six stages are Captured, Shaped, Drafting, Reviewing, Refining, and Shipped. Alongside them sit Parked and Dropped, which live outside the line and are first-class states rather than failures.
One vocabulary covers everything. A blog post, a website page, a Claude skill, a piece of code, and a consulting deliverable all move through the same six words, even though the work inside each stage looks nothing alike. Drafting a blog post means prose exists. Drafting code means a working implementation exists, not pseudocode and not an architecture sketch.
The most useful stage turned out to be Shaped, which is thinking rather than making. It’s where an idea gets a one-sentence summary, a specific audience, a scope, and a definition of done before anyone starts producing anything. It’s also where bad ideas get caught before they waste a drafting session. Most of what I killed, I killed here, cheaply.
Parked and Dropped both require a written reason. Not for auditing, since nobody audits me. A backlog with no exits becomes a guilt pile, and a guilt pile is a system you stop opening. Giving an idea a dignified way out is what keeps the list honest enough to look at.
Three operating modes
Every stage declares a default mode and answers one blunt question: can an agent operate here?
Solo is me alone. It’s rare in execution and non-negotiable for creative direction and voice. Collaborative is me working with Claude interactively. I set direction, Claude drafts or analyzes, I react and steer. Most shaping and refining lives here. Autonomous is a Claude agent executing a defined task inside guardrails and returning results for review.
Capture is Solo, because the ideas are mine. Reviewing is where agents earn their keep, since gate checks are systematic, rule-based, and exactly the work a tired human skips. Refining stays Collaborative, because “is this right now?” is a judgment call and I don’t want it automated.
The guardrails are explicit. An autonomous agent must have a defined scope, because “review this against all quality gates” is a task and “make this better” is not. It must return structured pass, flag, or fail output rather than handing back a silent rewrite, so I can see what changed and why. It must stop at its boundary and flag ambiguity rather than guessing. And it must never chain decisions: an agent can flag a problem and propose a fix, but it does not apply the fix and then grade its own work. Review and execution stay in separate passes.
Gates that compose instead of branching
This is the piece I’d defend hardest.
The obvious move is a process per deliverable type, and it’s a trap, because seven processes means seven things to maintain and none of them stay current. Instead there are three gate sets, and a deliverable pulls the ones it needs.
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.
A blog post runs content. A React component runs technical. A website page runs both, which is most of the interesting work. An agent runs technical plus agent safety. It stays one pipeline, with no forks per type.
The obvious move is a process per deliverable type, and it’s a trap. Seven processes means seven things to maintain and none of them stay current.
A cadence that assumes bad weeks
The rhythm is one weekly working session of thirty to sixty minutes, a fifteen minute monthly check-in, and a quarterly reflection where the framework itself gets revised, and not before.
There are no publishing frequency commitments anywhere in it. Not one post a week, not two listings a month. Those turn into pressure the moment life gets full, and pressure is what makes people abandon systems. The measure is whether work is moving through stages, not whether a volume got produced.
The session has a structure, and it’s biased toward finishing: open the pipeline, find the item closest to Shipped, start there. New ideas go into Captured and stay there. If everything is Parked, go shape something.
The instrument
A framework in a document is a wish. So three days after writing it, I built the tool that runs it.
It lives at /ops/pipeline on this site, password-protected, written in React, syncing to a Netlify Blobs backend with local storage as a cache so the interface stays fast and survives a lost connection.
Stages are columns. Every item carries its type, pillar, next action, and last-touched date. Gates render as checklists on the item, scoped to its current stage and assembled from whichever gate sets its type pulls. Advancing an item is blocked until its gates clear. A daily log records what moved, and it distinguishes work I did from work an agent did, which turned out to be the most interesting data in the whole system. The session rule is encoded as a nudge that names the item closest to shipping, so the tool asks the finishing question before I can start something new.
The adoption layer
I’ve watched enough process rollouts fail to know that the framework is the easy half. Adoption is the design problem. Being my own only user didn’t make that easier, it made the failure quieter, because the only person who would notice me quietly abandoning this was me.
Three decisions did the actual work.
The gate checklist is tri-state. Pass, fail, and not applicable. Two states would have been simpler and would have corrupted the entire thing, because a solo operator facing an irrelevant gate has exactly two options: lie to the checklist or stop using it. Making “not applicable” a legitimate, recorded answer is what keeps the honest answer available. This is a small interface decision that determines whether any of the rest is real.
The tool asks the finishing question, so I don’t have to. The bias toward completion isn’t a rule I have to remember and enforce on myself. It’s the first thing on the screen.
The framework revises itself on a schedule, not on impulse. Quarterly, and only quarterly. Otherwise every friction becomes a reason to redesign the process, and redesigning the process is a very satisfying way to avoid doing the work.
Then there’s the part I didn’t plan, which is that the first thing the gates caught was a defect in their own dashboard.
Three days after the pipeline tool went live, I ran the technical gates against it. The accessibility gate found contrast violations, and I fixed them. The brand alignment gate found visual inconsistencies against my own design system, and I fixed those too. The framework’s first real catch was a bug in the framework’s own instrument, in a thing I had just built and was pleased with.
That’s when I believed it. A gate that only ever passes your work isn’t a gate.
The system extended itself
The strongest evidence that the structure was sound came later, when I needed something it didn’t cover.
I wanted to build portfolio case studies from professional work without moving a single employer file, screenshot, or export onto a personal machine. That’s a confidentiality problem wearing a process costume, and the tempting solution is a separate side process with its own rules.
Instead the SDLC extended. I added a domain-specific pipeline for case studies with five stages of its own, and the control at its center is a mockup gate: no final visual gets built until a low-fidelity wireframe showing every exact final label has been reviewed and explicitly approved. Silence isn’t approval. Approval is per-visual, not per-batch.
The reason is economic. A confidential term is free to catch in a wireframe and expensive to catch in a finished graphic, and expensive things get rationalized past. So every visual is recreated from a written description rather than from source material, which makes de-branding the default state of the pipeline instead of a cleanup pass at the end. Nothing branded ever enters it.
Every visual on this page went through that gate.
Impact and results
The framework became an instrument in three days. Written June 4, 2026. Running, synced, and password-protected by June 7. The gap between “I wrote a process” and “the process runs” is where most internal frameworks die.
The gates found real defects in the first week. Accessibility and brand consistency violations in my own tooling, caught by the gates rather than by a user or by luck.
Everything since has moved through it. That includes this site, six case studies, the portfolio, the services page, and a personal daily brief app that went from Friday evening spec to a live app pulling real calendar data by Saturday morning, which happened at that speed precisely because the shaping work was already done before any code existed.
The vocabulary is the durable part. Months in, the thing I use constantly isn’t the dashboard, it’s the six words. Knowing that something is Shaped but not Drafting tells me what kind of session it needs and how much energy it will cost, before I sit down.
Reflections
The weekly session held, and the reason isn’t discipline. Voluntary cadences usually decay, and this one didn’t. What made the difference is that the session never asks me to make a decision at the moment my energy is lowest. It’s scoped to thirty or sixty minutes, and it opens with the tool telling me which item is closest to shipping. The cost of starting is close to zero, so starting stays easy on exactly the days when starting is otherwise the entire obstacle. If I were advising a team on cadence design, that’s the transferable part: protect the beginning of the session rather than the length of it. Most process design does the opposite and then blames the people.
Some of it was ceremony and the strip-down revealed which parts. Running a full lifecycle at a scale of one is an unusually clean experiment, because there’s no politics to hide behind. Anything that survived is load-bearing. The stage vocabulary, the composable gates, and the exits earned their place. A few gates I wrote with real conviction have never once caught anything, and I’ve left them in for now because quarterly is when that decision gets made.
Designing the human and machine boundary explicitly was the highest-value hour. Writing down which stages an agent may operate in, and what it must do when it hits the edge of its scope, took less than an afternoon and has prevented every version of the problem where you wake up to a confident, well-formatted, completely wrong artifact. The rule that has mattered most is the one about not chaining decisions. An agent that fixes a problem and then evaluates its own fix will always tell you it went well.
It is the same work, only smaller. Everything here is the work I’ve done for product teams, at the smallest scale it can exist at: name the stages, define done, decide who decides, make the right thing the easy thing, and build the instrument that makes the state of the work visible without anyone assembling it by hand. The scaffolding changes. The problem doesn’t.