Build in Public: What the Revenue Evidence Actually Shows

Build in public can improve feedback, trust, and distribution, but it does not reliably cause revenue. ProvenStartups found successful solo products, weak earners, and documented failures in the same cohort. Use public work as a measurable acquisition experiment, publish evidence instead of a founder diary, and stop when the audience does not contain buyers.

Contents

The useful path is short: inspect the revenue evidence, understand the contradiction, run a constrained publishing system, and know when to refuse the tactic. The sections below separate disclosed results from causal claims so a large screenshot never gets mistaken for proof that posting created the sale.

• ·What the revenue evidence actually shows
• ·Where the data contradicts build-in-public advice
• ·A build-in-public system worth running
• ·When build in public is the wrong choice
• ·FAQ

What the revenue evidence actually shows

The evidence shows that solo founders can reach meaningful revenue while building openly, but it does not isolate public posting as the cause. Across the full matching cohort, rather than only the examples below, 213 projects are solo-run. Of those, 65 disclose a clean monthly figure, with a $15K/mo median and a $6/mo to $300K/mo range.

The cohort contains products from SaaS and consumer apps to publishing, directories, plugins, and 20 cautionary tales. Its recorded evidence split is 25 [V], 0 [F], 0 [C], and 0 [U]. The cohort median is an aggregate supplied by the dataset, not an individually graded revenue claim.

The examples make the interpretation problem visible:

This is why ProvenStartups puts the grade beside the number. The full index covers 406 ideas: 57 third-party verified [V], 184 founder-reported [F], 121 creator-relayed [C], and 44 unverified [U]. The grading method is part of the claim, not a footnote added after an impressive figure.

Where the Data Contradicts Build-in-Public Advice

The popular claim is that consistent public sharing creates revenue. ProvenStartups' data does not support that causal conclusion: the cohort includes 20 cautionary tales, while its disclosed monthly outcomes stretch from negligible income to an outlier. Public visibility appears beside success and failure, so posting alone is not a defensible business model.

The sharper contradiction is that the biggest number is not always the strongest evidence. nano-banana.ai reports ≈$115K/mo net profit for a single month [C], while the Peptide Tracker App reports $11K MRR and $51K total revenue in seven weeks [V]. The smaller claim deserves more confidence because a third party verified it.

Nor does publishing convert an undisclosed business into a proven one. AI App Factory says no revenue figure was disclosed [U], despite details about overseas customers and low-priced purchases. ProvenStartups would refuse to infer revenue from attention, users, launch velocity, or a polished dashboard.

The defensible conclusion is narrower:

• ·Building openly may create conversations, backlinks, trust, and faster feedback.
• ·Revenue proves that someone paid; it does not reveal which post caused the payment.
• ·Causation needs attributable leads, conversion records, or a credible before-and-after comparison.

A Build-in-Public System Worth Running

Treat build in public as an instrumented acquisition test, not a lifestyle or daily content obligation. Publish artifacts buyers can evaluate, attach definitions to every metric, record which posts generate qualified actions, and set a stopping rule. If the activity produces peer applause but no buyer signal, move those hours back into product or distribution.

1. 1.Publish an artifact. Share a working demo, benchmark, commit diff, teardown, migration note, or reproducible failure. “Worked all weekend” contains no useful information.

1. 1.Define the metric. Say whether a number is MRR, cash collected, gross revenue, profit, cumulative sales, or an estimate. StoryShort.ai's $35K/mo across three apps [F] is useful because the scope is stated.

1. 1.Track the path to purchase. Use tagged links, source fields, booked calls, trials, activations, and paid conversions. A post that reaches developers may still miss the person with budget.

1. 1.Publish the negative ledger. Include failed launches, refunds, support load, churn, and experiments that produced no qualified interest. This is more decision-useful than another revenue screenshot.

Outside datasets are context, not validation. Stack Overflow's annual developer survey can frame developer behavior, and the Census Bureau's nonemployer statistics can frame solo businesses. Neither source verifies a specific startup's revenue or proves that public posts drove it.

When Build in Public Is the Wrong Choice

Do not build in public when disclosure creates more downside than measurable distribution. Client confidentiality, security details, regulated data, fragile platform advantages, and easily copied acquisition tactics are valid reasons to stay quiet. It is also the wrong channel when followers are mostly other builders and paying customers buy through search, marketplaces, outbound, or referrals.

Three stop conditions are enough:

• ·Public work repeatedly attracts peers but no qualified buyer actions.
• ·Preparing updates delays shipping, support, or direct customer contact.
• ·The useful details would expose customer data, operational weaknesses, or a short-lived edge.

WordUnscrambler's estimated $170K-660K/mo [C] is a useful warning. A public traffic model can look precise while remaining several steps removed from banked revenue. We would not turn that estimate into a publishing playbook without disclosed receipts and an attributable acquisition path.

Build in public is optional distribution. Evidence discipline is not optional.

FAQ

The short answers are: public work may help, daily posting is unnecessary, useful artifacts beat progress theater, and evidence quality matters more than claim size. A developer should be able to trace a metric to its definition and source. If that trail ends at a screenshot or retelling, treat the number accordingly.

Does build in public increase revenue?

Sometimes, but this dataset cannot establish a general causal lift. The full 213-project matching cohort includes both earners and 20 cautionary tales. Its $15K/mo median comes from the 65 projects with clean monthly figures, not from every project, and no supplied attribution data separates the effect of public posts from product, timing, search, marketplaces, or sales.

What should a developer publish?

Publish material a buyer can test: a live demo, performance benchmark, implementation note, migration guide, incident review, or clear pricing experiment. Include the result, measurement window, denominator, and failure conditions. Data Fetcher's $23K/mo [F] is a scoped revenue claim; its grade tells the reader that the source is the founder rather than independent verification.

How often should someone build in public?

Publish when there is a decision-useful artifact, not because a calendar demands a daily streak. A weekly changelog may fit a fast product; a monthly teardown may fit deeper infrastructure. Choose a cadence that does not delay shipping, then judge it by qualified conversations, trials, activations, and paid conversions rather than impressions.

How should revenue claims be checked?

Start with the evidence class: [V] third-party verified, [F] founder-reported, [C] creator-relayed, or [U] unverified. Then check whether the figure is monthly, cumulative, gross, net, recurring, or estimated. HabitKit's $15K MRR [F] and nano-banana.ai's ≈$115K/mo net profit for one month [C] describe different periods, metrics, and confidence levels; they should never be compared as equivalent proof.