Build in Public with Less Friction: My Real-Time Dev Diary Using NoteVault

Building in public without killing your flow

I like building in public. I hate context switching.

The problem is simple. When I am deep in code, I do not want to open Twitter, write a thread, polish screenshots, and remember what I did an hour ago. That kills the momentum.

But I still want a breadcrumb trail of what I actually did. Not a polished retro. A live feed of decisions, dead ends, and ugly hacks that eventually ship.

This is where NoteVault came in. I wired it up as a real-time dev diary with AI summarization on top. The result is a build log that basically writes itself while I work.

What I actually wanted from a dev diary

I tried all the usual stuff first.

• Daily notes in Obsidian.
• Manual changelogs in Notion.
• Git commit messages as history.

They all failed for the same reason. Too much discipline required. Too much ceremony. By 3 pm I had already forgotten what I did at 9:30.

So I wrote down what I actually wanted from a dev diary:

• Capture in seconds, not minutes.
• Zero formatting rules while I am working.
• One place, not five apps.
• Automatic summary at the end of the day.
• Something I can publish with minimal editing.

If the tooling fights any of those, I just stop using it after two days. I know myself well enough by now.

How NoteVault fits into this mess

NoteVault is basically a capture inbox with brains. Short notes, fast input, and then AI does the heavy lifting for organizing and summarizing.

I use it as the single firehose for my development day. Everything I do, think, or break ends up as a tiny note. I do not worry about structure while I am working. Structure comes later, handled by AI.

Very simple rule: if it took longer than 2 minutes, or I do not want to forget it, it gets a note.

The live dev diary setup

Here is the setup I actually use right now, not some idealized system I wish I used.

1. Short, timestamped notes all day

I keep NoteVault open on the side of my main monitor. No sidebars, no fancy views. Just a text box and a keyboard shortcut.

Every time I finish a small chunk of work, I drop a note. No editing. No rewriting. Just brain dump.

• Format: one or two lines, max.
• Always include: what I changed, why I changed it.
• Sometimes include: links, code snippet, screenshot.

Raw examples from a recent day, straight from my log:

• [09:42] Swapped NoteVault summary prompt to prioritize dev-only notes, general journaling kept out of daily digest.
• [10:17] Fixed scroll jitter on mobile nav in Safari by forcing GPU compositing on header (translateZ hack) and reducing box-shadow blur.
• [11:03] Tried streaming AI summaries on each note, too laggy. Rolled back to batched summaries on timer.

That is it. No tags yet. No nested hierarchies. I think premature organization kills this kind of system.

2. Lightweight tags for public-facing notes

I do not want my personal thought dumps to leak into public build logs. So I use a single convention: any note that is part of the build-in-public stream gets a simple label in-line.

Example:

[13:22] <public> Swapped dark mode toggle to system-preferred by default, added small tooltip for manual override.

Anything with <public> is fair game for publishing. Everything else can be internal context.

I tried using multiple tags like <bug>, <idea>, <refactor>. That looked nice for three days and then I completely forgot to be consistent. Now I just use one bit: public or not.

3. AI-powered daily summary prompt

The important part is what happens after the day is over.

I have NoteVault automatically collect all notes between, say, 08:00 and 18:00, and then feed them to an AI prompt that generates a daily build log.

The prompt is very specific. I tuned it over a few weeks. Here is the current version in plain English:

• Consider only notes that contain <public> if present. Ignore personal notes.
• Group related notes into 3 to 6 sections with headings.
• Preserve technical detail and decisions. Do not abstract everything away.
• Keep the voice first person. I did X, I broke Y.
• Output as markdown so I can paste into my blog.

This gives me something like:

## Shipping better mobile nav

- Fixed Safari scroll jitter by forcing GPU compositing on the header.
- Reduced box-shadow blur to avoid visible repaint lag.

## Tuning AI summaries in NoteVault

- Adjusted daily summary prompt to only include <public> notes.
- Abandoned per-note streaming summaries because of latency.

Most days I barely edit this. Maybe I trim one or two bullets that are too minor. Then it goes straight into my build log on the site.

4. Automatic triggers instead of discipline

I do not trust my 18:00 self to remember to run anything manually. So I wired the summarization as a scheduled job.

My current setup:

• Cron-like schedule in the backend that runs at 18:05 local time.
• Fetch all notes from NoteVault API for that day.
• Call the AI summarization endpoint with the prompt above.
• Save the output as a draft markdown file in my blog repo.

When I open my editor the next morning, yesterday's build log is already there waiting for a quick skim and publish. No friction. No "I will write the update later" fantasy.

Why this works better than traditional journaling

The main win is obvious: I do not have to remember anything. The notes are taken when the context is still warm.

But a few smaller wins matter too.

1. Honest history, not a PR statement

Retrospective updates always get polished by memory. Bugs disappear. Dead ends get compressed into a line or two.

With real-time notes, the log shows what actually happened. Including the dumb stuff like:

[14:36] <public> Spent 20 minutes debugging a "broken API" that was actually my local .env not loaded.

I think this kind of honesty is why build in public is interesting in the first place. Otherwise it is just marketing.

2. AI is good at structure, bad at guessing

I do not want AI to invent what happened. I want it to clean up what I already wrote.

Because I feed it dense, timestamped notes, it has actual material to work with. It can safely group, summarize, and rewrite for clarity. It does not need to hallucinate missing context.

This is where people go wrong with AI summaries. They throw a vague paragraph at it and hope for detailed changelogs. That is backwards. Capture first. Summarize second.

3. Publishing becomes a one-click decision

Before this system, publishing a build log meant:

• Reconstructing the day from memory.
• Checking git log.
• Opening too many browser tabs.

Now I just open the generated markdown, skim for anything sensitive, and hit publish. 5 minutes tops.

Because I use the <public> label, I rarely need to redact anything. I already filtered at capture time with a single word.

The rough edges and what I changed

This setup is not magical. I broke it a few times and had to adjust.

1. Too many notes, useless summaries

At first I logged everything. Absolutely everything. The AI summary turned into a wall of noise.

For example:

[09:05] Opened Figma.
[09:07] Checking email.
[09:12] Coffee.

That was nonsense. Now I use a simple filter for myself: would future-me care in a week? If not, I skip it.

The AI prompt also helps by ignoring trivial notes. I tell it to prioritize decisions, bugs, and visible changes over meta stuff like "writing docs" or "answering Slack".

2. Latency killed per-note AI

I tried doing fancy stuff at first. Every new note triggered an instant AI micro-summary. It looked cool on paper.

In practice, waiting even 1 or 2 seconds after every note broke the flow. So I killed it. All AI work happens in batch, outside my working window.

I think this matters. Anything that slows input will eventually kill the habit.

3. Mixing personal journaling and dev logs

I also use NoteVault for non-dev stuff. Sleep tracking. Random ideas. Health experiments.

That polluted the dev summary fast. The AI tried to merge kettlebell notes with API debugging. Awful.

The fix was simple. I added one more rule in the prompt: ignore anything that looks like training, food, or sleep unless it explicitly has <public> and references a project name.

This created a clean split. Same tool. Different output streams.

Publishing the dev diary on my site

On the public side, I keep it as boring as possible on the infrastructure front. Markdown files in a repo, rendered as part of the site.

My pipeline looks like this:

• Cron job drops a new markdown file in /content/build-log/YYYY-MM-DD.md.
• File contains frontmatter with date, title, and tags.
• The body is exactly what NoteVault's AI produced, with headings and bullets.
• Next deploy picks it up and rebuilds the site.

Some days I write a short intro paragraph manually. Most days I do not. The point is consistency, not literary quality.

Readers can scroll the archive, see the unfiltered stream of changes, and connect releases with the work that happened.

Why I think this approach scales

I am not pretending this system is perfect. But it checks the two boxes that matter for me.

• I actually use it every day.
• It produces something that feels honest enough to publish.

If you are building something and want to share the process without turning your dev day into a content creation job, I think this kind of NoteVault plus AI setup is a good tradeoff.

Keep the input frictionless. Make the AI do boring structure work. Automate the publishing pipeline as much as your tolerance for jank allows.

Then ship the log, even when it feels too small to matter. That is where the interesting stories usually start.