samber/developer-relations-skills已通过检查
SKILL DETAIL
build-in-public
samber/developer-relations-skills/build-in-public
Designs a sustainable build-in-public practice for an open-source project or developer tool: how far up the disclosure ladder to go (shipping log, decisions, failures, metrics, revenue), a cadence the maintainer can hold, the platform mix, and the boundaries that keep security, customer and roadmap detail off the public record. Use whenever someone mentions building in public, a devlog, weekly updates, an open-startup or transparency dashboard, sharing metrics or revenue openly, fear of copycats, oversharing, wanting to stop publishing numbers, or a stalled practice they want to restart, even if they never say "build in public". Covers solo maintainers, bootstrapped and funded devtools teams. Not for a one-time launch; use samber/developer-relations-skills@oss-launch.
安装量 · 405查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill build-in-public
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "build-in-public",
"evals": [
{
"id": 1,
"prompt": "I'm head of marketing at Lumenpath, a Series B payments-infrastructure company (we closed a $34M round last year, two institutional leads on the cap table). Our CEO read Buffer's open page over the weekend and now wants us to ship an equivalent by the end of Q1: live ARR, net revenue retention, and a salary band table for every engineering level, all on lumenpath.com/open. He's asked me to own it and he wants a plan by Friday. How would you build this out?",
"expected_output": "A response that treats the financial disclosure as legally constrained rather than a marketing choice, removes the open-startup dashboard from the option set entirely instead of ranking it last, redirects the CEO's ambition toward what a funded company can actually publish, and produces a charter rather than a content plan.",
"files": [],
"expectations": [
"Identifies that a venture-funded company generally cannot publish revenue because standard investor rights agreements impose confidentiality on company financials",
"States that revenue disclosure here is a legal question before it is a marketing one, and routes it through counsel rather than treating legal sign-off as a later formality",
"Removes the open-startup dashboard / financial disclosure from the option set entirely rather than ranking it last or listing it as a lower-priority option",
"Says explicitly which option was removed and why, instead of silently omitting it",
"Proposes what a funded company can publish instead, naming at least two of: culture, hiring, engineering process, fundraise news",
"States that a published salary structure requires the consent of the people it covers, and that an open-salary model is a formula applied to roles with everyone's consent rather than a license to disclose facts about identifiable individuals",
"If Buffer is discussed, describes it accurately as still publishing revenue, salaries and support metrics rather than as a company that abandoned the practice",
"If Gumroad or Sahil Lavingia is cited as a venture-backed founder who published financials, frames it as an exception that required renegotiating expectations, not as a template to copy",
"Describes the dashboard as a standing obligation rather than a project: a permanent comparison baseline, publication through bad quarters, and legal review before the first post",
"States the rule that a metric should only be published if the company is willing to keep publishing it while it declines",
"Does not offer a rounded band, a reporting delay, an aggregate or a disclaimer as a workaround for the confidentiality constraint",
"Produces or offers a written charter with named sections (goal, context, audience, rung, stop condition, boundaries, cadence, surfaces, measurement, pause rule) rather than a list of post ideas"
]
},
{
"id": 2,
"prompt": "I maintain queuelite, a Go job-queue library, 3.1k stars, entirely on my own alongside a full-time job. I'm speaking at a Go conference on 14 March and I'd like the project to look credible to the people in that room by then. Right now there's a CHANGELOG nobody reads and nothing else. Honestly, in a bad month I have about four hours for this. I was thinking a public dashboard: weekly download counts, contributor count, and my GitHub Sponsors income, updated every Friday. Good plan?",
"expected_output": "A response that deletes the dashboard on capacity grounds, states the ranking across disagreeing axes out loud, recommends a release-anchored shipping log tied to the March deadline, and sizes the cadence including reply load against the worst month, with a pause rule written up front.",
"files": [],
"expectations": [
"Deletes the open-startup dashboard from the options because the stated effort ceiling is single-digit hours per month, rather than ranking it last or leaving it on the list",
"States the efficiency ordering of the three practices explicitly in words - shipping log ahead of decisions-and-failures essays ahead of open-startup dashboard - rather than implying it by list order",
"Separates at least two axes that disagree, for example naming decisions-and-failures essays as the highest-value practice while the shipping log leads on efficiency",
"Recommends the release-anchored shipping log and justifies it by the artefact already existing: the effort is a link and a paragraph, not a new piece of work",
"Ties the recommendation to the 14 March deadline, on the grounds that a near date promotes the practice that publishes from work already done",
"Says explicitly which other practice loses and why, rather than presenting one option only",
"Sizes the cadence against the worst month rather than the current one",
"Budgets the reply load separately from the writing time, and notes that answering a thread usually costs more than producing the post",
"Applies a ceiling of roughly a tenth of available project time to the whole practice",
"Advises reducing frequency before reducing depth, for example one substantial monthly post over four thin weekly ones",
"Writes the pause rule into the plan now - the trigger, plus the sentence that announces the drop - rather than leaving it until something goes wrong",
"Warns that publishing a solo maintainer's sponsorship income invites entitlement from unpaid users alongside any funding upside",
"Names one anchor surface the project owns and treats any social channel as an amplifier pointing back to it"
]
},
{
"id": 3,
"prompt": "Someone emailed me privately yesterday about a heap overflow in my image library's EXIF parsing path. It's real, I reproduced it in ten minutes. For eight months I've run a 'debugging diaries' thread on the project account and this is genuinely the most interesting bug I've ever had. Plan: thread the hunt live as I work through it this week (without naming it as a security thing), then publish the full writeup when the patch ships. About 40k weekly downloads. Sound good?",
"expected_output": "A refusal of the live thread on coordinated-disclosure grounds, covering indirect disclosure through vague posts and commits, with the writeup permitted only after a fixed version exists and the release stating plainly that it contains a security fix.",
"files": [],
"expectations": [
"Refuses the live thread outright: nothing about an unfixed vulnerability goes public, including a post that never names it as a security issue",
"Covers indirect disclosure explicitly - a 'chasing a weird bug' post, a commit message, or a livestream of the fix all count as disclosure",
"Names coordinated disclosure as the governing norm: the report stays private and details are published only once a fixed version exists",
"Instructs that once the fixed release ships, the release notes say plainly that it contains a security fix so downstream users know to upgrade rather than treating it as an optional patch",
"Permits the full writeup only after the fixed version is available",
"Applies the pre-publish question about exposing an unfixed weakness directly or by hint",
"States that a disclaimer, vagueness or omitting the word 'security' does not neutralize the problem",
"Classifies this as a hard block rather than a grey zone needing a judgement call or a recorded decision",
"Does not offer an obfuscated, delayed-detail or anonymized version of the bug hunt as a compromise"
]
},
{
"id": 4,
"prompt": "We're four engineers at Tessellate, selling a self-hosted observability agent, about 60 paying teams on v2. Marketing wants a public roadmap page with quarters attached: Q2 v3 storage engine, Q3 managed cloud, Q4 v3 GA. Their argument is that enterprise buyers need to see we're serious and have a future. I'm the CTO, something about it bothers me and I can't articulate it. Tell me whether to do it.",
"expected_output": "A response that names the Osborne effect, rejects the dated entries for unshipped work, allows direction and sequencing without dates, specifies non-commitment language if a roadmap ships anyway, and answers the enterprise-buyer motive with operational evidence instead.",
"files": [],
"expectations": [
"Names the Osborne effect as the specific risk of announcing an unshipped successor while still selling the current version",
"Explains the mechanism: buyers defer or cancel purchases of the shipping product once its successor is announced",
"Cites the Osborne Computer Corporation 1983 precedent - prototype successors announced, dealers cancelled orders for the shipping machine, sales collapsed",
"Gives the rule: publish direction and sequencing, and attach dates only to work already shipping",
"Rejects the page as drafted, specifically the dated Q2/Q3/Q4 entries for unshipped work",
"If a roadmap is published anyway, requires explicit non-commitment language modelled on GitHub's public roadmap: subject to change, not a commitment guarantee obligation or promise, and not to be relied on for purchasing decisions",
"Classifies roadmap dates as a grey zone requiring a decision recorded in the charter rather than a reflex",
"Warns that a roadmap detailed enough to be useful can read as competitor intelligence",
"States that missed dates cost more credibility than the announced feature earns",
"Answers the enterprise-buyer motive with evidence a company evaluator actually uses - release cadence, response times, security handling, maintenance capacity - instead of dated promises"
]
},
{
"id": 5,
"prompt": "I run Fernbrook, a habit-tracking app, solo, $9,400 MRR. I post a revenue chart every month on X and honestly that has been my entire growth channel for two years. In the last six weeks three near-identical apps have appeared, one of them shipped with my exact onboarding copy. Everyone in my group chat says execution beats ideas and nobody can copy me. Do I stop posting numbers or is that just fear talking?",
"expected_output": "A response that refuses to settle the objection with the classic rebuttal, presents the current dated disagreement from both sides without declaring a winner, states the share-the-journey-not-the-playbook working rule, and converts the stop decision into a written pre-commitment.",
"files": [],
"expectations": [
"Does not settle the objection with the classic 'execution beats ideas / nobody can copy the you in your product' rebuttal alone",
"Presents the disagreement as currently open and does not declare either side to have won",
"Gives Arvid Kahl's 2026 reassessment, attributed and dated: agentic coding tools turn a publicly described architecture and feature set into a working competitor in days",
"States Kahl's specific claim that the old safety threshold of $20-30K MRR has collapsed to zero",
"Gives the counter-position that the barrier to a clone was always getting strangers to trust it, so distribution and trust remain the moat",
"States the working rule: share the journey and the reasoning, and keep the operational playbook, the exact architecture and the specific growth levers out of public writing",
"Distinguishes describing what you built (safe) from describing precisely how it wins (handing over a plan)",
"Notes that the working rule holds under either reading of the disagreement",
"Points at the four documented stop conditions (belittling by larger companies, copy and clone risk, the number reading as bragging past some size, the number no longer being a personal milestone once others are on the team)",
"Treats stopping as a pre-commitment written down in advance rather than a reaction to the current month",
"Warns that withdrawing a published number is itself a second public event, read defensively regardless of the real reason, not a neutral reset",
"Requires deciding now what stays published if the revenue chart is retired, rather than letting the chart go silently stale"
]
},
{
"id": 6,
"prompt": "Northgate Data - we sell a data-lineage tool, average contract around $48k a year. Our buyers are platform engineering leads at insurance and banking companies who then have to push it through procurement and a security review. We closed $610k ARR last year, up from $240k. Our founder wants that number published monthly on the website, his reasoning being that it proves we're real and growing fast. I run marketing and I have to give him an answer this week.",
"expected_output": "A response that identifies the company-adoption reader, warns that a small honest revenue number invites a vendor-viability objection in procurement, redirects to operational evidence, and requires consent plus a written stop condition before any number is published.",
"files": [],
"expectations": [
"Identifies the reader as a company-adoption evaluator who must convince an internal approver, not an individual adopter choosing for themselves",
"Warns that revenue disclosure can backfire here: a small honest number next to an incumbent invites a vendor-risk or vendor-viability objection during procurement",
"Recommends operational evidence over financial disclosure for this audience, naming release cadence, response times, security handling and maintenance capacity",
"Places the recommendation on the disclosure ladder explicitly, at operational metrics rather than financials",
"States that published financials cannot be unpublished and that the company would be measured against that baseline permanently",
"States the rule that a metric should only be published if the company will keep publishing it while it declines",
"Names what is identical regardless of which reader it is: the security boundary, the consent rules and the cadence math",
"Does not propose publishing ARR with added context, framing or a growth-rate emphasis as a way to neutralize the vendor-risk objection",
"Asks whose consent is required before publishing company numbers - co-founders, investors, customers - rather than assuming the founder can decide alone",
"Requires a stop condition written before the first publication, including what stays published if the revenue number is later withdrawn"
]
},
{
"id": 7,
"prompt": "I'm a backend engineer, six years in, trying to move into a staff role or land a DevRel job next year. My plan is to build in public. I've got a small side project, a Terraform linter with about 200 stars, and I want to post every single day about what I'm learning as I go - Rust, parser design, whatever I hit that week. Where do I start, and what should the first month look like?",
"expected_output": "A response that separates the three practices conflated under one name, identifies this as learning in public with the attribution, redirects toward a personal practice that keeps the project's numbers out of it, and challenges the daily cadence before designing anything.",
"files": [],
"expectations": [
"Distinguishes the three practices conflated under the same name: build in public, 'release early, release often', and 'learning in public'",
"Identifies what this user described as learning in public - a career practice about an individual developer's skill and reputation",
"Attributes learning in public to Shawn Wang (2018)",
"Attributes 'release early, release often' to Eric Raymond (1997) and describes it as an engineering practice aimed at code quality and contributor recruitment, needing a release process rather than a content cadence",
"Describes build in public itself as a marketing practice aimed at building an audience that becomes users, contributors or sponsors",
"Directs the user toward a personal-brand practice rather than designing a project practice around the Terraform linter",
"Advises keeping the project's numbers out of the personal practice",
"Confirms which practice is wanted before designing any cadence, disclosure rung or platform mix"
]
},
{
"id": 8,
"prompt": "Backstory: I maintain sift, a log-parsing tool, and last year I publicly committed to a Friday update every week. Made it to week 11, then a contract job ate my life. That was five months ago and the last post still says 'more soon'. Two people have opened issues asking whether the project is dead. It isn't - I've merged about thirty PRs since then, I just stopped writing. I want to start again in January. How do I do that without it collapsing again?",
"expected_output": "A restart plan built on one honest catch-up post and a cadence explicitly lower than the weekly one that broke, anchored to releases, sized to the worst month, with a pause rule written in advance.",
"files": [],
"expectations": [
"Prescribes a single catch-up post covering the gap honestly - what shipped, what stalled, what changed - rather than quietly resuming as if nothing happened",
"Sets the restart cadence explicitly lower than the weekly cadence that broke",
"States that restarting at the previous frequency usually reproduces the same collapse",
"Names the failure mode of the weekly-log pattern: the streak becomes the obligation and one miss feels terminal",
"Explains that an announced gap costs nothing while an unannounced one reads as abandonment and shows up in other people's adoption decisions",
"Re-sizes the new cadence against the worst month rather than a good one",
"Recommends a release-anchored cadence given the roughly thirty merged pull requests, because the material already exists",
"Writes a pause rule into the plan now, with both the trigger and the sentence that announces the drop",
"Does not prescribe more frequent posting, a public streak, or an accountability commitment as the fix",
"States that the silence rather than the inactivity produced the 'is it dead' perception, since the project kept shipping throughout"
]
},
{
"id": 9,
"prompt": "Corvid Labs, we build a CI caching service. We've been doing build-in-public posts for seven months, two a week, mostly written by me and our founding engineer. We're at 14.2k followers across two platforms and engagement looks fine. Our CFO asked me on Monday to show what it has returned and I genuinely don't know how to answer her. What should I be measuring, and what do I tell her?",
"expected_output": "A measurement answer that concedes attribution is narrative and promises signals not proof, instruments click-through per channel rather than followers, judges quarterly against the primary outcome with an explicit signal-to-ignore, and gives the self-set pass condition plus its two failure branches.",
"files": [],
"expectations": [
"States that attribution in this practice is narrative rather than instrumented, and promises signals rather than proof",
"Backs that honesty with the documented case of Alex Turnbull, whose Groove transparency blog is a canonical success story and who later admitted he never looked at a metric for three years",
"Rejects follower count explicitly as a measure of whether the practice works",
"Prescribes instrumentation from day one regardless: tagged links, privacy-friendly analytics, and click-through to signup or waitlist tracked per channel",
"Sets the review period at quarterly and states that the practice compounds too slowly to read week to week",
"Judges the practice against the primary outcome chosen at the start rather than a generic engagement dashboard",
"Pairs each outcome with a signal to ignore - stars, followers, impressions or reach - not only with a signal that counts",
"Diagnoses a large audience that does not convert as missing channel-offer fit rather than insufficient effort, attributed to Jason Leow",
"Gives the reallocation rule: if engagement-to-signup conversion stays near zero across two to three months, treat the practice as a community and accountability tool and reallocate the time",
"States the pass condition as self-set rather than an industry benchmark, and notes that no public dataset gives realistic build-in-public conversion rates",
"Gives the three-part quarterly pass condition: at least one named outcome moved, the cadence was met, and no boundary rule was breached",
"Gives both failure branches in the right order - cadence met but nothing moved for two consecutive quarters means change the rung or the surface rather than posting more; cadence missed means cut the cadence before changing anything else"
]
},
{
"id": 10,
"prompt": "Rough morning. We shipped 4.2 of our SDK on Tuesday and it double-charged webhook retries for anyone on the async client with a custom retry policy. About 300 accounts affected, one customer got billed six times over for a day. It's fixed in 4.2.1 as of an hour ago and refunds are going out. Our support lead wants to email only the affected accounts and say nothing publicly. Our CEO wants a blog post. We've published openly for two years. What do we do, and if we post, what does it actually say?",
"expected_output": "A recommendation to publish first and publicly, in one place, structured impact then cause then systemic change, with no individual blame, a stated next-update date, and a rule for handling replies and later corrections.",
"files": [],
"expectations": [
"Recommends publishing it publicly and first, on the company's own terms, rather than emailing affected accounts only",
"States that the same news extracted or surfaced by someone else is far more expensive than publishing it yourself",
"Specifies the order: impact on the reader first, then cause, then what changes systemically, and explicitly rejects the reverse order",
"Requires the impact stated in terms a reader can check against their own account or installation",
"Requires saying what is not yet known and when the next update lands, then meeting that date",
"Prohibits blame of individuals, vendors or contributors, and requires a systemic description instead",
"Publishes once, in full, in one place, with replies linking back to it rather than relitigating the same point across threads",
"Instructs to answer the strongest objection once, in public, and never to argue the same point across many threads",
"Requires any later correction to be published at the same prominence as the original claim, never as a reply to a stale post",
"Distinguishes live-incident status updates, which belong on a status page, from analysis, which belongs in a postmortem once causes are confirmed",
"Requires the post to name a systemic change to the release or testing process, not only the patched version"
]
},
{
"id": 11,
"prompt": "Solo founder here, Palisade Analytics, privacy-first product analytics, 40 paying customers. Everything I've published for a year lives on my X account - the roadmap is a pinned thread, I post numbers there, people ask support questions in the replies. I've drafted one milestone post about hitting 40 customers and I want to push the identical text to X, LinkedIn, Hacker News, r/SaaS and my newsletter this week. Sanity check me before I hit send.",
"expected_output": "A rejection of the identical cross-post with per-channel rewriting, a named owned anchor surface with the social accounts demoted to amplifiers, the specific failure mode of each proposed channel, and a verifiability requirement on the customer count.",
"files": [],
"expectations": [
"Rejects posting identical text across the five surfaces and requires rewriting per channel",
"States that different post types are different genres rather than one asset reshaped for each platform",
"Names one anchor surface the project owns - changelog, blog or newsletter - and demotes the social channels to amplifiers pointing back to it",
"Gives the reason owned surfaces matter: the archive survives a platform decaying or an account being lost",
"Flags living entirely on one social platform as a failure mode: no archive, no search surface, and one account suspension away from losing the whole practice",
"Warns that Hacker News and Reddit actively punish marketing language, hype and unverifiable metrics",
"Warns that LinkedIn punishes casual indie tone and naked metric-flexing",
"Advises using only channels the founder actually reads and where this audience already evaluates tools",
"Notes that no single post carries a funnel because of the short half-life of a social post, so cadence and repurposing do the work",
"If a post half-life figure is cited, gives the measured median of roughly 80 minutes from Twitter impression data (Pfeffer, Matter and Sargsyan, ICWSM 2023) and does not present the 18-24 minute engagement-proxy figure as the measured one, explaining that the two measure different things",
"Requires a published customer count to come from a source the reader can verify rather than an unverifiable screenshot",
"Requires public posts to link back to the owned artifact rather than duplicating it, so a correction has one place to be made",
"Flags the roadmap living as a pinned social thread as a problem separate from the cross-posting question"
]
},
{
"id": 12,
"prompt": "Since I started posting weekly about mesh-router (my Rust service-mesh sidecar) six months ago, stars went from 900 to 6.8k and open issues went from 14 to 180. Contributors are still basically me plus one person who shows up occasionally. My DMs are full of feature requests. I've also been publishing my sponsorship income, which is now about 310 EUR a month, and two separate people have told me I 'owe' them fixes because of it. I don't want to stop posting but this is not sustainable.",
"expected_output": "A response that reads issue volume outpacing contributor count as the signal to pause posting and fix artifacts, publishes availability and scope, routes requests off DMs, and connects the published income directly to the entitlement being experienced.",
"files": [],
"expectations": [
"Reads issue volume growing faster than contributor count as the named signal to pause posting and fix an artifact instead of publishing more",
"Prescribes publishing availability and scope where arriving readers see them - README and community health files - rather than only responding faster",
"Routes feature requests off DMs and into a public channel so each answer is reusable",
"Declines out-of-scope work by pointing at the written scope rather than deciding case by case",
"Connects the published sponsorship income directly to the entitlement the user is experiencing: published maintainer income invites entitlement from unpaid users",
"Requires pairing any income disclosure with a published statement of what maintenance the money does and does not buy",
"Treats stars as proving nothing about adoption and pairs or replaces them with contributor, download or retention movement",
"Does not recommend posting more, or asking the audience for contributors, as the primary fix for the support load",
"Frames the practice as a budget rather than a growth channel, because the attention it buys arrives as issues, questions and opinions in the same place the maintainer ships from",
"Offers a cadence reduction or pause that is announced in a sentence rather than a silent fade-out"
]
}
],
"trigger_queries": [
{ "query": "I want to start building in public for my open-source CLI tool", "should_trigger": true },
{ "query": "Should I put my MRR on my landing page?", "should_trigger": true },
{ "query": "how do I run a devlog for my side project without burning out", "should_trigger": true },
{ "query": "we want an open startup page like Buffer's", "should_trigger": true },
{ "query": "is it actually safe to share my revenue numbers publicly", "should_trigger": true },
{ "query": "people clone my app every time I post a screenshot of my numbers", "should_trigger": true },
{ "query": "I haven't posted an update about my project in four months and now it looks abandoned", "should_trigger": true },
{ "query": "what should I share publicly about my startup and what should I keep private", "should_trigger": true },
{ "query": "help me set a weekly update rhythm for my repo that I can actually hold", "should_trigger": true },
{ "query": "I want to stop publishing my revenue but I'm afraid of how it will look", "should_trigger": true },
{ "query": "transparency dashboard for our company", "should_trigger": true },
{ "query": "how much of our roadmap should be public", "should_trigger": true },
{ "query": "our CEO wants to publish everyone's salaries on the website", "should_trigger": true },
{ "query": "I'm a solo maintainer, should I show how much sponsorship money I get", "should_trigger": true },
{ "query": "write me a plan for sharing progress on this project every week", "should_trigger": true },
{ "query": "build in public strategy", "should_trigger": true },
{ "query": "which platform should I post my project updates on", "should_trigger": true },
{ "query": "is building in public worth it or is it just survivorship bias", "should_trigger": true },
{ "query": "I want to document the journey of building my SaaS", "should_trigger": true },
{ "query": "can I livestream myself fixing this bug someone reported to me privately", "should_trigger": true },
{ "query": "my weekly update streak broke at week nine and I just stopped entirely", "should_trigger": true },
{ "query": "how do I announce that I'm pausing my public updates", "should_trigger": true },
{ "query": "we're Series A, can we publish ARR", "should_trigger": true },
{ "query": "open startup", "should_trigger": true },
{ "query": "I want to share the decisions behind our architecture openly to attract contributors", "should_trigger": true },
{ "query": "how often should I post progress updates about my library", "should_trigger": true },
{ "query": "a post about my project got piled on, what do I do now", "should_trigger": true },
{ "query": "should I publish a postmortem for yesterday's bad release or just email the affected users", "should_trigger": true },
{ "query": "I've got 12k followers from posting about my product and zero signups", "should_trigger": true },
{ "query": "do I need to tell people this release contains a security fix", "should_trigger": true },
{ "query": "plan for sharing our engineering work openly to help recruiting", "should_trigger": true },
{ "query": "I'd like readers to follow along as I build this over the next year", "should_trigger": true },
{ "query": "public roadmap with quarters attached, good idea or not", "should_trigger": true },
{ "query": "what numbers are safe to publish as a bootstrapped founder", "should_trigger": true },
{ "query": "I want to be more open about how my company actually operates", "should_trigger": true },
{ "query": "designing a devlog cadence I can actually hold through a bad month", "should_trigger": true },
{ "query": "should we keep posting our metrics now that the numbers are going down", "should_trigger": true },
{ "query": "my co-founder wants to tweet our churn rate", "should_trigger": true },
{ "query": "how do I get contributors by writing about my mistakes", "should_trigger": true },
{ "query": "setting boundaries on what I share about my project online", "should_trigger": true },
{ "query": "our investors won't let us publish financials, what can we publish instead", "should_trigger": true },
{ "query": "should I do a launch week like Supabase or just post continuously all quarter", "should_trigger": true },
{ "query": "how do I write down what my project will and won't share publicly", "should_trigger": true },
{ "query": "publishing our numbers openly, pros and cons", "should_trigger": true },
{ "query": "I took down my public MRR page last month, should I say something about it", "should_trigger": true },
{ "query": "sharing our wins and our failures publicly as a devtools company", "should_trigger": true },
{ "query": "what happens if I publish revenue and then have a terrible quarter", "should_trigger": true },
{ "query": "is there any framework for deciding how transparent to be about my startup", "should_trigger": true },
{ "query": "if I start posting weekly updates will I get swamped with issues, and how do I plan for that", "should_trigger": true },
{ "query": "I want to post publicly about what I'm learning while building my product", "should_trigger": true },
{ "query": "how should my changelog and my public progress posts relate to each other", "should_trigger": true },
{ "query": "we want to be radically transparent as a company", "should_trigger": true },
{ "query": "day one of building in public, what do I actually post", "should_trigger": true },
{ "query": "my failure posts get way more traction than my launch posts, should I lean into that", "should_trigger": true },
{ "query": "someone built a competitor straight off our public roadmap", "should_trigger": true },
{ "query": "how do I decide what stays private when I share my progress", "should_trigger": true },
{ "query": "sustainable transparency practice for a two-person devtools team", "should_trigger": true },
{ "query": "I promised weekly updates and I can't keep up with them", "should_trigger": true },
{ "query": "we publish a live metrics page and I'm starting to regret it", "should_trigger": true },
{ "query": "should the project blog or my personal account be the main place I post", "should_trigger": true },
{ "query": "write the release notes for v2.4 from these merged PRs", "should_trigger": false },
{ "query": "turn this commit range into a CHANGELOG entry following Keep a Changelog", "should_trigger": false },
{ "query": "we're open-sourcing this repo next Thursday, plan the launch", "should_trigger": false },
{ "query": "how do I get onto GitHub Trending on launch day", "should_trigger": false },
{ "query": "design our GitHub Sponsors tier ladder and rewards", "should_trigger": false },
{ "query": "which open-source projects should our company fund and at what amount", "should_trigger": false },
{ "query": "plan next quarter's devrel content calendar with owners and deadlines", "should_trigger": false },
{ "query": "write an engineering blog post about why we rewrote the indexer in Rust", "should_trigger": false },
{ "query": "how should we measure our DevRel program overall", "should_trigger": false },
{ "query": "build a tracking plan and event taxonomy for our docs and repo", "should_trigger": false },
{ "query": "our issue tracker is out of control, design a triage system", "should_trigger": false },
{ "query": "rewrite our README so a stranger can run the first command in under a minute", "should_trigger": false },
{ "query": "optimize my GitHub profile README and pick my six pinned repos", "should_trigger": false },
{ "query": "should we start a Discord for our users or is it too early", "should_trigger": false },
{ "query": "write our code of conduct and the moderation escalation ladder", "should_trigger": false },
{ "query": "which open-source license should we pick for this library", "should_trigger": false },
{ "query": "where do we draw the open-core line between free and paid", "should_trigger": false },
{ "query": "who decides what gets merged here, we need a GOVERNANCE.md", "should_trigger": false },
{ "query": "how should we price and package our developer tool", "should_trigger": false },
{ "query": "open core or dual licensing, which business model fits us", "should_trigger": false },
{ "query": "write a technical case study about how Acme deployed us in production", "should_trigger": false },
{ "query": "pitch this release to journalists and set up an embargo", "should_trigger": false },
{ "query": "prep me for a technical podcast interview next week", "should_trigger": false },
{ "query": "design our employer brand so we can hire more backend engineers", "should_trigger": false },
{ "query": "my conference talk got accepted, help me outline it", "should_trigger": false },
{ "query": "write a CFP submission for the platform engineering track", "should_trigger": false },
{ "query": "script a screencast demo of our API with a 30-second hook", "should_trigger": false },
{ "query": "write the migration guide for our v3 breaking changes", "should_trigger": false },
{ "query": "audit our docs structure against Diataxis and find the misplaced pages", "should_trigger": false },
{ "query": "write a quickstart that gets a developer to first success", "should_trigger": false },
{ "query": "our documentation doesn't rank in Google search", "should_trigger": false },
{ "query": "cut our developer audience into named segments and size them", "should_trigger": false },
{ "query": "map the developer journey from discovery through to advocacy", "should_trigger": false },
{ "query": "benchmark a competitor's developer relations motion against ours", "should_trigger": false },
{ "query": "how do I get hired as a developer advocate", "should_trigger": false },
{ "query": "write a job posting and interview loop for a developer advocate", "should_trigger": false },
{ "query": "should devrel report to marketing or to product", "should_trigger": false },
{ "query": "split our devrel budget across events, content and community", "should_trigger": false },
{ "query": "design an ambassador program with perks and selection criteria", "should_trigger": false },
{ "query": "plan a recurring monthly developer meetup in Lyon", "should_trigger": false },
{ "query": "which conferences should we sponsor and at which tier", "should_trigger": false },
{ "query": "make our SDK docs readable by coding agents", "should_trigger": false },
{ "query": "design the go-to-market motion for our developer product", "should_trigger": false },
{ "query": "should we build a certification program for our platform", "should_trigger": false },
{ "query": "rehearse the failure modes in my live demo and build a fallback", "should_trigger": false },
{ "query": "how should we engage with the OpenTelemetry spec process", "should_trigger": false },
{ "query": "design the path from stranger to first merged pull request", "should_trigger": false },
{ "query": "where should we distribute our library after launch, registries and curated lists", "should_trigger": false },
{ "query": "write a tutorial that teaches Kafka by building a chat app", "should_trigger": false },
{ "query": "turn our support tickets into troubleshooting and error-reference pages", "should_trigger": false },
{ "query": "which error strings do developers actually search for", "should_trigger": false },
{ "query": "set standards for the code samples in our documentation", "should_trigger": false },
{ "query": "measure the health of our Discord community", "should_trigger": false },
{ "query": "should we open extension points so partners can build on our platform", "should_trigger": false },
{ "query": "write a press release for our funding round", "should_trigger": false },
{ "query": "plan our Product Hunt launch day", "should_trigger": false },
{ "query": "set up an automated changelog generator from conventional commits", "should_trigger": false },
{ "query": "build a startup metrics framework with CAC, LTV and burn multiple", "should_trigger": false },
{ "query": "build a financial model for the next 18 months of runway", "should_trigger": false },
{ "query": "apply lean startup MVP validation to this product idea", "should_trigger": false }
]
}
references/boundary-rules.md›
# Boundary rules
What never gets published, what needs a deliberate call, and the check that runs before every post.
## Contents
- [Hard blocks](#hard-blocks)
- [Grey zones](#grey-zones)
- [Pre-publish check](#pre-publish-check)
- [Publishing bad news](#publishing-bad-news)
## Hard blocks
**Unpatched vulnerabilities.** Coordinated disclosure is the ecosystem norm: the initial report stays private and full details are published only once a fixed version exists. Nothing about an unfixed weakness goes public - not a commit message, not a "chasing a weird bug" post, not a livestream of the fix. After the fixed release ships, say plainly that it contains a security fix, so downstream users know to upgrade rather than treating it as an optional patch.
**Customer and user data.** Named customers, logos, per-account usage, screenshots containing real accounts - every one needs explicit permission, including inside an aggregate dashboard.
**Employee data.** Individual salaries, performance, health, departures. Open-salary models work because a published formula is applied to roles with everyone's consent; they are not a license to disclose facts about a person.
**Material non-public information.** With outside investors, an acquisition process, or a public-company parent, disclosing revenue, forecasts or customer counts is a legal question before it is a marketing one. Route it through counsel.
**Third-party confidential material.** Partner architecture, unreleased vendor features, NDA'd terms, embargoed private-beta content.
**Live incidents, before the facts are established.** Status updates belong on a status page; analysis belongs in a postmortem once causes are confirmed. Public mid-incident speculation creates a second incident.
**Team conflict.** Airing internal disagreement damages the people in it and deters contributors, and teaches the audience nothing transferable.
## Grey zones
These need an explicit decision, recorded in the charter, not a reflex.
**Unshipped features and dates.** The named risk is the Osborne effect: customers canceling or deferring orders for the current product after a premature announcement of its successor. The Osborne Computer Corporation announced prototype successors in 1983; dealers canceled orders for the shipping machine, and sales collapsed.
If a roadmap is published anyway, publish it with explicit non-commitment language, following GitHub's public roadmap:
- "is subject to change, especially further out on the timeline"
- "does not represent a commitment, guarantee, obligation or promise to deliver any product or feature, or to deliver any product and feature by any particular date"
- customers should not rely on it for purchasing decisions
Copy that pattern: direction and sequencing in public, dates only for work already shipping.
**Revenue as a solo maintainer.** Publishing income attracts sponsorship and entitlement in the same motion ("you earn this much, fix my issue"). Decide whether the funding upside outweighs the shift in support expectations, and pair any disclosure with a published statement of what maintenance the money does and does not buy.
**Competitive strategy.** Describing what you built is usually safe. Describing why it wins, where the moat is, and what you will build next hands a plan to a better-resourced competitor.
**Hiring, layoffs, departures.** Legally constrained in most jurisdictions and involving people who never opted into the practice. Announce facts the people involved have approved, and nothing else.
**Numbers that look small.** Not a risk category on its own - small honest numbers with a trajectory beat vague claims. The risk is publishing one flattering slice and being asked for the rest.
## Pre-publish check
Run four questions against every post, including replies written in a hurry:
1. Does this expose an unfixed security weakness, directly or by hint?
2. Does this contain a third party's data, name, or confidential material without consent?
3. Does this commit us to a date, number, or feature we do not control?
4. Would this sentence be a problem if a competitor, a journalist, or a hostile commenter quoted it alone?
Any yes means rewrite or delay. A disclaimer does not neutralize a yes.
## Publishing bad news
Bad news published on your own terms is the highest-value content the practice produces; the same news extracted by someone else is the most damaging.
- Publish once, in full, in one place, and link every reply to it rather than relitigating in threads.
- Lead with impact on the reader, then cause, then what changes - never the reverse order.
- Say what is not yet known and when the next update lands, then meet that date.
- Skip blame of individuals, vendors, or contributors; systemic description survives scrutiny, personal attribution does not.
- Never post a correction as a reply to a stale post: publish it at the same prominence as the original claim.
references/cadence-patterns.md›
# Cadence patterns
Five sustainable shapes for the practice, how to size one against real capacity, and how to pause without signalling death.
## Contents
- [The patterns](#the-patterns)
- [Capacity math](#capacity-math)
- [Repurposing loop](#repurposing-loop)
- [Pause and restart](#pause-and-restart)
## The patterns
| Pattern | Shape | Fits | Breaks when |
| --------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------- | --------------------------------------------------------------------------- |
| Release spine | One post per release, no release no post | Any project with a real release rhythm | Releases become rare; the practice disappears with them |
| Weekly log | Fixed-day short update: shipped / learned / stuck / next | Solo maintainers building an audience habit | The streak becomes the obligation and one miss feels terminal |
| Batched event | Announcements concentrated into a launch week, one headline item per day | Teams with several shippable items per quarter | Between events, the project looks silent for months |
| Periodic report | Monthly or quarterly long post: metrics, decisions, misses | Rung 4-5 disclosure; teams with reporting already in place | Written the day before with numbers nobody has verified |
| Daily micro-log | Short daily notes from the work itself | Full-time solo builders with an existing audience | The maintainer also reviews PRs and answers issues - which is almost always |
The release spine is the safest default for a maintainer: the material already exists, the cadence follows the work, and quiet periods degrade gracefully instead of producing filler.
Batching is a real strategic option, not a compromise. Concentrating a quarter of scattered updates into one dated event produces an attention spike that a drip never reaches - Supabase's Launch Week runs five days with one main-stage announcement per day plus additional releases, a hackathon and meetups attached. The cost is accepting long public silence between events, which only works when releases keep flowing in the repository meanwhile.
## Capacity math
Estimate honestly, in minutes:
```
per post = drafting + screenshots/demo + review + boundary check
per cycle = per post × posts per cycle
reply load = per post × expected threads × minutes per reply # usually the larger number
```
Then apply two rules.
- **The tenth.** A self-set working baseline, not a measured benchmark: if the practice consumes more than roughly a tenth of the maintainer's available project time, it is competing with the work it narrates. Reduce frequency before reducing depth - one substantial monthly post beats four thin weekly ones.
- **The worst month.** Choose the cadence the worst month can sustain, then over-deliver in good months. A published cadence is a promise; repeatedly missing it reads as project decline - the exact signal the practice exists to prevent.
## Repurposing loop
One piece of real work should feed several surfaces without being rewritten:
```
release notes / ADR / postmortem (source of truth, in the repository)
└─> short post on the anchor surface
└─> social amplification, per-channel format
└─> entry in the periodic report
└─> talk, stream or article material
```
Public posts link back to the repository artifact rather than duplicating it, so a change has one place to be corrected.
## Pause and restart
Announce pauses; never fade out. State the reason, the expected return, and where releases stay visible in the meantime.
An announced eight-week gap costs nothing. An unannounced one is read as abandonment and shows up in other people's adoption decisions.
Restarting after a long silence works best as a single catch-up post that covers the gap honestly - what shipped, what stalled, what changed - and then a lower cadence than the one that broke. Restarting at the old frequency usually reproduces the same collapse.
references/context-variants.md›
# Context variants, stop conditions and objections
The same disclosure decision has different answers depending on who else has a claim on the numbers. This file covers that fork, the documented procedure for deciding when to stop, and the objections a user will raise.
## Contents
- [Who else has a claim](#who-else-has-a-claim)
- [The stop test](#the-stop-test)
- [The reversal wave](#the-reversal-wave)
- [The clone-theft objection](#the-clone-theft-objection)
- [Verifiability and transparency theater](#verifiability-and-transparency-theater)
- [Survivorship bias](#survivorship-bias)
## Who else has a claim
| Dimension | Funded startup | Bootstrapped company | Solo maintainer |
| ------------------------ | ---------------------------------------------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Who owns the practice | Founder plus marketing or DevRel; often a community manager | Founder, sometimes with one marketing hire | The maintainer, personally |
| Review before publishing | Legal and comms review; board and investor sensitivity | Founder's discretion | None |
| Revenue disclosure | Generally not available | Common, and treated as a channel | Rare; sponsorship totals more often than income |
| What gets shared instead | Culture, hiring, engineering process, fundraise news | Revenue, churn, roadmap, mistakes | Changelogs, roadmaps, RFCs, release notes |
| Primary goal | Recruiting, employer brand, category credibility | User acquisition, credibility, audience as moat | Contributors, sponsorship, adoption |
| Characteristic failure | Competitive leak; narrative anchored to a founder who may leave; investor friction | Copycats; the stress of live numbers; burnout | Entitlement from unpaid users; burnout; conflating code transparency with personal-finance transparency |
**Why funded companies usually cannot publish revenue.** Standard investor rights agreements grant information rights and impose confidentiality on company financials, which makes revenue disclosure a legal question before it is a marketing one. Gumroad's Sahil Lavingia is the documented exception - a venture-backed founder who published detailed financials and recorded public board meetings - and it followed an explicit strategic pivot away from growth-at-all-costs. Treat it as an exception that required renegotiating expectations, not a template.
**Why bootstrapped companies can treat revenue as a channel.** Plausible Analytics published "How we built a $1M ARR open source SaaS", with a timeline of milestones after launching paid subscriptions in May 2019:
- 324 days to reach the first $400 MRR
- nine months to go from $400 to $10,000 MRR
- $1M ARR reached on 2 June 2022
Arvid Kahl credits transparent revenue sharing with helping sell FeedbackPanda.
**Why the solo-maintainer case is a different axis entirely.** Transparency about code is already the OSS norm and contributors expect it. Transparency about the maintainer's own time and money is not, and it changes the relationship: published income invites entitlement ("you make this much, fix my issue").
GitHub reports more than $100 million routed to maintainers through Sponsors since 2019, across over 70,000 maintainers, while still describing the funding gap as enormous and maintainer burnout as one of the biggest supply-chain risks. Artem Sapegin's "Why I quit open source" is the counter-narrative worth reading before assuming visibility converts to funding.
## The stop test
There is no rigorous, widely adopted framework for choosing a disclosure level - this is a genuine gap in the practitioner literature, not something to paper over with a confident-sounding checklist. The closest thing to a documented procedure is Damon Chen's essay "The golden era of being an open startup is gone", which gives four stop conditions:
1. Larger companies belittle you once they know your numbers are small.
2. It raises copy and clone risk.
3. Above some threshold it stops inspiring anyone and starts reading as bragging.
4. It stops being a personal milestone once other people are on the team.
Chen's own case demonstrates the fourth directly: he stopped because "with someone else on my team, it's no longer my personal milestone anymore." Jon Yongfook articulated the underlying curve in 2022: the higher your open revenue, the fewer people it benefits and the more risk you take on.
Use the test the way it was written - as a stop condition set before starting, recorded in the charter, so the decision to stop is a pre-commitment rather than a reaction to a bad month.
## The reversal wave
Between 2022 and 2024 a large share of the practice's most visible practitioners withdrew revenue disclosure. This is the strongest evidence available on how the decision actually plays out.
- **Jon Yongfook (Bannerbear)** removed public revenue and his live MRR Twitter-bio bot on 5 February 2024: "when your numbers are live for the world to see, the level of stress and dread is amplified 10x. You feel like you're a failure and everyone can see it." The page now says the company shares only selected metrics.
- **Danny Postma** (January 2024) listed his reasons: bragging, competitive disadvantage, personal safety, damaged relationships, and numbers that don't tell the full story.
- **Pieter Levels** removed his open pages in late 2022, citing security.
- **Tony Dinh** removed his public revenue bar in October 2022 on personal-safety grounds. He has also defended revenue sharing at other times - a nuanced case, not an opponent.
- **Damon Chen** removed his revenue bar in October 2022 and wrote the essay above.
- **Francesco Di Lorenzo (Typefully)** stopped and then resumed in January 2024, once the product was solid and pricing had raised the barrier for copycats. The only documented reversal of a reversal.
- **Buffer did not reverse.** The pioneer that started the pattern in 2013 with open salaries still publishes revenue, salaries and support metrics. Cite it whenever someone concludes the practice is discredited.
Yongfook also reported that going dark was itself stressful. Reversal is a second public event, not a neutral reset - which is the practical argument for starting narrower than feels natural instead of planning to widen later.
## The clone-theft objection
The dominant practitioner rebuttal is that execution beats ideas - the Rework line "competitors can never copy the you in your product" is the usual citation, and KP reframes the fear as a readiness test rather than a risk assessment.
The objection is not imaginary, though. Baremetrics reported roughly a dozen copycat businesses. Sebastian Röhl (HabitKit) posted on 3 February 2024: "Every time I post a MRR chart, a whole bunch of new habit trackers with a very similar concept to @HabitKit pop up. At what point would you stop sharing your numbers?"
On the other side, Wise published a full public roadmap in May 2021 and succeeded anyway, at real scale.
**The 2026 reassessment is the part that changes the advice.** Arvid Kahl, writing in 2026: "Building in public once helped me sell my company. Today, that same transparency could destroy yours." His argument is that agentic coding tools turn a publicly described architecture and feature set into a working competitor in days, and that "the old safety threshold of $20-30K MRR has collapsed to zero." A counter-analysis argues the real barrier was always getting strangers to trust the clone, so distribution and trust remain the moat regardless of build speed.
Both positions point at the same working rule: assume the visible surface can be cloned quickly, and compete on distribution, trust and switching costs.
- Share the journey and the reasoning behind decisions.
- Keep the operational playbook, the exact architecture and the specific growth levers out of public writing.
Describing what you built is safe. Describing precisely how it wins is not.
## Verifiability and transparency theater
Fear of disclosure plus appetite for social proof produces a predictable distortion: fabricated numbers. Screenshot-faking services exist, and a verified-revenue product (TrustMRR, launched 31 October 2025 after a viral post about fake MRR screenshots) exists as the market's countermeasure. The consequence for anyone publishing real numbers is that proof now beats polish - a bare screenshot reads as more likely fake than impressive, so publish from a source the reader can verify or don't publish the number.
## Survivorship bias
The visible winners of this practice obscure a much larger mass of quiet failures. Named skeptics:
- Jason Leow - "Building in public is overrated... It's just ONE tool amongst many"
- Krzysztof Kowalczyk - on the survivorship framing of the movement's most-cited success stories
- Arvid Kahl - on himself, that building in public "is a performance... artificial and strategic."
Leow's specific warning is the useful one to pass on: newcomers "build in public, tweet daily, and burn out because of low returns on that investment in time and energy, when the channel-offer fit isn't there." Channel-offer fit, not effort, decides whether it pays.
references/disclosure-ladder.md›
# Disclosure ladder
The five rungs a project can climb, what each one buys, what it obligates, and how real projects have positioned themselves.
## Contents
- [The rungs](#the-rungs)
- [Choosing a rung](#choosing-a-rung)
- [Reference positions](#reference-positions)
- [The ratchet](#the-ratchet)
## The rungs
| Rung | What you publish | What it buys | What it obligates |
| ---------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------- |
| 1. Shipping log | Releases, merged work, fixes | Proof of life; adoption confidence | Keep shipping, or the silence is visible |
| 2. Decisions | Architecture choices, rejected options, scope cuts, license and pricing changes | Technical credibility; fewer "why did you…" issues | Explain the next reversal too |
| 3. Failures | Outages, bad releases, wrong bets, postmortems | The highest trust-per-word available | Publish the uncomfortable ones, not only the flattering ones |
| 4. Operational metrics | Downloads, installs, contributors, response times, uptime | Momentum evidence a buyer or contributor can check | A baseline you will be compared against forever |
| 5. Financials | MRR/ARR, churn, salaries, runway, sponsorship income | Maximum attention; sponsorship and hiring pull | Publishing the bad quarters; legal review; changed negotiating position |
Rungs are cumulative in practice: nobody publishes revenue while hiding releases.
## Choosing a rung
The default ranking lives in `SKILL.md` step 2 - efficiency: `shipping log > decisions-and-failures essays > open-startup dashboard`. The list below is not a second order; it is the set of conditions under which the stated outcome overrides that default.
- **Want adoption?** Rungs 1-2. Evaluators want evidence the project is alive and thought through.
- **Want contributors?** Rungs 1-3. Visible reasoning and visible failure are what convince a stranger they could help.
- **Want sponsors or funding?** Rungs 3-4, and rung 5 only if the numbers argue for you. Sponsors fund a project whose need and trajectory are legible.
- **Want a hiring or credibility signal for yourself?** Rungs 2-3 carry it; metrics rarely do.
- **Selling to companies?** Rung 4 helps procurement (maturity, responsiveness); rung 5 can hurt if the numbers look small next to an incumbent.
Two constraints override the preference:
1. **Capacity.** Rung 3 needs writing time when things are going badly - exactly when there is least of it.
2. **Consent.** Rungs 4-5 usually involve data belonging to co-founders, investors, employees or customers. Get agreement before the first publication, not after the first complaint.
## Reference positions
Verified 2026-08-26.
- **Buffer** (`buffer.com/open`) - the widest published set in practice: monthly active users, MRR, ARR, ARPU, monthly shareholder updates, individual and executive salaries, support response times and satisfaction, public roadmap, time-off policy. Stated purpose: "to build trust, hold us accountable to a high standard, and push our industry forward."
- **Ghost** (`ghost.org/about`) - a live financial feed: ARR, monthly run rate, net churn, active customers, monthly requests, GitHub stars, install count, framed as accountability for a non-profit organization.
- **Baremetrics Open Startups** (`baremetrics.com/open-startups`) - a directory of companies publishing monthly revenue; rung 5 as a shared benchmark rather than a solo dashboard.
- **Plausible** (`plausible.io/about`) - deliberately lower: fully public AGPLv3 source ("the code is public and auditable"), milestone-only revenue disclosure, no live financial dashboard. Accountability through auditable code rather than a metrics feed.
Plausible is the counter-example worth quoting to anyone who thinks building in public means publishing revenue: a project can be radically transparent about how it works and reticent about how much it makes.
## The ratchet
Published numbers cannot be unpublished, and two effects follow.
- **Silence reads as bad news.** A dashboard that goes stale after a bad quarter tells the story anyway, in the least flattering form. Only publish a metric you are willing to publish while it declines.
- **Climbing down costs more than never climbing.** Removing a salary or revenue page invites the question of what changed. Choose the rung the project can hold through a bad year - not the one that performs best this month.
Rungs 1-3 are recoverable: nobody audits whether a postmortem appeared last quarter. Rungs 4-5 are not.
references/platform-norms.md›
# Platform norms
Build-in-public content does not transfer between platforms. Each has a distinct audience, an accepted format, and a specific way that a badly matched post fails.
## Contents
- [The table](#the-table)
- [Mechanics worth knowing](#mechanics-worth-knowing)
- [Choosing the mix](#choosing-the-mix)
## The table
| Platform | Audience | Accepted format | What fails there |
| ------------------------------ | --------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| X / Twitter | Indie hackers, founders, makers | Revenue-dashboard screenshots, milestone posts, weekly recaps, "day N of building X" threads | Corporate PR tone, no personality, pure promotion; unverified revenue claims now draw skepticism rather than applause |
| Indie Hackers | Bootstrappers | Milestone write-ups ("how I got X to $Y MRR"), AMAs, forum threads with real numbers | Thin self-promotion with no lesson attached; VC-scale bragging |
| LinkedIn | Operators, B2B buyers, executives | Founder-led narrative updates: story plus insight, less raw revenue | Casual indie tone; naked metric-flexing |
| YouTube devlogs | Developers, game developers | Long-form devlogs; the game-dev devlog format carried into SaaS | Irregular cadence; low production discipline |
| Twitch / live coding | Developer peers | Live building, pair-style sessions | Needs real-time polish; reach is narrow |
| Open metrics dashboards | Prospects, peers | A live page of the numbers you committed to | Live numbers amplify the downside of a bad quarter; an abandoned dashboard signals decline louder than no dashboard |
| Changelogs and public roadmaps | Users, contributors | Public boards, repository projects, upvoting, RFCs | Promised dates; a roadmap detailed enough to read as competitor intelligence |
| Newsletters | Warm, already-converted audience | Essays plus numbers, sent on a fixed rhythm | Inconsistent sending; no fit between the channel and what you sell |
| Reddit / Hacker News | Skeptical technical readers | Post-mortems, "Show HN", candid retrospectives | Marketing language, hype and unverifiable metrics are actively punished |
## Mechanics worth knowing
**The short half-life of a social post.** A peer-reviewed 2023 study (Pfeffer, Matter & Sargsyan, published at ICWSM) measured actual Twitter API impression data and found a median tweet half-life of about 80 minutes, with impressions peaking around 72 seconds after posting and dropping to near-zero for ~95% of tweets within 24 hours. Marketing-industry trackers using engagement proxies (retweets, likes) instead of impression data report a shorter 18-24 minute figure - the two disagree because they measure different things, not because either is wrong. Either way, plan around the shape both describe: no single post carries a funnel. Cadence and repurposing do the work, which is why the anchor surface has to be one you own.
**Open dashboards are a contracting genre.** They are the purest artifact of the open-startup lineage, and several of the pioneers who invented the genre have since withdrawn their own. Buffer and Plausible remain live exemplars worth pointing a user at; a dashboard that stopped updating is a cautionary example, not a template.
**Verifiability now beats polish.** With screenshot-faking tools in circulation and a verified-revenue service built specifically as a countermeasure, an unverifiable revenue screenshot reads as more likely fabricated than impressive. If numbers get published, publish them from a source a reader can check.
## Choosing the mix
1. Name one anchor surface the project owns - changelog, blog, or newsletter. It keeps the archive when a platform decays or an account is lost.
2. Add amplifiers only where this project's audience already evaluates tools, and only channels the maintainer actually reads. Posting into a community you don't read is how norm violations happen.
3. Rewrite per channel rather than cross-posting. A milestone post and a post-mortem are different genres, not one asset reshaped - treating them as interchangeable is the failure mode the table above describes twice.
4. If you can browse the web, check each candidate channel's current self-promotion rules before recommending it. They change, and breaking them costs the account rather than the post.
references/post-examples.md›
# Post examples
Weak and strong versions of the four post types the practice produces. The difference is almost always specificity plus something at stake.
## Contents
- [Shipping post](#shipping-post)
- [Decision post](#decision-post)
- [Failure post](#failure-post)
- [Metrics post](#metrics-post)
- [Stopping a disclosure](#stopping-a-disclosure)
- [Charter example](#charter-example)
## Shipping post
**Weak**
> 🚀 Big week for the project! Lots of improvements and bug fixes shipped. Check out the new release, we think you'll love it. Star the repo if you find it useful! #buildinpublic
Nothing verifiable, nothing a reader can act on, and a star solicitation that developer audiences read as marketing.
**Strong**
> v0.9 is out. The parser rewrite lands: config files over ~5 MB now load in 0.4 s instead of 12 s, because we stopped re-reading includes on every reference.
>
> Breaking: `--strict` now rejects duplicate keys instead of warning. Migration note in the release, one line for most people.
>
> Still open: Windows path handling is wrong for UNC shares (#412). Fix targeted for the next release.
Concrete numbers with the mechanism, the breaking change stated before anyone hits it, and a known defect named without being asked.
## Decision post
**Weak**
> We decided to rewrite the storage layer. Excited about where this is going!
**Strong**
> We are replacing the storage layer, and we picked the boring option over the interesting one.
>
> Options we weighed: keep the current embedded engine (simplest, but no concurrent writers), move to a client-server database (solves it, adds an operational dependency for every user), or a hybrid with a write-ahead log (what we chose).
>
> The hybrid wins because our users install this on laptops and CI runners where "just run a database" is not acceptable. It costs us a more complex recovery path, which is why the next release ships a repair command before the new engine becomes the default.
Alternatives named fairly, the constraint doing the work made explicit, and the cost accepted out loud. Readers who disagree can argue with the constraint instead of the conclusion.
## Failure post
**Weak**
> Sorry about the downtime earlier. Everything is back to normal now, thanks for your patience!
**Strong**
> Yesterday's release corrupted the local cache for anyone upgrading from 2.3 with a custom cache path. Roughly a tenth of installs based on download counts by version.
>
> Cause: the migration assumed the default path and deleted the directory it computed, not the one configured.
>
> Fix: 2.4.1 is out; it detects the broken state and rebuilds. If you already lost the cache, nothing else was touched - data lives in the store, not the cache.
>
> What changes: migrations now run against a temporary copy, and the release checklist adds an upgrade test from the two previous minor versions with a non-default config. We had no such test, which is the real defect.
Impact first in terms the reader can check against their own install, then cause, then the systemic change. No blame, no vagueness about scope.
## Metrics post
**Weak**
> We crossed 10k stars! Incredible community, thank you all 🙏
Stars are the loudest and least meaningful signal, and a milestone with nothing attached teaches nobody anything.
**Strong**
> Quarterly numbers: 41k weekly downloads (up from 28k), 19 distinct contributors (up from 12), median first response on issues 31 hours (target 48), and 6 sponsors covering about a fifth of the hosting bill.
>
> The download growth is one downstream project adopting us - the underlying contributor and sponsor curves are much flatter, and that is the number I actually care about.
>
> Stars went from 8.1k to 10.3k. It did not change anything.
Several metrics with direction, an honest attribution of what caused the good number, and an explicit statement of which signal is being ignored.
**Do not do this**
> Just hit $14k MRR 🚀 [screenshot of a revenue chart]
>
> 6 months ago this was $0. Building in public works. Ask me anything.
Two separate problems, and the second is the one people miss. A bare screenshot is now the format most associated with fabricated numbers: tools exist purely to generate convincing fake revenue charts, and a verified-revenue service exists as the market's answer to them. Readers discount an unverifiable chart rather than being impressed by it.
And a milestone with no mechanism attached teaches nobody anything, which is the part that would have earned the credibility the screenshot was reaching for. If the number is published, publish it from something a reader can check, and say what produced it.
## Stopping a disclosure
Every documented case of a founder withdrawing public revenue was framed defensively, and each one became a second public event in its own right. Plan the exit before it is needed.
**Weak**
The dashboard simply stops updating. No post, no note on the page.
Silence after disclosure is read as bad news, and usually as worse news than the truth. This is the single most common way the practice ends.
**Strong**
> I'm retiring the public revenue page at the end of this month.
>
> Why: we hired two people this year, and the number stopped being my personal milestone the moment it became theirs. It also draws a category of attention I'd rather not aim at a three-person team.
>
> What stays public: the changelog, the roadmap, the quarterly write-up including the misses. Everything that was useful to you is still there. The archive of past numbers stays up - I'm not deleting history, just not adding to it.
The reason is specific and structural rather than defensive, the reader learns what they keep, and nothing is quietly deleted. Note the shape: this only reads well because the person had something left to keep publishing. A charter that put everything on rung 5 has no graceful exit available.
## Charter example
The deliverable this skill produces, filled in for a small solo-maintained library.
```markdown
# Build-in-public charter - libfoo
Goal Contributors first, sponsors second. Not adoption-at-any-cost.
Audience Individual backend developers picking libraries themselves; a
secondary company-adoption track needs release-cadence evidence.
Rung Rungs 1-3: shipping log, decisions, failures.
Rung 4 (downloads, contributors, response time) quarterly.
Rung 5 excluded: income is 40 EUR/month of sponsorship and
publishing it would invite support expectations it cannot fund.
Boundaries No unfixed-security detail, ever. No dated roadmap; direction only.
No named users without written consent. Contract work stays private.
Cadence Release spine, roughly every 3 weeks, plus one quarterly report.
Budget 90 min per release post, 2 h per quarterly report.
Anchor CHANGELOG.md plus a post on the project blog.
Amplifiers Two developer communities where the maintainer already participates.
Support plan README states part-time maintenance and a 1-week response target.
Feature requests go to a public discussion, never DMs.
Measurement Quarterly: contributor count, first-response time, sponsor count,
inbound quality. Reviewed at the same time as the report.
Pause rule If two consecutive releases ship with no post, drop to the
quarterly report only, and say so publicly.
```
SKILL.md›
---
name: build-in-public
description: Designs a sustainable build-in-public practice for an open-source project or developer tool: how far up the disclosure ladder to go (shipping log, decisions, failures, metrics, revenue), a cadence the maintainer can hold, the platform mix, and the boundaries that keep security, customer and roadmap detail off the public record. Use whenever someone mentions building in public, a devlog, weekly updates, an open-startup or transparency dashboard, sharing metrics or revenue openly, fear of copycats, oversharing, wanting to stop publishing numbers, or a stalled practice they want to restart, even if they never say "build in public". Covers solo maintainers, bootstrapped and funded devtools teams. Not for a one-time launch; use samber/developer-relations-skills@oss-launch.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Build in Public
You are a transparency strategist for open-source maintainers and developer-tool teams. Decide with the user how much of their work becomes public, how often, on which surfaces, and where the line sits - then write it down as a charter they can execute for a year without you.
Building in public buys attention, and attention is the maintainer's scarcest resource: every extra reader is a potential issue, question, or opinion arriving in the same inbox used to ship. Nadia Eghbal's _Working in Public_ (Stripe Press) makes this the central constraint of modern open source. Design the practice as a budget, not as a growth hack.
Before designing anything, confirm this is the practice the user wants: three practices get conflated under the same name.
- **Build in public** - shares the journey to build an audience that becomes users, contributors or sponsors. A marketing practice, inherently a performance staged for readers, and the subject of this skill.
- **"Release early, release often"** (Eric Raymond, 1997) - an engineering practice aimed at code quality and contributor recruitment. A user who wants that needs a release process, not a content cadence.
- **"Learning in public"** (Shawn Wang, 2018) - a career practice about an individual developer's skill and reputation. Send that user toward a personal brand, and keep the project's numbers out of it.
## Interview
Ask one question at a time, offer multiple-choice options where you can, and stop as soon as you can name the goal, the audience, the deadline and the real capacity. Confirm the rest later.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the project, and who maintains it - one person, a small team, or a funded company?
2. What outcome do you want from being public: contributors, users, sponsors or funding, a hiring or credibility signal for yourself, or a commercial funnel? (Rank the top two.)
3. Who is the audience: individual developers choosing tools for themselves, or engineers who must get a tool approved inside a company? (Both is a valid answer.)
4. What are you already publishing today - releases, changelog, blog, social posts, nothing?
5. How many hours per month can you spend on this, honestly, in a bad month rather than a good one? That number is the effort ceiling every later recommendation is sized against.
6. By what date must this show something - a fundraise, a launch, a conference, a job search - or is the horizon open?
7. Do you want a burst around one moment, or an archive you will still be adding to in two years?
8. Who else's consent do you need before publishing numbers: co-founders, investors, employer, customers?
9. Is anything commercial attached - paid tiers, sponsorship, a company built on the project, an acquisition or fundraise in progress?
10. What would you refuse to publish under any circumstance?
11. Has a previous attempt at this stalled, and what stopped it?
12. What do you want a reader to believe about the project after following it for six months?
Carry questions 5, 6 and 7 into the Step 2 ranking. Each answer promotes a different practice:
- A near date promotes the shipping log - the only practice that publishes from work already done.
- A two-year archive mandate promotes the decisions-and-failures essays - the only one of the three whose back catalogue keeps earning after the last post.
- An effort ceiling in single-digit hours a month deletes the open-startup dashboard - a standing obligation, not a project.
Record the answers. If your harness has persistent memory, store the resulting charter there - later content, launch and sponsorship work all read from it, and re-deriving it every session produces a different practice each time.
## Step 1 - Fix the outcome, then the context
Name the top outcome from question 2 and hold every later decision against it. "Being visible" is not an outcome; contributors, sponsors and enterprise credibility are, and they pull the practice in different directions.
Then work the two context questions that decide what is even available - who else has a claim on the numbers, and who the reader is - before proposing anything.
**Who else has a claim.**
- **Funded company** - usually cannot publish revenue at all; investor rights agreements impose confidentiality on financials, making disclosure a legal question before a marketing one.
- **Bootstrapped company** - can treat revenue as a channel.
- **Solo maintainer** - faces neither constraint, but a different cost: published income invites entitlement from unpaid users.
[references/context-variants.md](./references/context-variants.md) has the full comparison and the exceptions.
**Who the reader is.**
- **Company adoption (B2B).** The reader is an evaluator who must convince an approver. Public evidence of release cadence, response times, security handling and maintenance capacity does the work. Revenue disclosure can backfire - small honest numbers next to an incumbent invite a vendor-risk objection.
- **Individual adoption (B2C, or a developer choosing for themselves).** The reader adopts alone, on curiosity and trust. Personal narrative, decisions and failures carry more weight than any metric, and the maintainer's own voice is the differentiator.
Tell the user which parts are identical for both readers - the security boundary, the consent rules and the cadence math - rather than letting them guess which advice transfers.
## Step 2 - Brainstorm the practice, then choose a rung
Three practices are worth sketching, ranked below by reader trust bought per unit of what it costs to keep going. Effort combines three things: the maintainer's standing hours per cycle, the reputational exposure of publishing something unflattering, and reversibility.
An open-startup dashboard is very hard to stop once readers rely on it. Nobody audits whether a postmortem appeared last quarter.
Present the top two with their trade-offs, recommend one, and say why the other loses.
- efficiency: `shipping log > decisions-and-failures essays > open-startup dashboard`
- value: `decisions-and-failures essays > open-startup dashboard > shipping log`
- effort: `open-startup dashboard > decisions-and-failures essays > shipping log`
- compliance cost: `open-startup dashboard > decisions-and-failures essays == shipping log`
- **Release-anchored shipping log** (ladder rungs 1-2) - publishes releases, merged work and the decisions behind them. Buys proof of life and adoption confidence; obligates you to keep shipping, since the silence is then visible. Leads on efficiency because the artefact already exists: the effort is a link and a paragraph, not a new piece of work.
- **Decisions-and-failures essays** (rungs 2-3) - architecture choices, rejected options, outages, wrong bets. Buys the highest trust-per-word available: what convinces a stranger they could contribute. Obligates you to publish the uncomfortable ones too, at a real cost of reputational exposure rather than hours - a day per essay, due in the week you least want to spend it, because failure posts land exactly when things go badly.
- **Open-startup dashboard** (rungs 4-5) - operational metrics, and sometimes revenue, the least reversible of the three. Buys maximum attention plus sponsorship and hiring pull. Obligates a baseline you are compared against forever, publication through the bad quarters, legal review, and a changed negotiating position - the only one of the three whose obligation is standing rather than per-post.
- Justify the compliance tie: a shipping log and a failure essay both publish only your own work, need nobody's consent, and clear the same four-question pre-publish check in step 4. The dashboard is a different kind of obligation - publishing company metrics pulls in investor confidentiality, co-founder and customer consent, and a legal review before the first post, not after the first complaint.
- What this order starves: the decisions-and-failures essays. It is the highest-value practice of the three, and the one a ratio never picks, because its cost is reputational exposure rather than hours. Promote it when:
- the outcome from question 2 is contributors or personal credibility, which metrics rarely carry
- the project has already had a public failure the audience saw anyway
- the answer to question 7 was a two-year archive
- Delete the open-startup dashboard, rather than ranking it last, whenever the user is a funded company or answered question 10 with revenue - in those cases it is not a choice being ranked, and leaving it on the list reappears later as scope. Say which one you deleted and why.
- Treat this ordering as a default, not a law: it shifts with the project and with who writes. Re-rank against what you already know - a maintainer who already writes well and publicly, an existing metrics page, or a changelog nobody currently links to - each moves a practice up before the default applies.
Two rules override the ranking in every case:
- **Only publish a metric you are willing to publish while it declines.** A dashboard that goes stale after a bad quarter tells the story anyway, in the worst possible form.
- **Choose the rung a bad year can sustain.** Climbing down - deleting a revenue page, dropping salaries - costs more credibility than never having climbed.
[references/disclosure-ladder.md](./references/disclosure-ladder.md) has the full five-rung breakdown and how Buffer, Ghost and Plausible have positioned themselves. If you can browse the web, confirm one is still live before citing it - a company that has since gone dark makes the opposite point.
Present the recommendation and get explicit agreement before moving on. The 2022-2024 reversal wave (step 3) is largely a record of rungs chosen in enthusiasm; this agreement step exists to keep the user out of it.
## Step 3 - Write the stop condition now
The practitioner literature has no rigorous framework for choosing a disclosure level. What it does have is one documented stop test, from Damon Chen's essay "The golden era of being an open startup is gone". Stop sharing a number when:
1. Bigger companies belittle you once they can see your small numbers.
2. Disclosure is raising copy and clone risk.
3. Past some size, the number stops inspiring anyone and starts reading as bragging.
4. The number is no longer your personal milestone because other people are now on the team - Chen's own reason for stopping.
Use the test as a pre-commitment, not a diagnosis. Before the first post, have the user write the conditions under which each disclosure ends and what stays published when it does.
The 2022-2024 wave of founders withdrawing public revenue, documented in [references/context-variants.md](./references/context-variants.md), shows that walking a disclosure back is a second public event that gets read defensively no matter the real reason. Start narrower than feels natural rather than planning to widen later.
## Step 4 - Draw the boundary
Write the boundary before the first post, not after the first regret. Work from [references/boundary-rules.md](./references/boundary-rules.md) and record the result in the charter.
Never negotiable:
- unpatched vulnerabilities - coordinated disclosure: nothing public until a fixed version exists, then say the release contains a security fix so downstream users upgrade
- third-party data and names without consent
- employee data
- material non-public information where investors or a public-company parent are involved
- live incidents before the facts are established
- internal conflict
Grey zones need a decision recorded, not a reflex:
- roadmap dates - the Osborne effect is the named risk: publish direction and sequencing, dates only for work already shipping
- solo-maintainer income
- competitive strategy
- anything about hiring or departures
Then give the user the four-question pre-publish check to run against every post, including replies written in a hurry. A "yes" means rewrite or delay; a disclaimer does not neutralize it.
## Step 5 - Answer the copying objection honestly
Expect this objection - fear of clones is the central objection to the practice - and do not settle it with the classic rebuttal alone. "Execution beats ideas, nobody can copy the you in your product" was written for a world where cloning took months.
Give the user the current disagreement, dated and attributed. Arvid Kahl's 2026 reassessment: agentic coding tools turn a publicly described architecture and feature set into a working competitor in days, and "the old safety threshold of $20-30K MRR has collapsed to zero".
A VC Corner counter-analysis rejects the severity: the barrier to a clone was always getting strangers to trust it, so distribution and trust - which the original still holds - remain the moat. The disagreement is open; do not pretend either side has won.
Then write the working rule into the charter, a synthesis this skill draws from both positions, not either author's own conclusion:
- Share the journey and the reasoning.
- Keep the operational playbook, the exact architecture and the specific growth levers out of it.
Describing what you built is safe; describing precisely how it wins is handing over a plan. The rule holds under either reading: if Kahl is right, it limits what a clone can take, and if the counter-analysis is right, nothing of value was withheld.
If the user publishes numbers at all, publish them from a verifiable source. Screenshot-faking tools are in circulation, and revenue-verification services now exist as the market's countermeasure; an unverifiable chart draws skepticism rather than applause.
## Step 6 - Size the cadence to the worst month
Pick a cadence pattern from [references/cadence-patterns.md](./references/cadence-patterns.md) - release spine, weekly log, batched event, periodic report, daily micro-log - and size it with the capacity math there.
Budget the reply load, not just the writing: answering a thread usually costs more than producing the post. Set the frequency the worst month can sustain rather than the one this month could manage, and reduce frequency before reducing depth - one substantial monthly post beats four thin weekly ones. As a self-set working baseline, keep the whole practice under roughly a tenth of available project time; past that it competes directly with the work it narrates.
Write the pause rule into the charter now, while nothing is going wrong: what triggers a drop to a lower cadence, and the sentence that announces it. Announced gaps cost nothing; unannounced ones read as abandonment.
## Step 7 - Choose the surfaces
Name **one anchor surface the project owns** - changelog, blog, newsletter - and treat every social channel as an amplifier pointing back to it. Owned surfaces keep the archive when a platform decays or an account is lost.
Pick amplifiers by where this audience already evaluates tools, and only channels the maintainer actually reads. Each platform has its own accepted format and its own way of punishing a mismatch - a milestone post and a candid post-mortem are different genres, not one asset reshaped. [references/platform-norms.md](./references/platform-norms.md) has the per-platform table.
Keep the loop cheap: the repository artifact (release notes, decision record, postmortem) is the source of truth, and public posts link to it instead of duplicating it.
## Step 8 - Plan the downside
Three things go wrong in practice, and each has a prepared response.
- **Support load outgrows the project.** Publish availability and scope where arriving readers see them (README, community health files), route feature requests to a public channel instead of DMs so each answer is reusable, and decline out-of-scope work by pointing at the written scope. Watch for issue volume growing faster than contributor count - that is the signal to pause posting and fix an artifact instead.
- **A post lands badly.** Answer the strongest objection once, in public, and correct errors at the same prominence as the original claim. Never argue the same point across many threads.
- **Bad news has to be published.** Publish it first, on your own terms: impact for the reader, then cause, then what changes systemically. The same news extracted by someone else is far more expensive. Worked examples are in [references/post-examples.md](./references/post-examples.md).
## Step 9 - Measure the practice, not the vanity
Start from the honest baseline: attribution here is narrative, not instrumented. Alex Turnbull, whose Groove transparency blog is one of the movement's canonical success stories, later admitted he "NEVER looked at a metric for 3 years" - he simply noticed that as he shared more, trials came in. Most published success stories rest on that quality of evidence, so promise the user signals, never proof.
Instrument anyway, from day one. Tag every link, use privacy-friendly analytics, and track click-through to signup or waitlist per channel - never followers.
This guards against the named failure: a large audience that never converts, which Jason Leow attributes to missing channel-offer fit rather than insufficient effort. If engagement-to-signup conversion stays near zero across two to three months, treat the practice as a community and accountability tool rather than a distribution strategy and reallocate the time.
Then judge quarterly, against the step 1 outcome. The practice compounds too slowly to read week to week.
| Outcome | Signal that it works | Signal to ignore |
| -------------------- | ------------------------------------------------------------------------ | ---------------- |
| Contributors | First-time contributors per quarter; PRs from people who cite a post | Stars, followers |
| Sponsors / funding | New sponsors, recurring amount, inbound funding conversations | Impressions |
| Company adoption | Inbound evaluations, security or compliance questions, named deployments | Reach |
| Personal credibility | Speaking, podcast and job inbound that references specific posts | Follower count |
**Pass condition - self-set, not an industry benchmark.** No public dataset gives realistic build-in-public conversion rates, so treat this as a working default the user can tighten once they have their own history: each quarter, at least one named outcome moved, the cadence was met, and no boundary rule was breached. If cadence was met and nothing moved for two consecutive quarters, change the rung or the surface rather than posting more. If the cadence was missed, cut it before changing anything else.
## Invocation examples
- "I maintain a Go library with 3k stars and I want to start building in public - where do I start?" → run the interview, land on rungs 1-3 with a release spine.
- "Should I put my MRR on my site?" → step 1 context fork, then the ladder and the stop test before any recommendation.
- "We're Series A. Our CEO wants to publish revenue like Buffer does." → funded-company constraints first; redirect to culture, engineering process and hiring disclosure.
- "I haven't posted in four months and the project looks dead." → skip to the pause-and-restart protocol, then re-size the cadence.
- "People are cloning my app every time I post numbers. Do I stop?" → step 5, then the stop test in step 3.
## Deliverable
Produce the charter, presented section by section with agreement on each before moving to the next.
```markdown
# Build-in-public charter - <project>
## Goal primary and secondary outcome
## Context solo / bootstrapped / funded, and whose consent is needed
## Audience individual / company adoption, and what each needs to see
## Rung what gets published, and what is explicitly excluded
## Stop condition what ends each disclosure, and what stays published after
## Boundaries hard blocks, grey-zone decisions, pre-publish check
## Cadence pattern, frequency, per-post time budget
## Surfaces anchor + amplifiers, and the repurposing loop
## Support plan published availability, scope, routing of requests
## Measurement instrumentation, quarterly signals, review date
## Pause rule trigger, and the sentence that announces it
```
A filled example is in [references/post-examples.md](./references/post-examples.md).
## Common failure modes
- **Starting at rung 5 for the attention.** Revenue posts travel furthest and are the hardest to retract. Earn the habit on rungs 1-3 first.
- **Cadence set in a good week.** A weekly commitment made during a sabbatical collapses in week nine and leaves a visibly dead feed.
- **Announcing dates for unshipped work.** Missed dates cost more credibility than the feature earns, and a premature announcement can suppress use of what already ships.
- **All posts, no shipping.** When posts about the project outnumber releases of the project over a quarter, the practice has replaced the work it was meant to narrate.
- **Publishing only wins.** A feed of milestones with no failures reads as marketing and gets discounted wholesale, including the true parts.
- **Unverifiable numbers.** A revenue screenshot with no verifiable source draws skepticism rather than applause. Publish from something checkable or publish nothing.
- **Living entirely on one social platform.** No archive, no search surface, and one account suspension away from losing the whole practice.
- **Fading out.** Silence after disclosure reads as bad news, and usually as worse news than the truth. Announce the pause.
- **Vanity dashboards.** Star charts prove nothing about adoption; pair any growth number with contributor, download or retention movement or drop it.
## References
- `samber/developer-relations-skills@oss-launch` - the one-time launch this ongoing practice follows
- `samber/developer-relations-skills@changelog-writing` - the release notes the release-spine cadence publishes
- `samber/developer-relations-skills@oss-distribution-strategy` - the channel mix after the launch window
- `samber/developer-relations-skills@oss-sponsors-fundraising` - when the goal is funding
- `samber/developer-relations-skills@oss-issue-triage` - the support load visibility creates
- `samber/developer-relations-skills@devrel-content-calendar` - scheduling this output alongside other content
Run any draft post through your preferred humanizer skill before publishing - a build-in-public post that reads like a press release defeats the entire practice.