The problem
Building in public works. Writing about it does not happen.
Every developer who has tried to build in public has hit the same wall. The work is shipped on Tuesday, the LinkedIn post about it is drafted on Thursday, and by Friday the post has been re-edited three times and never published. The writing tax is real. The output collapses to zero within a month.
The mechanical problem is not that the writing is hard. The writing is reasonably easy if the developer is willing to do it. The problem is that the activation energy of context-switching from "shipping" to "posting" is consistently higher than the perceived reward, especially for technical founders who view writing as overhead.
The opportunity was to remove the activation energy. The Git history already contains the narrative. The LLM stack is good enough now to draft an on-brand version of that narrative, leaving the developer to either publish, edit, or skip.
Constraints
Cost, voice, and trust.
Three constraints shaped the architecture. First, cost. A single user might have 50 commits a week across 5 repositories, and drafting useful content for each commit means dozens of LLM calls. The per-user economics had to work at indie SaaS pricing, not enterprise pricing.
Second, voice. The output had to sound like the developer wrote it, not like an LLM wrote it. Generic tech-marketing-speak was the failure state. The system had to learn each user's voice from their existing posts and stay inside it.
Third, trust. An auto-poster that puts wrong claims on a developer's public profile is worse than no poster at all. The default workflow had to keep the developer in the loop, with auto-publish as an opt-in for low-stakes channels.
Architecture decisions
The shape of the system.
Multi-provider LLM factory. OpenRouter for breadth, Anthropic direct for the quality-critical drafts, Groq for the cheap-and-fast classification passes. A factory selects the right provider per task type, with automatic fallover when a provider is rate-limited or returns an error. Per-user cost caps. Per-task model selection.
A two-stage drafting pipeline. Stage one classifies the commit (feature, fix, refactor, chore, breaking change) and decides whether it is post-worthy. Most commits are not. Stage two, for post-worthy commits, drafts the post in the user's voice using the user's existing posts as few-shot examples.
Voice extraction from existing posts. When a user connects their LinkedIn or X account, the system pulls their last 30 posts, extracts the dominant style features (length, tone, structure, vocabulary), and stores a voice profile. The drafting prompt always includes the voice profile.
Output queue, not output stream. Drafts land in an editorial queue inside the app. The user reviews, edits, schedules, or skips. Publishing happens on a separate worker, on a schedule, with rate limiting per platform.
Postgres for the editorial state, Redis for ephemeral data. Drafts, schedules, voice profiles, post history, and LLM cost tracking all live in Postgres. Session state and short-lived locks live in Redis.
The Next.js app is a thin editorial UI. Most of the work happens server-side. The frontend is small, fast, and focused on review and edit.
What we shipped
The visible surface.
An editorial queue that shows the week's commits, classified, with drafts attached to the post-worthy ones. A voice profile dashboard that shows the user what the system thinks their style is, and lets them correct it. A scheduling interface that handles cross-platform posting with per-platform formatting (X gets a thread, LinkedIn gets a structured post, dev.to gets a longer draft).
Behind the surface: a cost dashboard per user per provider per day. A platform-specific publisher that handles each network's quirks. A feedback loop where the user's edits to a draft become positive examples for the voice profile, so the system learns over time.
What we would do differently
The honest retrospective.
The voice extraction layer was the most fragile part of v1 and is still the part that needs the most user-facing trust. We would invest more, sooner, in showing the user exactly what the system inferred and why. Black-box voice modeling is not a defensible product surface.
The decision to support three platforms at launch was probably one too many. LinkedIn and X have different enough audiences that the same commit should produce two different posts. dev.to is a separate motion entirely. We would launch with two and add the third later, after each one was earning its place.
The auto-publish opt-in was correct in principle but under-used in practice. Most users want to review every post. The right default is "draft and notify," not "auto-publish with safeguards." We would lead with the conservative default more clearly.
Build in public, post in voice, without the writing tax.