Shipping Cadence: How Often Should Indie Hackers Ship?

Quick answer

There's no universal shipping cadence. Daily, weekly, and milestone-based release rhythms all work, and the number matters less than whether you actually pick one and stick to it. What separates indie hackers who ship consistently from those who don't isn't skill or hours available — it's a fixed, self-imposed cadence tight enough to force a project to finish. Without one, work quietly expands to fill whatever time it's given, and "almost done" can stretch for months. The right cadence depends on where your project is: pre-launch work benefits from a tighter, near-daily rhythm; a live product with real users usually fits better on a weekly or milestone-based one.

How it actually works

Fixed-schedule productivity: pick the hours first, then fit the work

Most advice about shipping more starts from the wrong end — it assumes you need more hours, or more discipline. Cal Newport's fixed-schedule productivity framework flips that: choose a schedule of work hours first, then do whatever it takes to keep everything else — including your project scope — inside it. That means actively refusing features that won't fit, delaying commitments, cutting the habits that quietly eat build time. It's a different discipline from open-ended "work until it's done" scheduling, because it forces you to decide what actually matters before you start, not after you've already spent the week on it. Protecting that block of maker time is exactly the problem behind maker-schedule vs. manager-schedule thinking — a shipping cadence only holds if the hours behind it are actually protected from interruptions.

Parkinson's Law as a deliberate tool, not just a warning

"Work expands so as to fill the time available for its completion" usually gets quoted as a warning about procrastination. Cal Newport's closer read of Parkinson's original essay separates two versions of it. Personal deadlines — tight, self-imposed ones — compress a task down to its essentials, and that's something you can use on purpose: set the deadline first, and the scope tends to follow. The organizational reading is different, and it matters just as much for a two-person team as it did for Parkinson's original bureaucracy: groups without a clear goal or accountability structure drift toward busywork. Not because anyone's lazy — because unstructured time gets filled with whatever's easiest, usually email and reactive tasks, instead of the thing that was supposed to ship. A shipping cadence solves both problems at once. It's a personal deadline and a structural forcing function in the same commitment.

Where the more-than-once-a-week threshold matters

Cadence and process scale together. Guidance on release-cycle best practices points to a practical threshold: once you're deploying more than once a week, manual release steps start costing more time than automating them would save — that's the point to invest in a basic CI/CD pipeline. Feature flags are worth adding around the same time. They let you deploy on a fast, fixed cadence without exposing an unfinished feature to real users, decoupling "deploy" from "release" so cadence doesn't have to wait on polish. Not sure whether your build time is actually going toward shipping or getting absorbed elsewhere? It's worth running a one-week time audit before committing to a specific cadence — you want to know where the hours go before you promise a rhythm you can't back up.

When to use it (and when to skip it)

A daily cadence works best as an anti-perfectionism forcing function, and it works best pre-launch. One indie hacker's plan to ship more often committed to a production deploy every single day after recognizing that over-analysis — not lack of time — was the real bottleneck. The commitment itself did more work than any single technique: a daily deadline doesn't leave room to keep polishing something no one has used yet.

Weekly milestones tend to fit better once there's a live product and real users. A small team's breakdown of how they ship fast leaned on weekly milestones specifically because they allow quick feedback loops without the overhead of daily release management — decisiveness and same-day resolution of loose ends mattered more to their pace than the release frequency itself. Giving each workday a single clear focus is one way to protect the build time a weekly cadence depends on, without needing to timebox every hour.

Skip a tight cadence during architecture-heavy weeks, when client-blocked freelance work is eating your calendar, or when hitting the deadline would mean shipping something broken. A cadence is a tool for forcing scope decisions, not a reason to ship low-quality work. If strict time-boxing keeps breaking against how a task actually flows, a more flexible technique for structuring the work itself might fit better than forcing a rigid interval on top of it.

Frequently Asked Questions

Is there an ideal shipping cadence for indie hackers?

No single number fits every project. The consistent pattern across solo builders is a fixed, self-imposed cadence — daily, weekly, or per-milestone — that's tight enough to force finishing and loose enough to actually sustain. The failure mode is the alternative: no cadence at all, which lets projects drift indefinitely.

Should I ship daily as a solo founder?

Daily shipping works well as an anti-perfectionism forcing function early on, when the risk is never finishing rather than shipping something broken. As a project matures and has real users, weekly or milestone-based cadences usually fit better because they leave room for testing and feedback between releases.

How is a shipping cadence different from Parkinson's Law?

Parkinson's Law describes what happens by default — work expands to fill the time you give it. A shipping cadence is you using that tendency on purpose: setting a tighter, fixed interval so a task's scope gets compressed to what actually matters, instead of letting it drift.

When should I add CI/CD or feature flags to my release process?

Once you're deploying more than once a week, manual release steps start costing more time than automating them saves. Feature flags are worth adding around the same point — they let you keep deploying on a fast, fixed cadence without exposing half-finished features to real users.

How Pomlo fits in

A shipping cadence isn't a willpower problem — it's a time-protection problem. Pick the tightest deadline you want; it only holds if the hours behind it actually happen. Pomlo's focus sessions help protect the deep-work blocks a cadence depends on, so "ship by Friday" isn't competing with an afternoon of context-switching. Its reports show whether build time is actually going where the cadence assumes it is — useful the first time a "daily ship" commitment quietly turns into three days a week. And separating projects keeps client work, admin, and your own build time in distinct buckets, so a cadence commitment on your own project doesn't get eaten by billable hours without you noticing.

Pomlo is available on iOS, Android, and the web — download it from the App Store or Google Play and start protecting the time your shipping cadence actually needs.