Build in Public
How to Share Startup Failures in Public Without Losing Trust
Share startup failures with a five-part public failure note: facts, impact, uncertainty, corrective action, and clear privacy boundaries.
By Uriel Bitton · 4 min read
The short answer
Share startup failures in public when the update explains what happened, what it affected, and what will change. Separate confirmed facts from uncertainty, avoid blaming individuals, and keep customer, contractual, security, and sensitive commercial details private. If you cannot state the facts, impact, corrective action, and disclosure boundary accurately yet, wait before publishing.
Share startup failures in public when the update helps readers understand what happened, what changed, and what you will do differently. Do not treat failure as a performance of vulnerability. Use a five-part public failure note: facts, impact, known versus unknown, corrective action, and a clear boundary around information that should stay private. If you cannot explain those five parts accurately yet, wait until you can.
A failure post is not a confession
A useful failure update should make the work easier to understand, not make the founder look dramatic or unusually brave. Google Cloud’s postmortem guidance defines a postmortem around the incident, impact, response, root causes, and follow-up actions, with the purpose of learning rather than assigning blame.
That logic applies beyond outages. A failed launch, pricing experiment, onboarding change, or distribution test can be shared the same way: describe the event, separate evidence from interpretation, and show what decision changed because of it.
Use a five-part public failure note
1. State what happened without exaggerating it
Start with the observable event. “Our onboarding redesign reduced completion in the first week” is more useful than “We completely broke onboarding.” For an operational incident, include the date and affected system when that context matters. For an experiment, name the assumption or decision that failed.
2. Describe the impact before explaining the cause
Tell readers what the failure changed for users, the business, or the next decision. Impact might be delayed onboarding, a lost week of development, a campaign that produced no qualified conversations, or an outage that affected a defined part of the product. This keeps the post grounded in consequences instead of founder emotion.
3. Separate what you know from what you still suspect
GitLab’s 2017 database-outage postmortem published a detailed timeline and impact while documenting which recovery mechanisms failed. GitLab also noted that an engineer’s name had appeared in an initially public document and said future cases would redact names, showing that transparency itself can need correction.
Use simple labels when necessary: confirmed, likely, and still investigating. Readers can handle uncertainty better than false certainty.
4. Show the corrective action
The most useful failure post contains a changed behavior, system, or decision. Cloudflare’s 2023 control-plane outage postmortem did not stop at the outage narrative; it explained what failed, what worked, and the changes the company planned after recovery. Google’s reliability guidance similarly treats follow-up actions as a core part of a postmortem.
For a SaaS founder, the correction can be smaller: revert the onboarding change, narrow the ICP, add an alert, stop a channel, change the pricing test, or run a different experiment. If nothing will change, the post may be commentary rather than learning.
5. Keep a public boundary
A transparent failure post does not require publishing every internal detail. GitLab’s incident-review handbook explicitly allows a separate public RCA when the internal review contains customer-identifying, security-sensitive, or internal-only information.
The same boundary should apply to founder updates. Remove customer identities, private messages, credentials, active exploit details, contractual information, or commercially sensitive numbers that do not improve the lesson. Buildside’s practical guide to building in public uses the same principle: share the reasoning and evidence, then screen the update for customer, contractual, commercial, and operational risk. For numerical disclosures, the SAFE test for SaaS metrics provides a more specific disclosure check.
Do not manufacture failure content
Not every bug, missed target, or weak post deserves a public retrospective. Share the failure when it changes a decision, reveals a useful pattern, affects users, or produces a lesson another founder or customer can apply. Otherwise, keep it in your private operating notes.
A hypothetical example: “We moved onboarding from four steps to two because we assumed fewer fields would improve activation. Completion rose, but fewer users connected the data source required for the core workflow. We restored that step and will measure successful data connections before changing the flow again. The customer-level data stays private.”
Before publishing your next failure, write the full private version first. Then reduce it to five things: what happened, what it affected, what you know, what changed, and what should remain private. Building in public is more useful when failure becomes evidence for the next decision rather than content for its own sake.
Sources
Frequently asked questions
Should founders share failures when building in public?
Yes when the failure produces a useful lesson, changes a decision, affects users, or reveals a pattern others can learn from. You do not need to publish every bug, missed target, or bad week.
How do I talk about a startup failure without damaging trust?
State the observable facts, explain the real impact, separate confirmed causes from uncertainty, and show the corrective action. Avoid exaggeration, blame, invented certainty, and private details that do not improve the lesson.
What should stay private in a public failure post?
Keep customer identities, private messages, credentials, unresolved exploit details, contract-restricted information, and sensitive commercial details private unless disclosure is necessary and permitted. Share the lesson at the lowest-risk level that still makes it useful.
Should I publish a failure while I am still investigating it?
Only if you can clearly label what is confirmed, what is still unknown, and what users need to know now. For non-urgent founder lessons, waiting until the evidence is clearer usually produces a more accurate and useful post.
A note from Uriel Bitton
I think failure is worth sharing when it makes the next decision clearer. The useful part is not the drama of getting something wrong; it is the evidence, the correction, and the boundary between what readers need to learn and what the company should still protect.
Keep building with us
Get practical founder lessons and product updates in your inbox.