What is building in public, and how do you start?

What building in public means

Building in public is the opposite of stealth mode. Instead of working quietly for months and then unveiling a finished product, you show the work as it happens: what you shipped this week, a decision and the reason behind it, an experiment that failed, what comes next.

It does not mean sharing everything. You decide what to show; most founders share process, decisions and lessons, and keep sensitive details private. It is not the same as marketing either. "Something big is coming" is a teaser. "I cut the signup form from three fields to one, let's see what happens" is building in public.

Why do people do it?

• Early users. People who follow along are often among the first to try the product, even if you start with no audience.
• Feedback while it's cheap. You hear "why did you build it this way?" before launch, not after six months spent on the wrong thing.
• Accountability. Knowing you will post on Friday makes it harder to let the week drift. To write something, you first have to do something.
• Trust. Watching someone make steady progress for months is often more convincing than a polished landing page.

How open should you be?

Openness is a range. At one end are companies that publish even their salaries and revenue; at the other are founders who share only process and decisions. Arvid Kahl shared his previous company's revenue openly and credits that visibility with the acquisition interest that led to its sale. In an April 2026 essay he says he would no longer share numbers, because AI coding agents make whatever you reveal much faster to copy.

Upvera itself builds in public on its own startup page: releases, launches and events go up as they happen, without business numbers.

The lesson: how open you are is a choice, and it can change.

How to start

Where should you post?

Start where your customers are, not where the founder crowd is: the social network they already use, the communities of their industry, your own blog or newsletter. Showing up consistently in one place beats appearing now and then in five. For the daily record itself, Upvera is made for this: every day stays on your startup's page, and the sources you connect fill in the work.

How often?

The right rhythm is the most frequent one you can keep. For most people that means a few short notes during the week and one weekly recap. Posting once a week for a year beats posting daily for three weeks and then vanishing.

What goes into a good update?

Four parts: what you did, why, what happened or what you learned, and what is next. Add something visual if you can: a screenshot, a short screen recording, a link to the commit. End with a real question and you are more likely to get a reply.

Example update (invented, use it as a template):

Rebuilt the invoice screen this week. Most users got stuck on the VAT field, so it now fills itself in. Support emails dropped in the first two days, but foreign currencies are still broken. Next up: currency support. Should users enter the exchange rate, or should we fetch it?

What does a simple weekly rhythm look like?

• Monday: one sentence on what you want to finish this week.
• Tuesday to Thursday: one short note a day, what you did plus a screenshot. Five minutes, no more.
• Friday: the weekly recap. What the goal was, what happened, what you learned, what is next.
• Weekend: reply to comments. Half of building in public is the conversation.

What not to share

What you post stays online; people screenshot and archive. Run through these five before you publish:

• Customer and user data. Names, emails, phone numbers, addresses, or a detail that makes one customer recognizable. Under EU rules, personal data is any information relating to an identified or identifiable living person, and pieces that identify someone once combined count too. The classic accident is an admin dashboard screenshot with a list of emails in the corner. Blur it, or take the screenshot with fake data.
• Passwords, API keys and tokens. They hide in terminal output, .env files and address bars. GitHub's guidance for a secret pushed to a repository is to revoke or rotate it first, and it notes that rewriting history does not remove it from other people's clones. The same goes for a post: deleting it is not enough, rotate the key.
• Unannounced deals. A customer you are negotiating with, a partnership that isn't signed, a conversation with an investor. Naming them before they are ready can cost you both the trust and the deal.
• Numbers you'd regret. Revenue, customer counts, costs. You never have to share them. If you do, pick a number you would still share when it drops. Kahl's test helps here: share what people would want to follow, and hold back what would make you easy to clone.
• Other people's information. A teammate's mistake, a falling-out with a former co-founder, a customer's private message. Tell your own story; theirs needs their consent.

Common mistakes

• Posting only wins. People connect with problems and fixes; a feed of victory laps reads like advertising.
• Writing about effort instead of work. "Grinded all day" says nothing. "Found the bug in the checkout flow" says something.
• Pasting the same text everywhere. Readers on different channels expect different things.
• Ignoring replies. Posting without talking back is writing on a wall.

When it doesn't work

Building in public is a habit, not a distribution channel; on its own it does not sell anything. If your buyers are not on these channels, say procurement teams at hospitals, the people watching your process may never become customers. If your work depends on secrecy, such as defense, health data or a market where copying is fast, openness raises your risk. And if writing drains you instead of helping you think, shrink the rhythm or stop; the product still gets built.

Questions

Do I need an audience before I start?

No. Your first posts will reach few people, but you get practice and you leave a trail. When someone finds your product three months later, they can read those three months.

Will someone steal my idea?

The risk is real: Kahl argues that AI coding tools have made copying a product much easier. So share process, decisions and lessons rather than your architecture, the services you depend on or your numbers. Those are harder to clone.

Do I have to share revenue?

No. You can tell the story without numbers. "Our first paying customer arrived this week" carries less risk than the amount and is often enough.

What if I have nothing to show this week?

Write about where you got stuck, a decision you made or an idea you dropped. "I cut a feature this week, here's why" is usually a good post.

How Upvera does it

Upvera is a progress platform where startup founders and independent builders share what they build every day. You add your startup, which gets a public page, and post what you did today in a line. If you connect GitHub, the App Store, Vercel or npm, pushes and releases are read from the source and added to your days automatically. Days are sealed into an append-only ledger, and daily roots are published to a public GitHub repository with an OpenTimestamps proof that anyone can check at upvera.co/dogrula. The community responds with Prime ("interesting, lift it") or Pass ("not for me"). Add your startup or see how Upvera builds itself.

Sources

• Arvid Kahl: The Increasing Risk of Building in Public (April 2026)
• GitHub Docs: Removing sensitive data from a repository
• European Commission: What is personal data?