Favors.dev
To ship in public every day, separate the ship from the post. Every day you finish one small, real change. Then you spend five minutes on a four-line update: what changed, what it unblocks, what is next, and one open question. Some days that update is a screenshot. Some days it is a single sentence about a bug you found but did not fix. Both count.
Most daily-shipping advice quietly assumes you will have something worth announcing every day. You will not. Real product work is lumpy: three good days, a day lost to one bug, a day of renewals and refunds. When the plan requires a highlight every day, the first boring Wednesday either breaks the habit or gets dressed up as a win. Both end the same way, usually around week three.
What follows is the version that survives those Wednesdays: how to size a day's work, the update template, a worked week with two deliberately unglamorous days, how to batch without faking it, and the plain-text log that does the job of a streak tool.
Why is shipping every day different from announcing every day?
Because they are two separate acts with two separate bars. Shipping means a change now exists that did not exist yesterday. Announcing means telling people about it. The first should happen every working day. The second should be as small as the change was, which means most of your daily posts will be modest, and that is correct.
The mistake is welding them together. When "I shipped" has to mean "I have something impressive to post", the post starts setting the size of the work. You pick tasks that screenshot well instead of tasks that matter, or you skip a day of important invisible work because it would make a thin update. The audience never asked for a highlight reel. They follow along because the updates are honest and regular.
This is the practical half of a bigger idea. The guide to shipping streaks covers why a streak measures consistency rather than progress and how to design one that survives a bad week. This page is the daily routine that sits inside it.
What counts as a minimum shippable unit?
A minimum shippable unit is the smallest change a user, or you in a month, would notice. Write it down as one sentence before your first day, because it becomes the bar for whether a day counted. The test is simple: could you describe the change to someone without saying "worked on"?
The usual failure is sizing the unit like a project. "Improve onboarding" cannot be finished in a day, so every day ends without a ship and the update turns into "made progress on". Here is the difference across the kinds of work solo founders actually do, most of it unglamorous.
| Kind of work | Too big for a day | One shippable unit | What to post |
|---|---|---|---|
| Onboarding | Redesign onboarding | Cut the signup form from six fields to three | A before and after screenshot of the form |
| Bugs | Fix the billing bugs | Stop the double charge on plan upgrades | One sentence on what broke and who it hit |
| Marketing | Do SEO | Rewrite the pricing page title and meta description | The old line next to the new one |
| Customers | Talk to users | Reply to three churned users with one question each | The question you asked, not their answers |
| Infrastructure | Improve performance | Add an index to the slow dashboard query | The load time before and after, from your own logs |
| Docs | Write the docs | Write the one page support keeps linking to | The link and the question it answers |
Notice that two of those rows are not code at all. Replying to churned users and rewriting a page title are shipping, because each one changes something in the world. If your unit only counts commits, you will starve the marketing and customer work that decides whether the product survives.
What goes in a five-minute daily update?
Four lines, in this order. The format is fixed on purpose, so you spend the five minutes filling it rather than deciding what shape today's post should take.
What changed
One concrete thing that is different today than yesterday.
Signup form is down from six fields to three.
What it unblocks
Why it matters, in terms of a user or the next piece of work.
Mobile signups stop dying on the company-size dropdown.
What is next
Tomorrow's unit, stated small enough that you can finish it.
Tomorrow: the welcome email that used to ask for those fields.
One open question
A question a builder can answer in one line from experience.
Do you ask for company size at signup or after first use?
The first three lines are for the record. They keep you honest about what happened and they make a week of updates readable as a story. The fourth line is the one that does the public work.
The open question is what earns replies.An update that only reports gets a like at best. An update that ends with a question another builder can answer in one line from their own experience gets answers, and the answers are how people start to recognize your project. Keep the question narrow and factual: "signup or after first use?" works, "thoughts?" does not. If you want the broader case for why this feels less like self-promotion, it is in personal brand for founders who hate self-promotion.
What does a real week of updates look like?
Here is a worked week for a small subscription tool. The product is illustrative, but every entry is the kind of work a solo founder does in an ordinary week. Wednesday and Friday are the two unglamorous days, and they are in here deliberately, because those are the days that decide whether the habit lasts.
Monday
- changed
- Signup form is down from six fields to three.
- unblocks
- Mobile signups stop dying on the company-size dropdown.
- next
- The welcome email that used to ask for those fields.
- question
- Do you ask for company size at signup or after first use?
Tuesday
- changed
- Welcome email rewritten. It asks one question instead of three.
- unblocks
- I can finally read the replies instead of skimming them.
- next
- Fix the upgrade bug a user reported on Sunday.
- question
- Plain text or designed welcome email for a dev tool?
Wednesdayunglamorous day
- changed
- Spent the day on the upgrade bug. Found it, did not fix it. It is a race between two webhooks.
- unblocks
- Nothing yet. Knowing the cause is most of the work.
- next
- Make the second webhook wait for the first.
- question
- How do you order Stripe webhooks that arrive out of sequence?
Thursday
- changed
- Upgrade bug fixed. No more double charges on plan changes.
- unblocks
- I can turn the upgrade button back on in the app.
- next
- Refund the two people it hit and tell them what happened.
- question
- Would you email the fix to affected users, or only the refund?
Fridayunglamorous day
- changed
- Refunds sent. Renewed the domain, rotated a key, cleared the inbox.
- unblocks
- Monday starts with nothing overdue.
- next
- Pricing page copy, which has been wrong for a month.
- question
- Do you batch admin into one day or drip it through the week?
Saturdayrest day
Rest day, declared in advance. Nothing posted.
Sunday
- changed
- Pricing page says what the plans actually include now.
- unblocks
- Support stops getting the same question about limits.
- next
- Weekly recap post, then the onboarding checklist.
- question
- Monthly price first, or annual price first?
Read Wednesday again. Nothing shipped in the narrow sense, and the update says so plainly. It is also the most useful post of the week, because the question is specific enough that someone who has fought the same webhook ordering problem will answer it. Friday is admin, stated without apology. Saturday is empty because it was declared empty on Monday, not because the week ran out of steam.
None of those days required a highlight, and the whole week still reads as a founder moving a product forward. That is the effect you are after.
How do you batch updates without faking them?
Batch the thinking, never the claims. On a day when you have momentum and the next few units are obvious, write down the next two "what is next" lines and the questions you expect to have. That turns tomorrow's five minutes into two. What you never do is write "what changed" for work that has not happened, and schedule it to post.
- Safe to batch:tomorrow's unit, the open question, screenshots you already have, the weekly recap skeleton.
- Never batch:the "what changed" line. It gets written after the unit ships, every time.
- Worth batching weekly:a Sunday recap that stitches the week's four-liners together. It takes ten minutes because the dailies already did the work.
The reason is not moral. A scheduled update for unfinished work removes the one pressure that makes the practice useful: the small, daily obligation to finish something. Once the posts can go out without the work, the posts keep going and the work quietly stops.
How do you ship every day without a streak tool?
Keep a plain-text file with one dated entry per day, and paste the same four lines into it that you post publicly. That file is your streak counter, your weekly recap source and your changelog, and it lives somewhere no platform can switch off.
shipped.md
## Thursday
changed: upgrade bug fixed, no more double charges
unblocks: upgrade button back on
next: refund the two people it hit
question: email the fix, or only the refund?
## Wednesday
changed: found the upgrade bug, a webhook race. not fixed.
unblocks: nothing yet
next: make the second webhook wait for the first
question: how do you order out-of-sequence webhooks?
Newest entry on top, the same order the Keep a Changelog convention recommends for a project's changelog, and for the same reason: the reader cares most about what just happened. If you ever forget what you did, your version control remembers. git log with the --since option lists every commit since yesterday, which is usually enough to write line one. Just remember that commits count typing, not shipping, so a day of commits is not automatically a unit.
Tools still have a place. A community like WIP counts the streak for you and puts your entries in front of other makers. It is also a reminder of why the file matters: Makerlog, the old free streak community, is gone. makerlog.io no longer resolves and its app domain now redirects to an unrelated site, which I re-checked today. The full story is in what happened to Makerlog. Years of daily entries went with it. Keep your own copy.
The file is the record
It survives every platform you post to.
The post is the copy
Same four lines, pasted where builders read.
Five minutes, capped
Longer than that and it is a blog post.
Where you post matters more than the tool. A daily update in a feed of strangers disappears. The same update in front of a few dozen builders who know your project gets answers. Your public founder profile on Favors.dev works as that running log, and the launch calendar is where the bigger weekly milestones get seen by people who trade help back. For what is worth sharing beyond the daily note, the build in public playbook covers the rest.
What do you post on days you shipped nothing?
Post the truth, at its actual size. A day without a unit is not a failure to hide. It is one of four ordinary situations, and each has an honest post.
What you learned
The cause of a bug you have not fixed yet is real progress. Say what it was in one sentence.
What you decided not to do
A cut feature or a dropped idea is a decision, and decisions are the most interesting thing a builder posts.
The question alone
Skip the first three lines and post only the question you are stuck on. It is the line that earns replies anyway.
Nothing, on purpose
If today is a declared rest day, the most consistent thing you can do is honor it and post nothing.
The one post to avoid is the manufactured one: a trivial change shipped at 11 pm to keep the day alive, or a vague "great progress today" that nobody can reply to. Readers notice both faster than you would think, and you notice them too, which is worse. The streak survives a missed day. It rarely survives the feeling that it has become theater.
A final rule that saves most daily-shipping habits: decide your rest day before the week starts. A day off that was planned is part of the routine. A day off that just happened is the first step toward stopping.
Frequently asked questions
How do you ship in public every day?
Separate the ship from the post. Every day, finish one minimum shippable unit, meaning the smallest change a user or future you would notice. Then write a short update in four lines: what changed, what it unblocks, what is next, and one open question. Post it in one place where builders already know your project, keep a plain-text copy in a file you own, and declare a rest day in advance so a missed day is a plan rather than a failure.
What should I post if I did not ship anything today?
Post what you learned, what you decided not to do, or just the question you are stuck on. The cause of a bug you have not fixed yet is progress, and a cut feature is a decision worth sharing. What you should not do is invent a win or ship something trivial to have something to post. If the day is a declared rest day, posting nothing is the consistent move.
How long should a daily build in public update take?
About five minutes. The four-line format keeps it there: one concrete change, why it matters, tomorrow's unit and one question. If an update is taking longer than that, it has turned into a blog post, and those belong in a weekly recap rather than a daily note. The daily version is meant to be cheap enough that it never competes with the work itself.
Is it okay to write build in public updates in advance?
You can draft ahead, but you should only post an update after the work it describes is done. Batching the writing on a high-energy day is fine: note tomorrow's unit and the question you expect to have. Posting an update for work that has not happened yet is the one form of batching that breaks the whole practice, because the log stops being evidence.
Do I need a streak tracker to ship every day?
No. A plain-text file with one dated entry per day does the counting, and git log can show you what you actually changed if you forget. A tool like WIP adds a community and an automatic counter, and Makerlog, the old free option, is no longer online. The part no file replaces is people who notice when you stop, so post the update somewhere builders already know your work.