Twelve months ago I committed to a weekly shipping cadence for a solo creative-tech practice. One plan day. Three build days. One ship and retrospect day. The output over twelve months: roughly 150 shipped items, a handful of case studies, most of this website's writing cluster, and an agent council skill I use daily. The cadence is not the output. It is the rhythm that made the output possible without burning me out.
What I shipped
The cadence is a fixed-shape week. Monday morning is planning. Tuesday through Thursday is build time with no meetings before noon. Friday is ship day and the week's retrospective. That's it. Saturday and Sunday are genuinely off, which took me about four months to take seriously.
The shipped output averages three items per week across the twelve-month window. An item is something a reader or a client actually received: a shipped article on this site, a pushed case study, a delivered client artifact, a published product page, a released Claude Code skill, or a book-length draft that went out for review. That's a deliberately fuzzy definition; the definition I tried first (a released production feature) produced weeks with zero counted output and weeks with ten, which masked the actual rhythm.
Variance is real. Some weeks hit five ships. Some weeks hit one. The median is three and the mode is three. That stability, not the peak weeks, is what I'm chasing.
What worked
The Monday plan block as the single decision point for the week. Before I committed to this, I was making planning decisions every day, which meant every morning burned an hour deciding what to work on before I started working on it. Moving all of that to a ninety-minute block on Monday morning gave me back roughly four hours of weekly focus time, without changing my actual throughput on task execution.
Friday ship and retrospect as a forcing function against scope drift. Most weeks I catch an item on Wednesday or Thursday that I've quietly been growing past its original scope. The Friday deadline is the thing that forces the "is this the shippable version or is this the bigger version" call. Ninety percent of the time the shippable version is fine. Ten percent of the time I push the ship into next week with a clear reason, not a vibe.
The agent council as the pre-plan input. I run the five-persona decision skill against the week's ambiguous calls on Sunday night for about twenty minutes. By Monday morning the four executive lenses have surfaced the tradeoffs. Planning is faster because the thinking has already happened. This is ground truth for me: I tried running the cadence without the council for six weeks and Monday planning took about 90 minutes longer each time. The council is documented architecturally in the agent council case.
The Friday retrospective template. Same five questions every week. What shipped, what got cut, what surprised me, what decision do I regret, what am I putting on next week's plan. Thirty minutes, writing fast. The template means I don't spend the retrospective deciding what to retrospect.
“The shipping day is the forcing function, not the planning day. Planning without shipping creates thoroughness without delivery.
”
What didn't
The Wednesday mid-week review. I ran it for a quarter. It was the session everyone (everyone being me) skipped. Folded it into Friday. No loss of quality.
The two-week sprint rhythm. I tried it for one quarter because every agile playbook recommends it. At solo scale two-week sprints mean the second Friday has all the pressure and the first Friday has none. Reverted to weekly at the start of Q2 2025. Weekly is the right clock for one person. Sprint language came from teams; solo work needs solo rituals.
The over-planned Monday. In month one I was planning twelve items per week. Shipped three. Twelve-item plans produce shame, not output. Cut the plan volume to four items plus two stretch items. Shipped three or four almost every week after that. The plan should be slightly smaller than the observed output, not slightly larger.
Saturday "just a little work." Burned two months trying to catch up on weekends. The catch-up was never real; it was just the weekday's work on a different calendar day. Committed to actual weekends. Productivity on Monday improved enough to more than offset the lost weekend hours.
A public kanban board for personal work. Tried it for a quarter with the idea that if the work was visible, I'd ship faster. The reverse happened. Visible backlogs make me want to groom the backlog instead of ship. Private markdown file, ship day, retrospective. That's the actual surface area that matters.
What I'd do differently now
Start the cadence at two ship items per week, not three. The number I picked was aspirational for month one, and it took about four weeks to recalibrate to a sustainable rhythm. Starting lower and earning up would have saved that recalibration.
Treat the rituals as more important than the task lists. The Monday block is sacred not because of what gets planned but because of the week-shaping effect of doing the ritual at all. Same for Friday. The ceremony carries the output; the output does not carry the ceremony.
Write the Friday retrospective on Thursday night. By Friday morning, I'm already thinking about next week. The retrospective writes better when the week is still fresh. I started doing this in Q4 2025 and the quality of the observation notes went up immediately.
Cut calendar meetings to one morning per week. I tried "only afternoons are meetings" and it sort of worked. The stronger version is "only Tuesday morning is meetings." Three days of agents-only focus time per week is worth the calendar rigidity.
What the next 12 months will test
Client project work mixing with product work in the same cadence. I've mostly run the cadence against my own product and writing work. A larger client engagement in Q3 will test whether the weekly ship rhythm absorbs another person's timelines or whether I need a different rhythm for client weeks.
When one shipping stream needs to become two. The most realistic version of scaling this practice is not hiring a second person; it's running two parallel ship streams, each on the same weekly rhythm. That's going to test whether the plan day and ship day rituals work when there are two parallel plans and two parallel ship lists.
The cadence under low-energy weeks. Travel weeks, sick weeks, family weeks. The last twelve months had three or four such weeks and the cadence mostly broke. The breakdown was not the problem; the snap-back in week one after was. I have a couple of ideas for a "maintenance mode" cadence that ships one item per week without a plan day, but I haven't stress-tested it.
The long plan. I don't do quarterly planning formally right now. Every twelve weeks I look back but not forward beyond the next Monday. A twelve-month retrospective is going to need a counterweight: a twelve-week forward view that sets the shape of the upcoming shipping stream. That is the next experiment I want to run, and probably the one that matters most.
Frequently asked questions
Does the cadence work if I have a day job?
A version of it does. The nights-and-weekends cadence I ran before going solo was one ship per week, not three, with Sunday afternoons as the plan block and weekday evenings as build time. The rituals still hold; the volume scales to the hours available. The mistake I watched other operators make was trying to run a three-ship-a-week pace on ten hours of free time. The plan volume should fit the actual hours.
How do you handle unexpected work that lands mid-week?
If it's from an active client, it displaces a build item and I update the Friday retrospective's "what got cut" section. If it's a speculative request, it goes into next week's plan candidate list. The rule is that nothing other than an active commitment gets to displace the week's plan mid-stream. That rule cost me a couple of small opportunities in year one; net it saved more than it cost.
Is three items per week a lot for a solo operator?
Depends on item size. Three small items (a pushed article, a client deliverable, a feature on the site) is medium pace. Three large items (an agent council skill, a product page with checkout, a full case study) is aggressive. The three-per-week average across twelve months mixed small and large. The pace is feasible because the tooling stack compresses the time from idea to shipped output dramatically. I've written about the economics of that in the $200 a month AI tooling baseline.
What's the minimum kit needed to run this cadence?
A markdown file for the weekly plan, a markdown file for retrospectives (one per week), and a calendar that protects Monday and Friday. Optional but high-leverage: a daily triage skill like the one I describe in the morning triage I run every day, and an agent council. The cadence ran on just the markdown files for the first three months. The agent tooling added throughput later; it was not a precondition.
How do you handle the two-week sprint that most consulting clients want?
The internal cadence stays weekly. The external commitment stays whatever the client needs, usually two-week. What I ship to a client on their cadence is an aggregated output of my weekly rhythm. Weekly work, fortnightly communication. That translation has been invisible to every client so far because the deliverables feel coherent on their timeline while the underlying work is running on a faster one.
Sources and specifics
- Retrospective covers roughly 12 months of running a Monday-plan / Tuesday-Thursday-build / Friday-ship cadence from April 2025 through April 2026.
- Shipped output averages three items per week, where an item is a published article, released case study, delivered client artifact, or shipped Claude Code skill.
- The two-week sprint experiment ran for one quarter and was reverted. Weekly is the observed right clock for a one-person practice.
- Agent council integration documented in the agent council case; pre-plan workflow shaves roughly 90 minutes from Monday planning when run.
- Full practice context in a hybrid creative-tech operator role. The productized version of this methodology is the One-Person Studio OS.