Build in Public Strategy
By Cristian Lascu · The Sovereign Technologist · Last updated: July 6, 2026
TL;DR — What's on this page
Build in public strategy: what to share and how. The Sovereign Technologist. Practical frameworks for employed technologists building products, leverage, a
👉 Want the next list each Thursday?
Free. No spam. Unsubscribe anytime.
Building in public means narrating the work of shipping a product — the price you tested, the churn you saw, the feature you killed — out loud, on a channel you control, while you are still figuring it out. It works because a finished launch is forgettable but a decision in progress is followable: people subscribe to watch how it resolves. For a senior technologist with five to ten hours a week, it doubles as a forcing function and free research — every post that explains a choice sharpens the choice, and every reply is a signal you didn't have to pay for.
The failure mode is performing progress instead of reporting it. "Day 47, still grinding" with no number, no decision, and no artifact reads as a diary nobody asked for, and it trains an audience to expect motivation instead of substance. Building in public compounds only when each update carries something a reader can take: a metric, a template, a mistake with its price attached. Share outcomes and specifics, not moods — otherwise the audience you gather is just other builders performing back at you, and none of them will ever buy.
What should you share, and what should you hold back?
The test is simple: share anything that teaches, hold anything that harms. A workable default is to be generous with your reasoning and your results, and stingy with three things — data that belongs to someone else, confidence given to you in private, and the single hardest part a competitor could clone in a weekend. Most builders get this exactly backwards: they hide their metrics, which build trust, while broadcasting half-built features, which invite copying.
When in doubt, ask what a reader actually does with the information. If they learn something, share it. If the only party served is a competitor, or the only thing exposed is someone else's private data, hold it. The table below is a default, not a rule — a metric that would mislead before you have signal is worth delaying until it means something.
| Category | Default: share | Default: hold back |
|---|---|---|
| Metrics | Signups, revenue, churn, conversion — as ratios first, absolute numbers once you're comfortable | Figures that identify a specific client, or numbers that mislead before you have enough signal |
| Decisions | Why you chose the stack, the price, the niche — the reasoning behind it, not just the verdict | Legal, HR, or co-founder disputes that are still being negotiated |
| Failures | Features you cut, experiments that flopped, and what each one cost you in time or money | Failures that expose a customer's data or a partner's private confidence |
| Roadmap | The problems you're weighing and the tradeoffs between the paths in front of you | Unshipped features a competitor could ship faster than you can |
| Code / IP | Architecture patterns, snippets, and the lesson behind each one | The proprietary algorithm or dataset that is your actual moat |
Get the next list before everyone else.
Each Thursday, The Sovereign Technologist ships a new framework, agent-ready workflow, or curated list — built specifically for senior engineers, tech leads, and consultants who want to compound career leverage without quitting their jobs.
Free. No spam. Currently read by 141+ senior technologists.
How does sharing the process compound into an audience?
Compounding runs on three timelines. In the moment, a specific post — something like "I raised my price from nine dollars to twenty-nine and conversion barely moved" — gets shared because it settles an argument other builders are already having. Over months, those posts stack into a searchable archive that ranks and gets cited, so a stranger lands mid-story and reads backward through your decisions. Over years, you stop being a person posting updates and become the person known for a particular problem — an asset that outlives any single product you ship.
The mechanism only holds if the audience lands somewhere you own. Followers on a social platform are rented: the algorithm decides who sees you, and the platform can change the rules or disappear. Route every public update toward an email list so the relationship survives the channel. Post the story where the reach is, but end each one with a reason to subscribe — the follow-up numbers, the template, the next experiment — so attention converts into something you keep.
What cadence works when you have a full-time job?
Treat the constraint as the format. You cannot narrate daily and you shouldn't try; a weekly recap forces you to accumulate something worth reporting and keeps the update from decaying into a mood journal. Five to ten focused hours a week is enough when the writing is a byproduct of work you were already doing — you are not manufacturing content, you are publishing your notes.
The point of the cadence isn't discipline for its own sake; it's that a regular, specific update trains readers to expect substance from you and come back for it. Skip a week openly when there's nothing real to report — an honest gap reads as integrity, and it protects the signal of the weeks when something actually moved.
- →One weekly recap: the number that moved, the decision you made, the thing that broke
- →Draft it in fifteen minutes at the end of a work session while the details are fresh — not on Sunday from memory
- →Capture raw material as it happens: screenshot the metric, paste the error, so the recap is assembly rather than recall
- →Keep one longer piece a month for the search archive — a decision explained in full that a newcomer can find cold
- →Skip a week honestly rather than fake progress; a missing week is fine, a fabricated one is noise
How do you build in public without risking your job or your moat?
Two risks matter when you're employed: your company's policies and your own moat. Read your contract for IP-assignment and moonlighting clauses before you post a line of code, keep the project on personal hardware and personal accounts, and never share anything that reads as your day job's work. Separately, hold back the one genuinely hard part — the algorithm, the dataset, the integration that took weeks — because building in public does not mean handing a competitor your build instructions.
The safe and effective zone is your reasoning. Nobody can copy why you chose a niche or how you priced against churn, and that reasoning is precisely what an audience follows. Publish the decisions and outcomes generously; guard the specific mechanism and the confidential relationships. If a post would embarrass a customer, breach an NDA, or shorten a competitor's build time, it fails the test no matter how good the engagement would look.
For the bigger picture, read the career sovereignty guide for technologists, or jump straight to 12 ranked side-project ideas for senior technologists. To get new frameworks like this each week, subscribe to The Sovereign Technologist newsletter.
Frequently asked questions
Should I build in public before I have any traction or revenue?
Yes — the zero-to-one phase is the most followable part, because a story with no ending yet is what makes people subscribe. You don't need revenue to have substance: share the problem you picked and why, the pricing you're weighing, the first ten customer conversations. Waiting until you have impressive numbers means you build the entire audience-forming arc in private, then launch a finished product to nobody who watched it happen.
What if a competitor copies my idea because I shared it?
Ideas are cheap; execution, distribution, and the hard ten percent are not. Share the reasoning and the results, but hold back your actual moat — the algorithm, the dataset, the integration that took weeks. In practice, the audience you build by sharing is a bigger head start than the secrecy you'd gain by hiding, because attention is the one thing a competitor cannot clone just by reading your posts and copying your feature list.
How is building in public different from just marketing my product?
Marketing sells a finished thing; building in public documents an unfinished one, and the honesty is the whole point. You share decisions before you know whether they worked, failures with their real cost attached, and numbers that aren't flattering yet — which is exactly why people trust and follow it. Marketing broadcasts at buyers; building in public accumulates an audience invested in the outcome, some meaningful fraction of whom eventually become the buyers.
One framework. Every Thursday.
If this list was useful, the next one will be too. Subscribe and you’ll get the next agent-ready playbook the moment it ships.
Free. No spam. Currently read by 141+ senior technologists.