Ship in seven days: the loop that beats the roadmap
Roadmaps are forecasts, and forecasts rot. A seven-day build loop replaces the quarterly plan with something a solo founder can actually finish — and learn from.
The short version
- A week is the shortest box that still contains a real build — short enough that being wrong costs days, long enough to ship something a user notices.
- Scope by subtraction: write the release note first, cap the week at one user-visible outcome, and leave Friday afternoon for shipping.
- The week is done when something is live and someone outside your team has touched it — not merged, not staged.
- Spend the weekend reading three numbers, not building: did anyone arrive, did anyone return, did anyone use the thing you shipped.
The most expensive artifact in early-stage software is a roadmap nobody asked for. It looks like progress, it survives contact with no customer, and it quietly converts a week of building into a quarter of committing. The alternative is not chaos. It is a loop short enough that being wrong costs days instead of months.
Why seven days is the right box
A week is the smallest unit that still contains a real build. Shorter and you only ever ship cosmetics; longer and the scope quietly expands to fill the calendar. Seven days forces the two decisions that matter — what is in, and what is explicitly not — while the memory of the last release is still fresh enough to inform them.
Scope by subtraction
Start the week with the smallest change that a real user could notice and describe back to you. Then remove everything that only you would notice. Settings pages, admin niceties, the refactor you have been promising yourself — none of it survives a subtraction pass, and none of it teaches you anything about demand.
- Write the release note first. If you cannot write it in one sentence, the scope is still too big.
- Cap the week at one user-visible outcome. Infrastructure work is allowed only where it blocks that outcome.
- Leave Friday afternoon empty. Shipping takes longer than building, every single time.
Ship before it is comfortable
The instinct to polish is the instinct to delay judgment. Polish is real work, but it belongs after the market has told you the thing is worth polishing. A rough feature in front of ten users generates more signal in a day than a beautiful one in a branch generates in a month.
Read the week, then decide
The weekend is for reading, not building. Three numbers are usually enough: did anyone new arrive, did anyone come back, did anyone do the thing you built. If all three are flat, the following Monday is not for iterating on the same feature — it is for questioning the assumption underneath it.
Done consistently, the loop compounds in a way roadmaps never do. Fifty weeks is fifty pieces of evidence about what your users actually want, and the founders who have that evidence are the ones who look, in retrospect, like they had a plan all along.
Put this article to work
Ask it a question, or turn it into a to-do list for your own project. Both answer strictly from this article — nothing invented.
Answers are generated from this article only and are a working draft, not advice.
Questions this answers
How long should an early-stage build cycle be?
One week. It is the smallest unit that still contains a real, user-visible build, and it keeps the cost of being wrong at days rather than months. Shorter cycles produce only cosmetic changes; longer ones let scope expand to fill the calendar.
Should a solo founder write a roadmap?
Not a quarterly one. A roadmap is a forecast, and early-stage forecasts rot faster than they can be executed. A repeating weekly loop — scope, build, ship, read the data — produces evidence instead of commitments, and fifty weeks of evidence beats any plan written before you had users.
When is a feature ready to ship?
When a real user could notice it and describe it back to you. Polish belongs after the market confirms the thing is worth polishing — a rough feature in front of ten users generates more signal in a day than a beautiful one in a branch generates in a month.
Building something?
Put it in front of founders who read this — free listing, community-voted, reviewed before it goes live.
Keep reading
The blocker list: what actually stalls solo builders
It is almost never the hard technical problem. Weeks disappear into decisions that were never worth making, and into work that could have waited a year.
Read the article →
Retention is the only moat left
When anyone can rebuild your feature set in a weekend, the durable question is not what you built. It is why anyone opens it again on day thirty.
Read the article →
Launch day mechanics: the week that decides the day
A launch is a logistics exercise dressed as a marketing event. Almost everything that decides the outcome is done in the week before you post — which is good news, because that part is controllable.
Read the article →