Build in Public, Get Found: Why a Build Log Beats a Single Launch Day
A launch day gives you one chance to be noticed. A build log gives you a new chance every week. Why building in public helps people, Google and AI answers find your product, and a simple 15-minute routine to do it.
··11 min read
A launch day is one moment. You post, you answer comments, and for a few hours people look at your product. Then the next day starts, with its own launches, and the attention moves on.
I've been building software since 2016, and I build on my own with an AI coding agent (Claude Code). Building got very fast. But a product that's fast to build is also easy to miss, because thousands of others were fast to build too.
That's why Axiean's own project page has a build log, and why every project on Axiean can have one. This post explains why I think regular updates help you more than one big day, and how to do it without it taking over your week.
In short
Building in public means sharing your work while you make it: what you shipped, what broke, what you learned. A build log (or devlog) is where you keep those updates, in order, with dates.
One launch day is one chance to be noticed. A weekly build log gives you .
a new chance every week
Each entry is a new page with first-hand experience, which is what Google's guidance asks for. An Ahrefs study of 17 million citations found that AI assistants cite pages that are 25.7% fresher than Google's normal results.
Write five kinds of entries: Shipped, Learned, Decided, Asked, Milestone. Never share keys, user data or details that help attackers.
15 minutes a week is enough: list, write, share a short version that links back.
What does "build in public" mean?
Building in public means showing your work while you make it, not only when it's finished. You share what you built this week, what went wrong, what you decided and why, and what you're unsure about.
A build log is the home for those updates: dated entries attached to one project, so anyone can read its story from the first idea to today. Game developers have called this a devlog for years. A build log is not the same as a changelog:
Changelog
Build log
Written for
Users who want to know what changed
Anyone curious about the product and the person behind it
You can have both. But only the build log gives people a reason to follow you before they need your product.
Why one launch day isn't enough anymore
There are simply more launches than ever. Product Hunt counted 2,345 launches in Q2 2026, up from 1,508 a year earlier, and new app releases on the app stores grew about 60% in a year. I wrote about these numbers in how to get your first users in 2026.
More launches means each one gets a smaller share of attention, for a shorter time. A good launch day still matters. But if it's your only plan, you get one spike and then silence.
An illustration of the idea, not real data: one big day versus many small ones.
A build log turns that one spike into a series of small moments. Some people miss your launch but see your third update. Some see your launch, aren't ready, and come back when your eighth entry solves their problem. Every entry is another door into your product.
Three ways a build log helps you get found
1. People: more chances to notice you, and more reasons to trust you
People rarely use a new product the first time they see it. They need to see it a few times, and they need to believe it will still be there next month.
Regular entries help with both. Each one is a new reason to visit, and the dates show that someone is still working on it. A product with ten honest updates over three months looks very different from one with a launch post and nothing since.
On Axiean, people can follow you. When you post an entry on a published project, your followers get a notification, and the entry appears in their Following feed.
A build log is first-hand experience by definition. Nobody else can write "how I fixed the email codes in my app" from your point of view.
There's a second benefit: specific entries match specific searches. Very few people search for your product's name. Many people search for the exact problem you just solved. An entry called "Why our sign-up emails went to spam, and the three DNS records that fixed it" can bring the right visitor for years.
3. AI answers: fresh pages get cited more
AI search tools like ChatGPT and Perplexity cite pages when they answer. In July 2025, Ahrefs analysed about 17 million citations and found that the pages AI assistants cite were on average 25.7% fresher than the pages in Google's normal results (1,064 days old against 1,432). ChatGPT preferred the newest pages most.
That's one company's study, so don't treat it as a law. But it points in the same direction as everything else: a page that was updated recently, by someone who did the work, is a good page to quote.
One condition: AI crawlers have to be able to read your entries. Many of them don't run JavaScript, so your updates need to be in the page's HTML. My GEO guide explains how to check this in two minutes.
What to post: five kinds of entries
The hardest part of building in public is not writing. It's knowing what to write about. I use five kinds of entries, and every week fits at least one of them.
Five kinds of build log entries. Any week fits at least one of them.
Shipped. Something changed. Say what it is and why it matters to the user, not only what you did in the code. "You can now export invoices as PDF" is better than "Added PDF library."
Learned. Something broke, surprised you or took longer than expected. These entries get read the most, because they're honest and useful to other makers.
Decided. You made a choice: a feature you won't build, a price, a tool you switched to. Give the reason. People trust a product more when they understand its choices.
Asked. You need input. Ask one clear question: "Would you use this on your phone or your laptop?" Answer everyone who replies.
Milestone. A first: first user, first payment, first 100 sign-ups, first time someone you don't know recommended it. Share numbers only if you're comfortable with them.
Here's a real example. This is the start of the first entry in Axiean's own build log, a Decided entry:
Working with AI tools changed how I build. Things that used to take weeks now take days, and ideas I would once have shelved are suddenly worth a weekend. I'm far from the only one.
But building getting faster didn't make being found any easier.
It's short and plain, and it says why the project exists. That's enough. You can read the whole entry and the rest of the log on Axiean's project page.
A template for one entry
If you don't know how to start, fill in this template. It takes about ten minutes.
Title: [What changed, in plain words]
What I did: [one or two sentences]
Why: [the problem it solves, or the reason for the decision]
What I learned: [one thing that surprised you or went wrong]
What's next: [the next step, without promising a date]
Question: [optional, one question for your readers]
Between 100 and 300 words is plenty. Write the way you'd explain it to a friend.
What never to share
Building in public doesn't mean sharing everything. Before you post, check for these:
Keys and secrets. Screenshots of code, terminals and dashboards often show API keys, tokens or database addresses. Crop them out or blur them, and if one was ever visible, replace the key. My vibe coding security checklist explains why this matters so much.
Users' data. No names, emails or messages from real users without their permission. Not even in a "look, my first sign-up!" screenshot.
Details that help attackers. "We added rate limits to sign-in" is fine. "Here's the exact endpoint that has no rate limit yet" is not.
Promises with dates. "Coming next" is fine. "Ready on Friday" turns a missed Friday into a broken promise.
Numbers you'll regret. Revenue and user counts build trust, but once they're public, they stay public. Decide what you're comfortable with before the first post.
The 15-minute weekly routine
Consistency matters more than length. Pick one day of the week and do this:
List (5 minutes). Look at what changed since last week: your commits, your task list, your notes. Pick the one thing that matters most to a user.
Write (5 minutes). Use the template above. One idea per entry.
Share (5 minutes). Post a short version (two or three sentences) in one place where your users already are, with a link to the full entry.
Keep the full version in one place you'll still have in a year, and share short versions everywhere else. That way the links, the search traffic and the history all build up in one place instead of disappearing in a feed.
On your project's page, sent to followers and shown in the feed
Axiean is new and its community is still small
There's no single right answer. My suggestion: keep the full entries where they stay findable and are linked to your product, and use social posts and communities to send people there.
How build logs work on Axiean
I built Axiean's build logs for exactly this, so here is how they work:
Entries live on your project's page as a timeline, together with milestones like "Launched on Axiean". Each entry also has its own page.
Before launch, entries are your back story. If your project is still a draft, its entries are private to your team. They go public when you publish the project, without spamming anyone.
After launch, entries are news. They appear in the home feed and in the Following feed of people who follow you, and your followers get a notification. The home feed shows at most one entry per project per day, so nobody can flood it.
They're readable by machines. Entry pages are rendered on the server, with structured data, and listed in Axiean's sitemap, so search engines and AI crawlers can read them.
You can tag them with the AI tools and technologies the entry is about, so people interested in those tools find them.
Entries are text only for now (no images yet), up to 10,000 characters.
The build log on Axiean's own project page.
If you're building something with AI, publish your project and write your first entry the same day. A good first entry is simply: why are you building this, and who is it for?
Your first four entries
If you're starting today, these four entries give your log a strong beginning:
Why I'm building this. The problem, who has it, and why you care. (This is also the best way to find your one-sentence focus.)
How it works today. The first version, honestly: what it does and what it doesn't do yet.
The first thing that broke. Every product has one. Sharing it shows you're paying attention.
What the first users told me. What they liked, what confused them, and what you'll change.
After that, use the five kinds of entries above, once a week.
Common worries
"Someone will copy my idea." With AI, anyone can copy a feature in a weekend, whether you share it or not. What they can't copy is the trust and the audience you build by showing your work.
"I have nothing to write this week." Then write a Learned or Decided entry. A week without shipping usually means you were stuck on something, and that's interesting.
"Nobody reads it." At first, that's true. Build logs work slowly: the tenth entry is read by people who found the third one in a search. Keep going for three months before you judge it.
Frequently asked questions
What is building in public?
Building in public means sharing your work while you make a product: what you shipped, what went wrong, what you decided and why. Makers do it to get feedback early, to build trust, and to give people many chances to discover the product instead of one launch day.
Does building in public really work?
It works best as a habit, not a single post. Regular updates give people more chances to notice you, show that the product is alive, and create pages that search engines and AI tools can find. It won't fix a product nobody needs, but it helps a useful product get found.
What should I post when building in public?
Post what you shipped, what you learned, the decisions you made, questions for your users, and milestones. One idea per post, written plainly. Never post keys, users' data or details that would help an attacker.
How often should I post a devlog?
Once a week is a good rhythm for most solo makers. It's frequent enough to keep people interested and rare enough that you always have something real to say. A regular day matters more than the exact number.
Does a build log help SEO?
Yes, if search engines can read it. Each entry is a new page with first-hand experience, and specific entries match specific searches. Keep entries in the page's HTML (not only loaded by JavaScript) and link them to your product.
What's the difference between a changelog and a build log?
A changelog is a short list of what changed, for users. A build log tells the story behind it: why you made a change, what you learned and what's next. Many products have both.
"Slop" was Merriam-Webster's word of 2025, and people now look for signs of it. What makes an AI-built product feel like slop, what makes it feel cared for, whether you should say you used AI, and what Google, the FTC and the EU AI Act say in 2026.
AI gets you to a working demo fast. The last 20% (errors, emails, payments, accessibility, languages, privacy, backups) is what turns it into a product. Twelve things AI usually leaves unfinished, how to check each one, and what to ask your AI.
··15 min read
The words around building with AI change every few months. Here are 40 of them, explained in plain English: what they mean, where they came from and why they matter to you. From vibe coding and MCP to context engineering, slopsquatting and llms.txt.
Vahid Aslani
