To post a build log online that's honest and still gets read, make each post about one specific thing you learned or decided, show the real number with its context (even if it's small), and say how you used AI. Readers follow a process they can learn from; they don't need big numbers. Never buy followers, invent users or post fake reviews, and say clearly when a post is about your own product.
How do I post a build log online that's honest and still gets read?
You're building something with AI, and you've heard you should "build in public": post your progress on X, LinkedIn or a subreddit so people follow along. Then you sit down to write the first post and hit two problems at once. Your numbers are small, and the posts that seem to get attention all have big ones.
The pull is to round up, leave out the bad week, or make it sound further along than it is. Don't. An honest build log can still get read, and it's the only kind that keeps working once someone checks.
What do the people who write about this agree on?
Most advice on building in public comes from founder blogs and marketing pages, and much of it is selling a tool. A few sources stand apart: a writer's own guide, Google's guidance for creators, and the FTC's rules on endorsements and reviews. They come from very different places, but they agree on more than you might expect.
Share the process, not just the result. Austin Kleon's Show Your Work! makes the case that you build an audience by sharing your process as it happens, in small pieces, rather than waiting for a finished product. A build log is exactly that. The interesting part is not "launched v2." It's what you tried, what broke and what you changed.
Show first-hand evidence. Google's guide to creating helpful, reliable, people-first content asks whether content shows first-hand experience, and suggests explaining how something was made, with evidence like photos or results. It also says it's useful to disclose substantial use of AI where readers might ask how the content was created. For a student building with AI, that's a gift: your prompts, the bug the assistant introduced and how you caught it are real first-hand material nobody else has.
Don't fake signals of popularity. The FTC's final rule on fake reviews and testimonials bans reviews from people who don't exist or have no real experience with the product, including AI-generated ones. It also bans buying or selling fake indicators of social media influence, such as bot followers or views, when used to misrepresent influence for a commercial purpose. A student project may never get near the FTC, but the rule draws the line in the right place.
Disclose when there's a relationship. The FTC's Disclosures 101 for social media influencers says to disclose any financial, employment, personal or family relationship with a brand, and to put the disclosure where it's hard to miss, not buried in a bio or a cluster of hashtags. If your roommate posts about your app, they should say they're your roommate.
Where do they disagree or go quiet?
They disagree on how much to share. Kleon's advice leans toward sharing a little every day. There's a practical caution none of these sources dwells on: you may not want to post every metric, every user's details or your whole playbook. Both can be true. Share the lesson and the shape of the number; keep private anything that identifies a user.
None of them is written for students. None says how to talk about a product that has five users, or what to do when a post gets reach but nobody signs up. That's where the practical part comes in.
A five-part build log post that people can actually use
Each post should be about one week, or one decision, and nothing else.
- One line on what changed. "This week I cut the sign-up form from six fields to two."
- The real number, with its context. "Before: 4 of 15 testers finished sign-up. After: 9 of 14." Say where the number comes from (your analytics, a spreadsheet of tester notes) and the date range.
- What a user actually said or did. A short paraphrase, with no names, unless they agreed to be named.
- How you used AI. Which tool, what you asked it, what it got wrong. One or two sentences.
- What's next, or what you're stuck on. A specific question gets better replies than "thoughts?"
Then check it against this list before you post:
| Check | Why it matters |
|---|---|
| Every number has a source you could show | If someone asks, you can post the screenshot |
| Visits, sign-ups and active users are labeled as different things | Mixing them is the most common accidental inflation |
| Nothing identifies a user without their consent | Their privacy matters more than your post |
| Friends or family who promote it say they know you | The FTC guidance treats these as relationships to disclose |
| No bought followers, likes or reviews | Fake signals are banned for commercial use and fall apart when checked |
| It's clear this is your own product | Readers should never have to guess |
How do you get it read without inflating it?
Honesty doesn't mean writing badly. A few things help an honest post find readers:
- Lead with the lesson. "Two sign-up fields doubled completions" is a better first line than "Week 4 update."
- Post where the problem lives. If your tool helps nursing students, a nursing subreddit or a campus group will care more than general startup accounts. Read each community's rules on self-promotion first; many limit it.
- Be consistent. One post a week, on the same day, beats five posts in launch week and then silence.
- Post the bad weeks. "Nobody came back after day one, and here's my guess why" is often the most read post in a log, because other builders recognize it.
- Reply to people. A build log is a conversation. The people who reply are often your first real users.
How STARC handles build logs
STARC is a small nonprofit, and its one-person company cohort asks every student to write one build log a week for eight weeks: what shipped, numbers, what users said, where you're stuck, next step, and how you used AI. Logs need evidence for their numbers, and faked data ends your participation. Logs are visible only to the cohort by default. Each one is published only if the student agrees, with their name or anonymously, and it can be withdrawn later.
The first cohort hasn't run yet, so there are no published logs to show. The rules are on the How it works page, and common questions are in the FAQ.
The short version
Write about one thing per post. Show the real number and where it came from. Say how you used AI. Disclose when the person praising it knows you. Then post consistently, including the weeks that went badly. The build logs worth reading are the ones a stranger could check.
Related questions
Will people read a build log if my numbers are tiny?
Often, yes, if the post teaches something. A post that explains why 3 of your 12 testers quit on the sign-up screen is more useful to other builders than "we hit 100 users!" Small numbers with a clear lesson are the normal state of an early product.
Do I have to say I used AI to build it?
Nothing forces you to on most platforms, but say it anyway when readers would wonder. Google's guidance on helpful content encourages explaining how content was made, including the role of AI, because it builds trust. In a build log, how you used AI is often the most useful part.
Can I ask friends to post about my product?
You can, but their posts should say they know you. The FTC's guidance for influencers treats personal and family relationships as connections that need a clear disclosure, and asking friends to post as if they were strangers is the kind of thing that destroys trust.
Is it OK to post screenshots of my analytics?
Yes, and it's the best evidence you have. Crop out anything that identifies a user, keep the date range visible, and say what the number does and doesn't mean (visits are not users, sign-ups are not active users).
Want to build your own product?
The OPC cohort: 12 students, 8 weeks, one real product with real users.
Last updated: 2026-10-16. Written by the STARC team. Rules quoted here come from our transparency page; if they change, this post is updated.
More questions
My AI-built website is slow: what can a student actually fix?
Why a website you built with AI loads slowly, how to tell whether it's slow for everyone or only some visitors, and the fixes worth doing first.
Mobile app or web app: which should a student build first with AI?
For students building a first product with AI: why a web app is usually the better first build, when a mobile app is worth it, and the store rules to know.
Non-CS major applying for product manager jobs: does building your own product help?
For non-CS majors aiming at PM internships and APM roles: when a product you built yourself helps, when it doesn't, and what interviewers will ask.