Your public devlog, written by your tools

You have seen the threads. A founder posts “Day 47 of building my SaaS” and drops a bullet list of what shipped, what broke, and what is next. The thread gets likes. People follow along. And then, somewhere around Day 12, the updates stop.

Not because the building stopped. Because the writing did.

The building in public paradox

Building in public is supposed to be the honest, unpolished alternative to marketing. You ship something, you tell people about it, you move on. No press releases, no content calendars, just the work itself.

Except there is a gap between the work and the telling. After a long day of shipping, the last thing you want to do is open a text editor and reconstruct what happened. So you skip a day. Then a week. Then the thread dies, and the project keeps going in silence.

The paradox: the people who build the most have the least energy left to document it.

What a devlog actually needs

Strip away the format, and a devlog is three things layered together:

1. What you built. Commits, merged PRs, closed issues. The raw output.
2. What you decided. Tasks planned and completed. Features prioritized, bugs triaged, scope cut.
3. What you said about it. The public posts where you shared progress, vented frustration, or celebrated a milestone.

Most devlogs try to capture all three in a single writing session at the end of the day. That is why they fail. You are asking yourself to remember, synthesize, and narrate in one sitting, after doing the actual work.

But the raw material for all three already exists.

Your commits are in GitHub. Your completed tasks are in Todoist. Your public updates are on Bluesky. Each tool holds one layer of the story. No tool holds the complete picture.

Three tools, one devlog

deariary connects to all three and assembles them into a single daily entry. Not a dashboard or an analytics view, but readable prose that describes what your day looked like.

Here is what that looks like in practice. Say you spent a Wednesday working on your side project:

Wednesday, March 18

Spent the morning on the new onboarding flow. Merged two PRs: one that replaced the old welcome screen with a step-by-step wizard, and another that added email verification. Closed the “signup drops off at step 3” issue that had been open since last week.

Checked off five tasks in Todoist: finalize wizard copy, write verification email template, add rate limiting to the verification endpoint, update the docs, and deploy to staging. The deploy task sat in the backlog for two days before finally getting done.

Posted on Bluesky around 3pm: “Onboarding rewrite shipped to staging. Signup completion went from 40% to 68% in internal testing. Still ugly, but it works.” Got a reply from another builder asking about the rate limiting approach.

That is one day. You did not write any of it. GitHub provided the code story. Todoist provided the task story. Bluesky provided the public story. deariary wove them together.

Why the combination matters

Each integration alone tells a partial story. GitHub alone gives you a code log but misses the tasks you completed without committing code. Todoist alone gives you a task list but lacks the technical context of what those tasks involved. Bluesky alone preserves your public commentary but strips it from the work that prompted it.

Stack all three, and the devlog becomes dimensional. It shows the code, the decisions, and the narrative you shared with the world, tied together by the day they happened.

For someone following your project, this is far more interesting than “Day 47: worked on auth.” It is the full context of what building actually looked like on that specific Wednesday.

The devlog you will actually maintain

The reason most devlogs die is not lack of commitment. It is that maintaining a devlog is a second job on top of the first one. You already shipped the feature. Now you have to write about shipping the feature. The marginal effort feels pointless when you could be shipping the next thing.

Automatic devlogs eliminate that marginal effort. You do the work. The devlog assembles itself. The streak never breaks because there is nothing to maintain.

This changes the math of building in public. When the cost of documentation drops to zero, you can share every day, not just the days you have energy left over. The quiet Tuesdays where you only fixed a flaky test and reorganized your backlog are recorded alongside the Fridays where you launched a major feature. Both matter to someone following along.

Sharing it

deariary lets you make individual diary entries public with a shareable link. Drop it in your project’s README, pin it to your profile, or link it from your weekly update post.

Some builders share daily. Others post a weekly roundup with links to the entries that mattered most. The format is flexible because the content is already there. You are not creating something new to share. You are choosing which existing entries to surface.

This also solves the “building in public” authenticity problem. When you write a devlog by hand, there is always the temptation to make it sound better than it was: more productive, more decisive, more on track. An automatic devlog just reports what happened. The messy days are messy. The slow days are slow. That honesty is exactly what makes building in public compelling.

Beyond the solo project

This is not limited to solo indie hackers. Small teams building a product together can each connect their own tools, and the combined output becomes a team devlog. One person’s commits, another’s task completions, and the team’s shared social posts all flow into the same record.

For open source maintainers, the devlog becomes a transparent log of project activity that contributors and users can follow. What got merged this week, what issues were triaged, what the maintainer said publicly about the project’s direction.

Getting started

Connect GitHub, Todoist, and Bluesky in your deariary settings. Each takes about 30 seconds. If you use other tools, webhooks can pipe in deploy events, CI results, or anything else with an API.

Your first complete devlog entry will appear the next morning. Read it, and you will see the day reconstructed from three different angles.

You were building in public the whole time. Now there is a record of it.