The indie hacker diary stack: GitHub + Bluesky + Todoist
The build-in-public thread is the highlight reel. The pinned post that says “Day 47” picks the moments worth posting and skips the rest. By the time anyone scrolls back through it six months later, the project looks like a clean line from idea to launch.
The actual line was not clean. The week the database migration broke and nothing shipped is gone. So is the Tuesday spent rewriting copy, the afternoon you almost gave up, the three days of unpaid bills you ignored to keep coding. None of those landed in any post, because none of them were post-shaped.
The diary is where they go. Not the public thread you share with followers, but the private record you keep for yourself, so the whole arc of the project survives instead of just the parts that played well online.
Three integrations are enough to assemble that diary on their own, and most indie hackers are already running all three for unrelated reasons. We have written previously about how the same setup can produce a public-facing build log. This post is about the private record sitting underneath, which is a different artifact.
Why these three, for solo building
A solo founder’s day does not look like a developer’s day at a company. No team chat is pinging through the morning. No time tracker is required by a manager. The work happens inside three smaller surfaces: a repository, a public account, and a list of things you keep telling yourself you will do.
Each surface holds something the other two do not.
The repository, viewed through GitHub, is the longest-running written record any indie project has. There is only one author committing to it, so every change is a decision you made and can read back. Branches that never merged are abandoned ideas. Forty commits on a Sunday are a sprint. A two-week gap is an honest one. For a solo project, the commit log is a more legible biography than anything a non-engineer founder will ever have access to.
The public account, here Bluesky, holds the voice of the project in real time. Not the polished launch thread, but the in-flight posts: the “this is harder than I thought” at 11 PM, the screenshot of the bug that made you laugh before you fixed it, the small-win post the morning a webhook fired for the first time. These get written before retrospect has a chance to smooth them over. That is what makes them diary material rather than marketing copy.
The task list, here Todoist, is the indie hacker’s private roadmap. Not assigned sprints, but a self-managed pile of intentions: the “rewrite landing page” that has slipped four times, the “register for the conference” you keep punting, the “talk to a lawyer about the LLC” that has been there since spring. The list is a running portrait of where you actually are versus where you keep telling yourself you are.
Three sources, three shapes of trace. Almost everything a solo project produces a record of, it produces in one of these. What does not produce a record anywhere (we will get to it) is its own category.
What the diary is, that the public version is not
The same three tools can produce two different artifacts, depending on who is reading the output.
The public version is what you share with followers: the readable assembly of what shipped this week, what you announced, what is next. It is curated, even when it is candid. You decide which days, and which moments inside those days, the audience gets to see.
The diary is what you read back when nobody is watching. Same source data, different audience. The diary keeps the entries you would never pin to a profile: the day the only commit was reverting the previous day’s commit, the Bluesky post you deleted, the task that has been on the list so long it has become a joke. None of those belong in front of an audience. All of them belong in a record of how the project actually went.
deariary writes the diary by default, every day, from the same three sources. Whether a specific entry becomes public is a separate decision made after the fact, not a precondition for the day to be recorded at all.
How a stacked diary entry reads
A Wednesday in the middle of a project, nothing dramatic, three sources reporting:
Wednesday opened on the landing page copy again. Three commits of revisions to landing-page, posted about at 10:42 with “two months in and the landing page copy still doesn’t sound like the product.” By midday the tax research had pulled you sideways: a try-stripe-tax branch opened, a new task added about EU customers. The “Rewrite About page” task slipped a fourth time. The quarterly tax estimate, second day unfiled.
Stripe webhook in staging finally tested clean. The duplicate-signup-email fix shipped as PR #34 in the afternoon, flagged on Bluesky at 19:30 as “the bug i wanted” because nobody noticed it. Investor follow-up email replied to between the webhook test and the deploy. The 14:15 post thanking whoever wrote the Stripe webhook docs sits in the middle of all of it.
That entry would not make a good Bluesky thread. The About page slipped again, the tax estimate is overdue, the landing copy still does not sit right. None of it is wrong, all of it is true, none of it is post-shaped.
But this is the Wednesday you would actually remember six months later. The PR is in the repo, but the repo does not say the afternoon was mostly the tax sidetrack, the slipped tasks, and a quiet win at dinner. The diary does.
What the public posts edit out
Bluesky as a journaling source has a specific quirk worth naming: it is the part of your day you chose to make legible to other people. That is its strength as diary material (the posts are honest, in the moment, untouched by retrospect) and its limitation. You only post what you are willing to share.
So a build-in-public stream alone tells a polished story. The post about the ramen win on day 12 is there. The post about the third silent week of database work, where there was nothing to show, is not there, because there was nothing to post.
The diary fills in the silent stretches. On the days you did not post, GitHub and Todoist still recorded something. Three commits to a refactor branch. A task closed, two slipped. The diary entry exists for that day even though the timeline does not. Reading the project back across a quarter, the silent stretches are often where the actual work was, and they are completely invisible if you only have the public posts.
The reverse case is also useful. On a day with no commits and no tasks closed, but a single post that says “took the day off, brain was fried,” the diary records exactly that. A code-only journal would leave the entry blank. A polished update would skip the day entirely. The diary calls it what it was: a rest day, mid-project, with a reason.
What the list says when it is ignored
Of the three sources, the task list is the one solo founders most often underrate as diary material. It feels mundane. It is mundane. That is what makes it useful.
The slips are the most interesting part. An item that sits on the list for two weeks while ten others move past it is telling you something about the project, or about what you are avoiding, or about what was never actually important. An item you keep adding back after closing is telling you something about scope. An item that finally closes after four slips is a different kind of moment than one that closed the day it appeared.
None of that shows up in the code log, because the work that did not happen leaves no commit. None of it shows up on the public side, because nobody posts about the chore they keep punting. The diary is the only artifact in which the running picture of avoidance and slippage is visible at all.
Reading back, the patterns are useful. Repeating slips often point to a co-founder problem, a pricing problem, or a “I do not actually want to work on this” problem worth surfacing. Once a year, the persistently slipped items in the diary are some of the most honest data the project has on itself.
Setup
Free tier permits one connection, so running all three needs Basic or above. Basic raises the cap to five, leaving headroom for a fourth tool later if the project grows into one. The current plan comparison lives at deariary.com.
A reasonable connection order is GitHub first (the longest written record an indie project has, on day one), Todoist next (the list, where intent and reality diverge), Bluesky last (the most personal piece, since your public voice now lives next to the work that produced it). Each one is an OAuth flow that finishes in under a minute. The morning after the third connection, the previous day’s entry has all three layers woven through it.
What no integration captures
Plenty of solo building does not produce a trace anywhere. The customer support reply written from a phone, unless it routes through a webhook. The investor call, unless the calendar is connected. The walk where the actual pivot decision happens. The two hours of staring out the window before the day’s first commit. These leave no fingerprints in any system, and so they leave none in any diary.
Some of the gaps close with extra connections. Calendar covers calls. Toggl covers hours. Webhooks bridge anything else that emits an event. The rest of the gaps stay open by nature, because some of solo building is undocumented and always will be.
What the three-tool stack does record, with no daily effort from you, is the part of the project that left a trace somewhere. For most indie hackers, on most days, that is the majority of the work. Reading the diary back, six months or a year later, is what turns those traces into a story you can still recognize as your own.
The launch threads will get the likes. The diary is for you.
The three integrations are wired up from your settings page.
