A build-in-public roadmap to your first customer and first feedback

Building in public is a distribution habit, not a strategy

Building in public means sharing the work while it is happening: the metrics, the decisions, the mistakes, the changelog. Buffer did it with company salaries in December 2013 and still publishes its revenue dashboard. Thousands of indie developers do it on X, Indie Hackers, Bluesky and LinkedIn today.

It works for one reason. People trust someone they have watched work, and trust is what a stranger needs before paying a one-person company. It fails for one reason too. The audience that applauds a build-in-public post is mostly other builders, and other builders are rarely your customers.

Max, the maker of Flowly, wrote this up on Indie Hackers on 1 June 2026. A post of his drew 500 views and 50 comments in a day and produced no customer. His line is the one to keep: "Applause from builders is a measurement of how good your post was, not how good your product is."

So the roadmap below pairs every public action with a private measure. The public side builds trust. The private side tells you whether anybody has the problem. You need both, and you need to stop confusing them.

Here is the whole route. The weeks are a default pace for someone with evenings and weekends. Slower is fine. Skipping a stop is not.

1. Stop 0, day one. Write the one-line promise and list ten named people. Move on when all ten are real people you can reach this week.

2. Stop 1, week one. Hold ten conversations and keep notes. Move on when three or more describe the same problem unprompted.

3. Stop 2, weeks two to three. Start a public changelog and post the first three updates. Move on when a stranger replies with a question about the problem.

4. Stop 3, week four. Ship a floor version and set up ten users by hand. Move on when five of the ten use it a second time.

5. Stop 4, week five. Keep a feedback log with sources. Move on when you can name the top three complaints with a quote each.

6. Stop 5, week six. Launch once, on one board, with a question in the listing. Move on when you get feedback from someone you have never spoken to.

7. Stop 6, weeks seven to eight. Set a price and ask. Move on when one person pays.

8. Stop 7, ongoing. Keep two dashboards and post one weekly update. You are on track when customer metrics move independently of audience metrics.

Stop 0: write the promise and name ten people

Before any post, write one sentence: who it is for, what it does, what it replaces. "Invoice reminders for freelance designers who chase payments by email" is a promise. "A smarter way to manage client work" is not. If you cannot name the person and the thing they do today instead, you are not ready to build in public, because you have nothing specific to be public about.

Then write down ten named people who match the sentence. Not personas. People, with a way to reach each one. Look in your own contacts, a forum, a Slack group or a subreddit where they already complain. If you still cannot fill the list, that is your first finding: the audience is harder to reach than you thought, and the sentence may need to change.

Public output at this stop: nothing. Private output: the sentence and the list.

Stop 1: have ten conversations and log the facts, not the compliments

Rob Fitzpatrick's book The Mom Test sets three rules for these conversations: talk about their life instead of your idea, ask about specifics in the past instead of opinions about the future, and talk less. The questions that work are "talk me through the last time that happened", "what else have you tried" and "why do you bother". The questions that fail are "would you use this" and "is this a good idea", because everyone says yes to be kind.

Do ten of these. Fifteen minutes each, by call or in person, not by survey. Write down what they do today, what it costs them in time or money, and what they already tried. Write down the exact words.

This is the first thing worth posting. Not the idea, the findings: "Talked to ten freelance designers this week. Seven chase at least one late invoice a month. Four use a spreadsheet, three use memory, none use software." That post is useful to other builders, it shows you work from evidence, and it costs you nothing in secrecy because the finding is not the product.

Move on when three or more people described the same problem without you naming it. If nobody did, change the promise, not the people.

Stop 2: start a changelog before you start a landing page

The default build-in-public move is a landing page with a waiting list. Skip it for now. A waiting-list signup is the weakest signal in the business: it costs the visitor nothing and tells you nothing about whether they will pay.

Start a public changelog instead. A page, a thread, or a weekly post with the same shape every time: what you shipped, what you learned, what is next. Three entries make it a habit the reader can follow. Date every entry.

The changelog does two jobs. It gives you something to post that is true and specific every week, so you never have to invent content. And it is a record a future customer can read to decide whether you are the kind of person who finishes things.

Keep the post about the problem, not the stack. "Added the overdue-invoice detector; it misses invoices sent as PDF attachments, fixing that next" is read by designers. "Migrated to Postgres" is read by other developers, who will not pay you.

Move on when a stranger, meaning someone not on your list of ten, replies with a question about the problem rather than a compliment about the project.

Stop 3: ship a floor version and set up the first ten users yourself

A floor version is the smallest thing that does the one job in the promise, end to end, for one person. Not a minimum viable product with onboarding, billing and settings. One job. If the promise is invoice reminders, the floor version sends one reminder for one invoice, and you may be the one pressing the button behind the scenes.

Then recruit users by hand. Paul Graham's essay Do Things That Don't Scale describes how the Stripe founders handled early users who agreed to try the product. Instead of sending a link, they asked for the laptop and set it up on the spot. He calls it the Collison installation. Do the same, over a screen share if you must. Nobody at this stage installs anything from a link in a post.

The first ten users should be the people from stop 1 who described the problem. They already told you what hurts, and you are going back with the thing that fixes it. That is not a cold pitch. It is a follow-up.

Post the setup sessions: what broke, what the user did that you did not expect, what you changed the same evening. This is the most-read kind of build-in-public content, because it is specific and slightly embarrassing.

Move on when five of the ten use it a second time without being asked. Second use is the first signal that is hard to fake out of politeness.

Stop 4: collect feedback where it costs the giver something

First feedback comes from four places, in descending order of value.

1. Behaviour. What the ten users did and did not do inside the floor version. A feature nobody touches is feedback. Log it.

2. Unprompted messages. A user who writes to you about a bug or a missing piece is spending their time. That is the strongest written feedback you will get.

3. Answers to one specific question. After the second use, ask one question: "What almost stopped you from using it today?" One, not a form of twelve.

4. Public replies. Comments and quote posts on your changelog. Useful for noticing patterns, useless for deciding features, because the commenters are not the users.

Keep a feedback log with four columns: date, who, what they said in their words, and where it came from. Weight it by source using the list above. Three users hitting the same wall beats fifty likes on a feature announcement.

Post the top three complaints, in the users' words, with what you will do about each. Makers rarely do this, and it is the single most credibility-building thing you can publish, because it proves you listen and it tells future customers what to expect.

Move on when you can name the top three complaints and quote a user for each.

Stop 5: launch once, on one board, with a question attached

By now you have a changelog with a few weeks of entries, a floor version, ten users and a feedback log. That is a launch, and it is the moment to put the product in front of people you have never spoken to.

Pick one board, not ten. A launch spread across every directory in one week produces ten thin listings and no conversation. Pick the board where you can answer every comment for a week.

We run one. AppBoard.pro is free to launch: you sign in, paste your URL, the form prefills from your site, you review the categories and pricing, and submit. Products rank by a Points-Based Score (PBS) built from upvotes, saves, follows, ratings and real click-throughs, with recent activity weighted more than old. Promotion is a separate paid placement and does not touch the score. Products enter a queue and publish in turn, so submit when the floor version is ready, not the night before you want attention.

Two things the board does well for this stop. Anyone with an account can comment and review, so the listing becomes a second feedback channel from strangers. And every product can be listed as an alternative to an established tool, which is where the people with the problem are searching long after launch day.

Two things it does not do. It does not bring you customers by itself; a listing is a surface, and the traffic to it on day one is mostly makers and seekers, not your ten designers. And it does not replace the conversations in stop 1. Nothing does.

Whatever board you choose, write the listing around a question. "Freelance designers: how do you chase late invoices today?" gets replies. "Introducing InvoiceNudge, the smart way to get paid" gets upvotes from builders and silence from designers. Then answer every comment, and copy anything useful into the feedback log with the source marked "launch comments".

Move on when you have feedback from at least one person you have never contacted.

Stop 6: put a price on it and ask

A customer is someone who pays. Not a signup, not a star, not a "would totally pay for this". Until money moves, you have users, and users are cheap to collect and easy to misread.

Pick a price from what you learned in stop 1. If seven designers chase a late invoice a month and each chase costs an hour, the tool that removes it is worth something a month. You heard the number in stop 1, when you asked what they already tried and what it cost. Set one price, monthly, with no free tier yet. A free tier before the first customer tells you who likes free things.

Then ask the ten users directly, one at a time, in a message that says the price and asks for a yes or no. Not a launch post. Not a pricing page tweet. A message to a named person who has used the thing twice. Expect most to say no. Write down the reasons; they are the best feedback in the whole roadmap.

If nobody pays, you have learned something true before building a billing system, and the changelog entry writes itself. If one pays, post it, with their permission, and say what they paid for. "First paying customer: a freelance illustrator in Lisbon, 9 euros a month, after we fixed the PDF attachment bug she reported" is the build-in-public post people remember, and it is only possible because you logged the feedback.

Move on when one person has paid.

Stop 7: keep two dashboards and never mix them

From here the roadmap becomes a weekly loop. The one rule that keeps it honest is Max's: keep audience metrics and customer metrics on separate dashboards, and never let one stand in for the other.

The audience dashboard holds followers, post views, replies and changelog readers. It tells you whether the public habit is working. The customer dashboard holds conversations held, second uses, paying customers, churn and the reasons people said no. It tells you whether the product is working.

A weekly public update then has a fixed shape: one number from each dashboard, one thing shipped, one thing learned, one thing next. Buffer has published its numbers monthly since 2013 and the format has not needed to change. Yours will not either.

When the customer dashboard moves and the audience dashboard does not, you have found a channel that is not your audience, which is the whole point. When the audience dashboard moves and the customer dashboard does not, you have written a good post. Enjoy it, then go back to stop 1 with the next ten people.

What to do now

Write the one-sentence promise and the ten names tonight. Book three of the ten conversations for this week. Start the changelog with entry one: the promise, the list, and the date. Everything else on the roadmap follows from those three things, and none of it needs an audience yet.

When ten people have used the floor version twice, launch it on AppBoard.pro with a question in the listing, and treat every comment as a row in the feedback log.

Sources: Rob Fitzpatrick, The Mom Test · Paul Graham, Do Things That Don't Scale (July 2013) · Buffer, Transparency Timeline · Max, "Your build in public audience is not your market", Indie Hackers (2026-06-01) · How AppBoard.pro works (2026-10-08).