Why the Last 30% of a Side Project Stalls

It's a quarter to ten on a Wednesday night, and the app you've been building since April runs on your phone. It has worked, more or less, for six weeks. The list of what's left is eleven lines long — finish onboarding, polish settings, fix the sync edge cases, fill in the store's privacy form — and you open it after work, read the first line, move a button four pixels to the left, and close it again.

Nothing on the list got shorter.

The last stretch of a side project stalls because the work changes kind, not because you stopped caring about it. The first seventy percent is mostly making: new screens, new chapters, something visible at the end of every session. What's left is mostly judging and closing — testing, fixing edge cases, rewriting, settling the decisions you put off, packaging the thing so someone else can use it. Judging asks for fresher attention than the tired evenings the making used to get. Closing suits those evenings but rarely gets them, because it never looks like progress. The way through is to relabel what's left by the attention it needs, give each kind the hours that suit it, and write one sentence that says when you're done.

The project that's almost done

A project that's almost done has its own kind of evening. In the early weeks, an hour after work produced something you could point at: a screen that wasn't there yesterday, a feature that finally worked. The hour ended with proof. In the last stretch, the same hour ends with nothing that looks like progress. You tested something and found it mostly worked. You looked at two layouts and didn't pick one, then reread the onboarding text four times and changed a comma.

That evening feels like you've stopped caring, and mostly you haven't. What changed is how the work pays. Making pays as you go: every session leaves a mark. Finishing — the judging and closing — pays at the end, and only if the decisions inside it actually get made. Without the running payment, the sessions shrink — first to twenty minutes, then to opening the project and closing it — and the project sits at almost done for a month.

The same thing happens to someone writing a book alongside a job. The first draft is making, and it grows every evening it gets. Revision is judging and submission is closing, and both tend to inherit the late slot the draft was written in. Work that only pays off when it lands behaves this way in general: progress stays invisible until the day it's finished.

The same row of cards. The end of it is a different kind of card.

Making, judging, and closing

Work on a project comes in three kinds, and the mix changes as the project ages. Making adds something that wasn't there: a screen, a feature, a chapter, a first draft of anything. Judging decides what stays — testing, comparing, cutting, rewriting, and settling the questions you deferred while you were making. Closing finishes things for good, in steps with no decisions left in them: uploading the build, formatting the manuscript to a template, filling in the submission form, pressing publish.

Early on, a project is mostly making, and making is forgiving about when it happens. A tired evening can still produce a rough screen or six hundred words, because you can pick up where the last session stopped and the result is visible either way. The schedule that grows around a side project — after dinner, after the house goes quiet, whatever is left of the day — grows around making.

The last stretch is mostly judging and closing, and that schedule fails each of them for a different reason. Judging done in a tired hour tends not to hold. A layout picked at ten at night is usually picked to end the evening rather than to settle the question, so the next time you look at it the reasons aren't there, and the decision gets made twice.

Closing is the other way round: it suits a tired hour, with no decisions in it to reopen, and still rarely gets one. A closed item makes the list shorter but leaves the thing you're making looking as it did the day before, and months of making have taught you to read progress only in the thing itself. So the tired evening skips fill in the store's privacy form and goes to the top line instead: finish onboarding, which sounds like making and is usually a judgment in disguise. The button in the opening scene was a layout question, reopened.

The work didn't get harder; it changed kind, and the hours you give it didn't change with it.

Route the last stretch by kind

Moving a stalled project again means routing what's left by kind: each item gets a label, and each label gets the hours that suit it. It takes the list you already have, a pen, and four rules.

1. Relabel every line that's left. Mark each remaining item as making, judging or closing. Last-stretch lists are usually written in making words — finish onboarding, polish chapter nine — which hide what the work asks for. A line holding two kinds is two items, and splitting it is often the first real movement in weeks, because the next sitting starts from a line that can be finished.

2. Turn postponed decisions into items of their own. Judging hides inside vague lines because the decision was never written down. Decide: password or magic link can be finished in a fresh twenty minutes; polish sign-in can't, because nobody can say when it's done. A decision on the list is also one you can see you've made.

3. Give judging your freshest hour and closing your tired ones. A decision you can't explain the next morning gets made again, so judging goes wherever fresh time turns up, even half an hour on a Saturday. Each decision leaves closing steps behind it, and closing is the work a tired evening is good for. Measure those evenings in lines crossed off, not in changes to the thing itself.

4. Write the finished sentence, then cut what it doesn't need. Say in one sentence what will be true when you stop: The app is on the store and the link has gone to three friends. Every remaining item either serves that sentence or moves to a later version. Without one, the list keeps growing, because something can always be better. It's naming the finished state, applied to a whole project.

With a notebook, this is a letter beside each line and one sentence at the top of the page. The rule that does the most work is the third: the other three reshape the list, but only the third changes what happens on Wednesday night. A stalled project is often less short of hours than of the right hour for the item in front of it. A Saturday is only where fresh time tends to turn up; what makes an hour fresh is the energy you actually have, and some weekday evenings have that too.

"But isn't this just the 90-90 rule?"

The ninety-ninety rule is the best-known description of the last stretch, and it is about time. Attributed to Tom Cargill of Bell Labs and popularized by Jon Bentley in 1985, it goes: "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time" (Wikipedia). It is a warning about estimates, and a fair one. What it doesn't tell you is what to do with Wednesday night.

Closer to the point is James Stanier's essay on finishing, which describes the ending of a project as "like landing, demanding a completely different kind of skill and attention" (Landing the plane). That is the same diagnosis. The essay is written for engineering managers, and its prescriptions fit that seat: protect the scope, check in more often, favour checklists over heroics, shield the team from new requests.

A side project has nobody to coordinate with. The person who makes the decisions, does the closing and supplies the hours is the same person, at the end of the same day. Scope still needs cutting, but there's no one to protect it from except yourself. What a solo project can still adjust is which kind of work gets which hour. That choice weighs more alone than on a team: most of a side project's hours come after a full day, so the few fresh ones are worth placing with care.

How Canvas Tasks handles the last stretch

This is where Canvas Tasks comes in. Every task carries an energy level — High, Medium or Low — and a nature: Creative, Thinking or Work, with Unclassified for anything not yet sorted. Both can be changed from the task's details, so relabelling means opening each remaining item and setting both: the nature for the kind of work, and the energy for how much it needs, which answers rule 3's question of a fresh hour or a tired one. The three kinds above map loosely onto the natures: making is usually Creative, judging is usually Thinking, and closing usually belongs under Work, the app's label for routine and administrative tasks.

Switch the task view to the matrix and, by default, tasks are laid out with energy as rows and nature as columns. The tired evening then has an address: the Low row, Work column. So does a fresh half hour: High, Thinking. Instead of asking which line on the list to face, the view shows the two or three that fit the hour you actually have.

In Canvas Tasks, a project has a Finished state field: one line, for the sentence in rule 4. The project can be completed before every child task is done: Complete project moves it to the Completed shelf with its child tasks kept, and it can be restored later, so what the sentence left out is still there when you come back for the next version.

The Stalled badge is there so a project doesn't sit at almost done for a month without you noticing. It appears when none of the project's child tasks has changed for about two weeks, not counting the days off you've set, and it watches the list, not the clock: time logged with the app's focus timer or by hand leaves it in place, while splitting an item or crossing one off clears it.

One honest limit: projects, and with them Finished state and the Stalled badge, are part of Pro. Relabelling tasks and the matrix view are free.

None of this makes the last stretch shorter. It gives each piece of it a label, and an hour that suits it.