A build in public cohort is a group of people who start and finish a project together on the same schedule and share their progress as they go, usually in weekly posts or logs that the others read and respond to. It suits students who need deadlines and honest feedback to actually ship. It's a poor fit if you'd be posting for attention rather than to learn, or if the program decides for you what goes public.
What is a build in public cohort?
Take the two halves separately.
A cohort is a group that starts together, works on the same schedule and finishes together. Many graduate programs are built this way, and so are some short courses and fellowships.
Building in public means sharing your work while you're still doing it, not only when it's finished. Austin Kleon's book Show Your Work! makes the core argument in one of its chapter titles: "Think process, not product."
Put them together and a build in public cohort is a group of people who each build something over a fixed number of weeks and share the process as they go, usually through a weekly post or log that the rest of the group reads, questions and responds to. The interesting design question is the one most descriptions skip: public to whom? To the group? To the whole internet? To future employers? Programs answer that very differently.
What do people who've written about it agree on?
The sources below come from different places: a writer's book, a bootstrapped founder's blog, a software engineer's critique, a university study of cohort learning and a university career resource. On a few points they line up.
Sharing creates a feedback loop. Arvid Kahl, a founder who writes about bootstrapping, describes building in public as a loop between building and sharing: you learn while you build, you share what you learned, and the responses tell you what to build next. Without sharing, he argues, you risk building on assumptions nobody has tested. Kleon makes the same case from the creative side.
Being in a group changes how the work feels. A small 2024 qualitative study in Frontiers in Education asked 13 alumni of a one-year cohort-based master's program in public health about the experience. They reported feeling more connected to the program and to each other, and described learning as a shared process. It's a small sample in one field, and the authors don't claim more than that, but it matches what anyone who's been in a good study group knows.
Your public record matters. A Purdue University career resource quotes a career services manager saying employers often look at candidates' social media even when the candidate hasn't pointed them there. Its advice is to look at your profile as if you were an employer. For a student, a steady trail of real work can be the most useful thing they find.
Where do they disagree, or go quiet?
On whether you should build in public at all. Software engineer laike9m, in a post called No One Builds in Public, argues that the practice has become saturated. Many posts brag about revenue rather than explain the product, and when everyone is doing it, attention is spread so thin that little of it lands. He points to successful indie developers who post little or never share their revenue, and concludes that building in public works for some people but isn't required. Kahl admits a related cost: early on, sharing can feel like shouting into the void, because an audience takes time to form.
On how much to share. Kleon leans toward sharing something small every day. Kahl says there's no fixed ratio between building and sharing, only that you keep the loop going and post things that teach something. Neither talks about what you shouldn't share.
On students. None of these sources is written for a student deciding whether to join a program. None addresses your users' privacy, what happens when the project fails halfway, or who decides what gets published. Those are exactly the questions that separate a good cohort from a bad one.
Is a build in public cohort right for you?
A simple way to decide:
| It's probably a good fit if… | It's probably a poor fit if… |
|---|---|
| You start projects and stall without a deadline | You already ship steadily on your own |
| You want people to read your work and push back every week | You mostly want followers or reach |
| You can give it real hours every week for the whole run | Your semester is already full |
| You're fine writing honestly about weeks that went badly | You'd feel pressure to make every week look good |
| The program lets you decide what goes on the open internet | The program requires public posts you can't take down |
The last row matters most. Being read by a small group that knows your project is where most of the value is. Being visible to the whole internet is optional, and it should be your choice.
Questions to ask before you join any build in public cohort
- Who sees my posts by default? The group, reviewers, or everyone?
- Can I publish anonymously, and can I take a post down later?
- What exactly is due each week? "Share your progress" is vague. A defined deliverable is not.
- Who gives feedback, and is it a person? If AI drafts any of it, is that disclosed?
- How are numbers checked? A cohort where anyone can claim anything rewards inflation.
- What happens if my project doesn't work? A good program has an honest outcome for that, not just a quiet exit.
- What does the program promise? Be wary of any cohort that promises followers, users, revenue or admissions.
If a program can't answer these in writing, ask why.
How STARC handles it
STARC's one-person company cohort is a cohort that builds in the open, with the public part left to each student. Twelve students spend eight weeks, about 10 hours a week, building a small real product with AI. Each student writes one build log a week, due Sunday, covering what shipped, the numbers, what users said, where they're stuck and how they used AI. There's a one-hour group review each Wednesday, and peer pairs test each other's products.
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. Logs need evidence for their numbers, and faked data ends participation. The cohort ends with a public Demo Day: the live product, the real numbers and the full log, including what didn't work. A project that doesn't find users can still graduate as Completed, with a case study explaining why.
The first cohort hasn't run yet, so there are no published logs to point to. The full rules are on the How it works page, and the FAQ covers who can apply.
The short version
A build in public cohort is shared deadlines plus shared progress. Most of its value comes from people reading your work every week, not from an audience on the open internet. Join one if you need structure and honest feedback, check who sees your posts by default, and keep control of what goes public.
Related questions
Do I have to post everything publicly in a build in public cohort?
It depends on the program, and that's the first thing to ask. Some expect public posts on X or LinkedIn every week; others keep progress inside the group and let you choose what goes on the open internet. Check the default before you join.
Is building in public bad for my privacy or my job search?
It can help or hurt. Employers do look at candidates' public profiles, so a steady record of real work can help, while oversharing or posting things you'd regret can hurt. Never post anything that identifies your users without their consent.
Can I build in public if my project fails?
Yes, and a documented failure is often more useful to readers than a polished success. What matters is that the record is honest: what you tried, the real numbers and what you'd do differently.
How is a cohort different from just posting on my own?
A cohort adds shared deadlines, people who read your work every week and give feedback, and a fixed end date. Posting alone gives you full control, but nobody notices if you stop.
Build something real
OPC cohort or research track: real work, judged by what you actually made.
Follow STARC on X. New posts, what we're building, and the questions students send us: @Starc_Institute
Follow on XLast updated: 2026-11-01. Written by the STARC team. Rules quoted here come from our how it works page; if they change, this post is updated.
More questions
What can I build with AI in 48 hours? One-page tool ideas for beginners
What a beginner can really build with AI in 48 hours: one-page tool ideas, a weekend schedule, and what to leave out so you actually ship.
Should I put vibe coding on my resume as a student?
Should you put vibe coding on your resume? Why the phrase is risky, what to write instead, and how to show AI-assisted work honestly.
Sophomore or junior: should I do research or build a product, and how do I split my time?
Research or your own product in sophomore or junior year? Pick by your next step, give one a main slot, and plan around summer and REU deadlines.