Nothing is finished until you say it is

Hey, it’s Paul. Sunday, March 2, 2026.

Something unusual happened today. I looked across five active software projects and realized that four of them formally closed a milestone. Not shipped a feature. Not merged a PR. Closed a milestone — said “this body of work is done, we’re moving on.”

One project closed its entire issue backlog. Zero open items. Another submitted a version to the App Store and immediately closed the milestone and opened the next one. A third hit 17 out of 17 issues completed on a milestone that had been open for weeks. A fourth was at 53 out of 54.

None of this was coordinated. But all of it happened on the same day. And it made me realize something I’d been ignoring: I’d been shipping constantly but rarely finishing.

The problem with continuous delivery

Modern software development is built around continuous flow. Ship small, ship often, never stop. There’s no release date, no version number, no moment where you pop the champagne and say “that’s done.” The backlog is infinite. The pipeline never empties. You’re always mid-stream.

This works brilliantly for throughput. You get faster feedback loops, smaller risk per change, fewer coordination bottlenecks. But you lose something that turns out to matter a lot: endings.

Without a formal ending, work just… accumulates. Issues get closed but they don’t add up to anything. You look back at three months of merged PRs and you can’t point to a boundary and say “that was a thing we did.” It’s all one continuous blur of commits.

I noticed this because I built tooling today — skills for my AI pipeline — that automatically tracks milestone progress when work ships. And the moment I turned it on, I could see the gap. Issues had been getting created and closed for weeks without ever being assigned to a milestone. Work was happening. Progress was invisible.

What milestones actually do

Here’s what’s interesting. A milestone isn’t a technical artifact. It’s a psychological one. It forces you to answer two questions that continuous flow lets you avoid: What are we trying to accomplish? And how will we know when we’re done?

Those questions sound simple. They’re not. “What are we trying to accomplish” requires you to draw a boundary around scope — to say “this is in and that is out.” Continuous delivery never makes you do that. There’s always the next ticket. “How will we know when we’re done” is even harder, because it means committing to a definition of done that you’ll have to live with.

One of today’s projects — a text editor for macOS — had three bugs that needed fixing before the next App Store submission. Not ten. Not “whatever we can get to.” Three. That constraint changed how the work felt. Each fix had weight. The third one closing meant something. Not just “another issue closed” but “this version is ready.”

That’s the difference between shipping and finishing.

Closing is a decision, not a state

The reason I find this worth talking about is that it applies way beyond software. Organizations struggle with this constantly. Projects that never formally end. Initiatives that fade instead of concluding. Teams that move on to the next thing without ever acknowledging that the last thing was completed.

I used to think this was a management failure — someone should declare victory or defeat and move on. But now I think it’s more subtle than that. Closing something is a decision. You have to actively choose to say “this is done.” And that means accepting that what you have is enough, even when you know it could be better.

Today, one project had all 17 issues closed but the milestone was still technically open. Nobody had clicked the button. The work was done but the ending hadn’t been declared. That gap — between completion and acknowledgment — is where organizational ambiguity lives. Where projects become zombies. Where people feel busy but can’t say what they accomplished.

The feedback that only endings provide

Something else happened today that I didn’t expect. The moment milestones started closing, the tooling started giving useful information back. “March 2026: 10 of 12 closed.” “v1.0.2: 3 of 3 closed.” These are sentences that only make sense if you’ve committed to a boundary.

Without the boundary, all you can say is “we closed 47 issues this month.” Sounds impressive. Means nothing. You can’t tell if that’s ahead of plan or behind it. You can’t tell if the important things got done or just the easy ones. Numbers without a frame are noise.

The frame is what milestones provide. And you only get the frame if you’re willing to draw the lines and say “this set of work belongs together, and when it’s done, we’ll know.”

The courage to say “enough”

I think the real reason continuous delivery won — beyond the engineering benefits — is that it’s easier. You never have to say “this is good enough to ship as a version.” You never have to commit to a scope and be held accountable for it. You never have to look at what you accomplished and judge it as a whole.

Milestones bring back that judgment. And judgment is uncomfortable. What if the milestone feels thin? What if the release notes are underwhelming? What if closing it means admitting that the ambitious thing you planned got descoped to something smaller?

Good. That discomfort is information. It tells you whether you’re working on the right things. Whether your scope is realistic. Whether your ambitions match your capacity. You don’t get any of that feedback in a continuous stream.

So here’s the question I’m sitting with tonight. Where in your work — or your life — have you been shipping without finishing? Where have you been in continuous flow so long that you’ve forgotten what it feels like to say “that’s done, and I’m proud of it, and I’m moving on”?

Because nothing is finished until you say it is. And saying it turns out to be the hardest part.