How to Correct a Build-in-Public Update

The short answer

Correct material factual errors at the original URL with a dated note. Send the correction through the channels that carried the claim, and revise any charts or conclusions that relied on it. If the replacement is still uncertain, withdraw the original figure and explain what remains open.

Correct a material error where you first published it, add a dated note that explains what changed, and send the correction through the channels that carried the original claim. If the mistake changes a conclusion, correct the conclusion too. A new number can leave readers with the same wrong impression if the headline, chart, or follow-up still tells the old story.

Building in public gives your progress updates a life beyond the day you write them. A prospective customer might bookmark a launch recap. Another founder might cite your experiment. A newsletter reader might see the headline and never open the source. An edit to the original helps the next visitor. A correction in the places where the claim traveled helps people who already acted on it.

Decide whether the change needs a public note

Ask what a reader might reasonably do with the original claim. If it could change what they buy, how they use the product, what they cite, or how they interpret your progress, make the correction visible. That includes a wrong count, a misquoted person, an incorrect availability claim, or an overstated conclusion about an experiment. Fix a misspelled word quietly when it leaves the meaning intact.

Separate facts that were wrong at publication from facts that changed afterward. If a beta really had 40 workspaces on Monday and gained five on Friday, a dated update can add the later count. If Monday’s report called 40 setup events 40 workspaces, Monday’s claim needs a correction. If you change how you define activation next month, give the new definition a start date and say whether earlier figures can be recalculated on the same basis.

The Associated Press standards on corrections offer a useful publishing model. AP identifies corrections clearly and makes them visible both to readers and to subscribers who may have used the original information. The equivalent for a founder might be a dated note in the original Journal post and a direct follow-up with the newsletter editor who quoted it. The audience and publishing tools differ. The practical question is the same. Who received the wrong claim, and where can they find the repair?

Check what the source actually counted

Save a private copy of the published wording and the evidence behind it. Identify the exact sentence, period, and unit. For a metric, write down the numerator and denominator separately. For a product capability, record the plan, access group, or version you verified. This gives you something concrete to check before replacing a claim.

Use the original window and eligibility rules when repairing a count. If your announcement reported first-week activation, keep the original group of eligible accounts and the first-week observation window. A current dashboard could include later activity or exclude workspaces that have since closed. A result from that dashboard may be correct for today and still answer a different question.

When a figure represents accounts, check that the rows map to distinct eligible accounts. Inspect a few records behind the total. A workspace with three successful setup events should contribute one activated workspace if the definition is at least one successful setup. Also check whether a workspace created near the end of the signup period got the full observation window. These checks follow from the claim itself. A tidy chart or a familiar dashboard label gives you no assurance that its unit matches your sentence.

If the evidence rules out the original claim and the replacement is still uncertain, mark the claim as withdrawn while you check it. Say which figure readers should stop using and which question remains open. Give a next update date only if you can meet it. In some cases the underlying records are too incomplete to reconstruct the result. A clear withdrawal is the finished correction in that case.

Work through a fictional activation correction

Consider a fictional SaaS for organizing volunteer shifts. In a public onboarding recap, its founder said that 48 of 60 new workspaces published a first schedule within seven days. The reported activation rate was 80%. A social post repeated the 80% figure, an email newsletter linked to the recap, and the recap’s closing paragraph said the new checklist improved activation.

The team’s intended rule was to count each eligible workspace once if it published any schedule in the first seven days after creation. The report actually counted 48 qualifying publish events. Some workspaces published several times. Under the intended rule, the same events belonged to 36 distinct workspaces. The denominator was still 60 eligible workspaces, each observed for seven days. The corrected activation rate was 36 divided by 60, or 60%. The original rate was 20 percentage points too high.

The team also checked the closing claim about improvement. Suppose the prior update reported 35 of 60 workspaces, or about 58%, before the checklist shipped. Even if the two cohorts used the same measurement rules, their small difference could reflect who signed up or when they needed to post a schedule. The two snapshots can describe what happened in each cohort. They give the founder insufficient evidence to attribute a lift to the checklist. The corrected recap should drop the causal claim and say what the team will measure next.

Put the repair beside the original claim

Replace the figure in the original body, chart, chart description, and any headline or preview that repeats it. Keep the original publication date and add the date of the correction. Put the note where readers will encounter it before reusing the figure. In this example, it belongs near the top because the number drove the post’s headline and conclusion.

Correction, June 12. An earlier version reported first-week activation of 80%. The report counted 48 schedule publish events, including repeat publishes by the same workspace. In the original cohort, 36 of 60 workspaces published at least one schedule within seven days of creating a workspace, for an activation rate of 60%. We’ve corrected the chart and withdrawn the claim that the checklist improved activation.

If the denominator also changes, explain why. Suppose you find that several test workspaces were included. The public note should identify the exclusion and give the corrected eligible total if that total is safe to disclose. Changing both parts silently makes it harder for readers to understand why a percentage moved.

Follow the claim through the places it traveled

For a short public update, a simple list of copies is enough. Track where the claim appears, what can be edited there, and who saw it. In the fictional example, the source is the recap, the copies are the social post and newsletter, and the inference is the statement about checklist impact. Use those three checks on your own posts before you call the repair finished.

• Fix the source. Update the original URL in place when you can. Open it as a reader and check the headline, chart caption, and note. Look at the published version because a draft preview only shows what you meant to send.

• Correct the copies. Edit the social post where possible and add a visible reply linking to the corrected source. If a platform prevents edits, leave the reply and publish a standalone correction when the original reached people who might miss a reply. A sent email needs a new message or a prominent note in the next issue, depending on how quickly readers need the repair.

• Correct the conclusions. Check follow-ups, sales slides, and charts that relied on the old claim. Remove the causal sentence in the recap and send the revised wording to anyone you know reused it. For external copies you cannot edit, provide the corrected fact and a source link so the owner can make the change.

Give people enough detail to understand the fix in the channel where they receive it. A reply in the fictional example could say, “Correction to our onboarding recap. First-week activation was 36 of 60 workspaces, or 60%. Our earlier 80% figure counted repeat publish events. We also withdrew the claim about the checklist’s effect.” A link to the revised recap can carry the chart and measurement details.

Use judgment about direct follow-up. A reader casually following the project can usually get the correction from the public record. If you know a prospect used the number to evaluate the product, send it directly. If a collaborator built a slide around it, send them the replacement figure and explain which conclusion to remove. The work is to reach people whose next decision could still depend on the old version.

Close the loop in your next progress report

If the wrong figure appeared in a running series, check the next installment before it goes out. A chart with a corrected June point and a July headline that still compares against 80% tells two stories at once. Carry the corrected 60% into the comparison, label the counting rule next to the series, and link back to the note so readers can reconcile their saved copy. If you cannot reconstruct comparable earlier points, leave a gap or start a new series with a dated explanation. Otherwise readers may interpret a reporting change as a shift in product performance.

Preserve the correction without republishing sensitive details

You can explain a mistake without posting raw event rows, customer identifiers, or screenshots from an account. Run the replacement claim through the same disclosure decision you would use for a fresh update. Buildside’s guide to choosing which SaaS metrics to share publicly walks through when to share exact figures and when to generalize, delay, or keep them private.

If the original update exposed information that should have stayed private, remove that information from the places you control. In any public note, describe the category of information removed only as far as it is safe to do so. Handle any necessary contact with affected people through the appropriate private channel. The dated note exists to tell readers what they can rely on. It can do that without preserving every detail of the previous version.

Once the repair is out, add a small check to the way you publish progress. The fictional team could put the eligibility rule, unit of analysis, and observation window beside the saved report. It could also test that a workspace with several publish events counts once. Before the next update, someone can compare the headline with that definition and independently recompute the displayed fraction. A solo founder can do the same check in a separate pass, starting from the written claim instead of the chart.

Questions founders ask next

Should I keep a separate correction log?

A dated note at the original URL is usually enough for one update. A shared log helps when you regularly publish figures across several posts or when readers need to find all affected periods in one place. Keep each entry linked to the corrected source.

What if someone reposted a screenshot I cannot edit?

Contact the person who shared it with the corrected wording and a link. Put a visible note at the original source and in the channel you used to circulate it. Record where you sent the correction so you can distinguish confirmed edits from outstanding requests.

Can I publish the revised number before I know why it was wrong?

Yes, if the revised number and its scope are independently verified. Say what you have confirmed and keep the cause open. If you cannot verify the replacement, withdraw the original claim and state which part is still being checked.

Sources

• Associated Press news values and principles, corrections and data sections

• Buildside Journal guide to deciding which SaaS metrics to share publicly

Frequently asked questions

A note from Uriel Bitton

I share practical lessons from building Buildside and learning alongside SaaS founders.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading