The WIP limit

One project on the shelf now has an end condition and a plan for the day it fires. The rest have a verdict and nothing else, and a verdict is not an absence — a parked project still renews its domain, and a killed one whose sunset plan has not actually been run is still serving pages to strangers. Every one of them is drawing hours out of the same finite month, and nothing in the ledger yet adds those hours up.

This lesson adds them up, sets the total against a number you are going to have to choose, and takes the answer seriously even when it is unwelcome. The number that comes out is a cap on how many things you can keep alive at once. It is not a number anybody can look up for you, and the largest part of the work here is being honest about that.

A different cap from the one triage already set

The triage module already capped something, under a heading using this same three-letter word, and this lesson is not re-arguing that cap. “At most two in pursue” is a limit on candidates you are actively pushing — a claim about where new hours go. What follows is a limit on a different set: the things already shipped, already reachable, already drawing maintenance whether or not you open the folder this month. Different set, different constraint, and the two numbers have no reason to match.

The membership test for this second set is not “am I working on it” and not “is it earning”. It is: could a stranger reach this today, and does it hold anyone’s data or money? A finished sports-guides site with no traffic passes that test. So does a half-built recipe app that never launched but still has a login page and a table of accounts behind it. Whether the thing earns changes what it is worth; it does not change what it costs, and this lesson is about the cost side.

A project can be in both sets, in one, or in neither. Something you are pushing hard that has never been shipped is in the triage cap and not in this one. Something you shipped, parked, and have not thought about since is in this one and not in the triage cap — which is exactly the case where a cap on pursue tells you nothing at all, and is why this lesson exists separately from that one.

The budget is a fact about you, not about a project

Every field the ledger carries so far belongs to a project. State, demand evidence, maintenance, verdict, rate, kill criteria, sunset plan — each of them is a sentence about one thing on the shelf. The field this lesson adds is not like that, and where it goes in the file matters for that reason.

Maintenance budget is the hours per month you are willing to spend holding already-shipped things steady, at zero growth, before an hour goes into building or selling anything. It is a fact about your month, not about any product, so it belongs at the top of PORTFOLIO.md, above the per-project sections, next to the summary table. Filed under a project it would read as that project’s property, and the whole point of the number is that it is shared out among all of them.

It has to be a figure you decided, and that is the part worth slowing down for. “Whatever’s left” is not a budget. It is a report on what already happened, written after the fact, and a number that is defined as the outcome cannot be exceeded — there is no reading of it that can ever contradict you. That is the same defect the kill-criteria work spent a whole lesson removing from a threshold, for the same reason: a commitment you cannot fail is not a commitment.

Where the shape of this idea comes from

Limiting how much you hold at once is not a new thought, and there is a precise version of it: a theorem. John D. C. Little published a proof of it in 1961 and wrote about it again fifty years later in Operations Research. His own statement of it:

“Little’s Law says that the average number of items in a queuing system, denoted L, equals the average arrival rate of items to the system, λ, multiplied by the average waiting time of an item in the system, W.” (Little, Operations Research, 2011)

Rearranged, it is the sentence that gets quoted at people: hold more things at once, and each one waits longer. That intuition is real and it is worth having. What is also worth having is the paragraph that comes before it, because Little is careful about what kind of thing his law is about:

“A queueing system consists of discrete objects we shall call items, which arrive at some rate to the system. … The stream of arrivals enters the system, joins one or more queues and eventually receives service, and exits in a stream of departures.” (Little, Operations Research, 2011)

Read the departures again. A queueing system is somewhere items pass through. Your live products do not pass through anything — you shipped them in order that they would stay. There is no departure stream, so there is no waiting time to average, and W is not large but undefined. That is not the law failing. It is the law being about something else, and Little says so plainly in the same paper: the quantities in the formula are “different averages with different dimensions”, computed over a period you have to define.

The version that circulates in project-management writing — WIP equals throughput times cycle time — is not a mangling of the algebra, and it is worth being precise about that too. Little’s own paper prints the operations-management form, TH = WIP/CT, credits it to Hopp and Spearman’s Factory Physics (2000), and records that it “is equivalent to λ = L/W.” The rearrangement is sound. What travels badly is the assumption underneath it: the theorem describes averages over a defined period in a system where items arrive and leave, so applying it to a particular board, or a particular shelf, asserts that the board is that kind of system. Checking that assertion is no part of the popular version, and it is the thing to check.

What the WIP-limit literature actually argues

The place the phrase “WIP limit” comes from is the Kanban method, and its own documents are short enough to read rather than paraphrase. Kanban University publishes The Official Guide to The Kanban Method, which defines the term twice and never once appeals to a formula:

“WIP (Work in Progress) states the number of work items in progress at a certain time” … “WIP limits serve as an enabling constraint, which gives focus and develops behaviors such as collaboration and finishing started items with high quality. WIP limits are key to establishing a pull system.” (Kanban University)

The justification the guide gives is about flow and slack: “When resources are fully utilized there is no slack in the system and the result is very poor flow, just as in rush hour on the freeway.” David J. Anderson, who adapted Kanban for knowledge work and whose 2010 book the guide names as its basis, argues the same way in his own writing on the method:

“It is the WIP limit that ultimately stimulates conversations about process problems. … The team has the option to break the limit, ignore the problem and carry on, or to face up to the issue, discuss it and suggest a change.” (Anderson, djaa.com)

Three things fall out of reading those two documents rather than repeating what people say about them.

• Neither one mentions Little’s Law. Not once, in either document. The derivation people attribute to the method is not the one the method’s own primary sources give; they argue from flow, from pull signals, and from making process problems visible enough that somebody has to talk about them.
• The limit is on work items, and a work item leaves. The guide’s WIP limit is “the maximum number of work items allowed at a time” in a state on a board — a card that crosses from started to finished and exits. Shipping a product is that card exiting. Everything this lesson is about begins one moment later.
• Both are written for teams. Anderson’s sentence says “the team has the option”; Kanban University’s guide works through departments and internal services. This is literature about a group of people moving work through a shared process, not about one person carrying standing upkeep.

The one strand written for a person

There is a version of this literature aimed at an individual, and skipping past it would be dishonest. Personal Kanban, from Jim Benson and Modus Cooperandi, reduces the whole method to two rules on its own site: “There are only two real rules with Personal Kanban: 1. Visualize your work 2. Limit your work-in-progress.” Its front page adds that Personal Kanban “was named to distinguish humane, knowledge-work Kanban from factory floor Kanban — not to say it was only for individuals.” Modus Cooperandi sells coaching, consulting, tooling and training in it, so the same caveat applies.

It is the closest precedent that exists and it is still not this. The work it limits is a task list — its own introduction names “people, tasks, responsibilities, deadlines, and even recreation” as the things competing for attention — and every one of those is something you can finish. Your live products are not in the doing column. They are done, and the load they generate is not the work of finishing them but the standing cost of their continuing to exist. A task list empties. A shelf of shipped products does not.

Nobody has published the number

Which leaves the actual question of this lesson without a source, and that is not a gap in the reading. I went looking for an authority on how many live products one person can run and there is not one: no study, no standard, no industry guide that puts a figure on it. What exists is qualitative advice about focus, which names no number, and anecdote.

The anecdote is worth naming so that its shape is visible. Indie Hackers, on 11 December 2025, published James Fleischmann’s write-up of Samuel Rondot, one person running a portfolio of three named products at $28K a month. It is a first-person case study rather than research, it describes one person’s outcome rather than a limit, and the body of it is cut off partway through by the site’s own subscriber wall — so even the anecdote does not tell you how he decided what he could carry. That is the state of the evidence.

Summing the shelf against the budget

The construct is one addition and one comparison. Take the Maintenance figure for every project that passes the alive test, in hours per month, and add them up. Set the total against the budget. What comes out is not a cap you chose — it is the number of projects whose upkeep fits inside the hours you said you had.

Invent a budget and four maintenance figures for a moment, purely to show the shape of the division. None of these are measurements and none of them are recommendations; they are placeholders. Suppose the budget reads ten hours a month, and the four live projects come to four, three, three and two. The sum is twelve. The shelf is two hours a month over a limit its owner set, before a single hour has gone into growing anything, and it was over before anybody wrote either number down.

The tempting response is to trim each one a little. That does not work, and the maintenance-load lesson already said why: the defining trait of this work is that it is tactical. The support email and the broken build arrive on the world’s schedule, not yours, so there is no version of them you can decide to do less of in advance. A maintenance number does not compress because you would prefer a different total. Something comes off the list instead, and which something is a ranking question you already have the instrument for — the effective hourly rate is the one figure in the ledger with your own hours in the denominator.

Two honest limits on this construct, said here rather than discovered later. It runs entirely on estimates: one project’s maintenance number was measured and the rest were estimated, so the sum inherits every one of those estimates and is no better than the worst of them. And it counts hours, which means it says nothing about the cost of holding four different products in your head at once — a real cost that this arithmetic cannot see and that no source found here measures for a portfolio of shipped products. The sum is a floor on what the shelf costs you, not a full accounting.

What a parked project costs

The triage module defined parked as no work and no spend beyond what keeps the lights on, plus a dated revisit. Keeping the lights on is a maintenance number, and the whole value of doing this sum is discovering that it is not zero.

• The registration still renews, on its own schedule, whether or not anyone visits.
• The dependencies still break. Parking defers that cost rather than removing it, and it arrives compounded on the day you next open the project and find the build no longer runs.
• The support email still arrives, and now nobody answers it. That cost is paid first by the person who wrote it and eventually by your name.
• The revisit date is itself an hour, and it is the one hour a park verdict explicitly promises to spend.
• If it ever took money or holds anyone’s data, the obligations that come with that do not pause. The kill-criteria work made the point in the other direction and it holds here too: the duty is the same on the day you launch and the day you stop looking.

So a parked project is a line item in the budget, not an exemption from it — at a smaller number than its live one, and never at zero. Parked felt free precisely because nothing was adding it up, and the sum is where it stops being free. The same goes for a project carrying a kill verdict whose sunset plan has not actually been run: until the exit is executed, it is alive, and it belongs in the total at its full number. Writing the verdict was the decision. Removing the line takes the work.

What this does not cover

There is now a budget at the top of the ledger, a total beneath it, and a name attached to whatever has to come off. All three are true on the day you write them and none of them stays true: maintenance numbers drift, a parked project’s revisit date arrives, and the hours you actually have change with everything else in your life. What the ledger still has no mechanism for is the reading — a fixed date to open the whole file and check it against reality, chosen in advance rather than triggered by something breaking. That is what comes next.