Does Building in Public Still work?

Question: Does building in public still make sense now that AI lets developers ship products in days instead of months?

Building in public isn’t dead, but the old version of it has lost a lot of its usefulness. When software took months or years to build, the build itself had enough weight to carry the story. There were architecture decisions, messy debugging sessions, slow feature work, customer feedback loops, and enough visible progress for an audience to follow along. Now that AI tools can help a solo builder get from idea to working MVP in a weekend, the interesting part often isn’t the code anymore. It’s whether the idea is worth building, whether anyone wants it, whether anyone can find it, and whether it can become a real business instead of another shipped-but-forgotten side project.

Building in public made sense when the build was the journey

The original appeal of building in public was simple: instead of disappearing for a year, building something in private, and then launching to silence, you’d document the process as it happened. Founders, indie hackers, solo developers, and small product teams used Twitter, blogs, forums, newsletters, and later X to show the work in progress. They shared what they were building, what broke, what they learned, what users asked for, and how the numbers were moving.

That worked because software used to have a much longer visible arc. You could spend weeks setting up the foundations, months getting the first serious version out, and years turning a scrappy product into something stable. There was enough material in the process to make the public documentation useful. Someone following along could learn from your technical decisions, avoid your mistakes, and understand how the product changed over time.

It also worked because it made builders feel less alone. A lot of solo work is quiet, uncertain, and easy to abandon. Posting updates gave people a small amount of accountability, a way to attract early users, and sometimes a community that cared before the product was ready. The audience wasn’t just watching a launch. They were watching the product become itself.

What building in public originally meant

At its best, building in public wasn’t just a stream of promotional updates. It was a record of decisions and tradeoffs. People shared daily coding updates, architecture notes, database decisions, debugging sessions, feature roadmaps, revenue milestones, failed experiments, ugly screenshots, half-baked landing pages, and uncomfortable lessons from customer conversations.

That kind of sharing had real value because it exposed the middle of the work. It wasn’t only “we launched” or “we hit a number.” It was “we thought this was the right feature, users didn’t care, so we changed direction.” It was “we picked this stack because it let us move faster, but now we’re paying for that shortcut.” It was “this onboarding flow looked fine to us, but customers kept getting stuck at the same step.”

That’s useful. It teaches. It gives other builders a more honest picture of what making software actually looks like. It also gives potential users a reason to trust the product, because they can see the thinking behind it and the person doing the work.

AI has changed the timeline

AI coding tools have compressed a lot of the visible development journey. They don’t remove the need for judgement, testing, product taste, or maintenance, but they do remove a lot of the slow repetitive work that used to become public update material.

A solo builder can now ask an AI coding tool to generate boilerplate, scaffold database tables, draft CRUD screens, write documentation, fix obvious bugs, suggest refactors, build a simple landing page, create test data, or explain why some messy error is happening. None of that means the result is automatically good. It still needs review, and it still needs someone who understands what they’re trying to build. But the calendar has changed.

What used to be a month of slow visible progress can now become an afternoon of prompting, editing, testing, and cleaning up. What used to be a multi-week MVP can sometimes become a weekend prototype. A basic SaaS dashboard, internal tool, WordPress plugin, content workflow, or small web app can come together quickly when the problem is clear and the stack is familiar.

That creates a strange problem for building in public. If the first working version appears almost immediately, there isn’t much of a traditional development journey to document. The builder still did work, but the public story has fewer natural chapters. There’s less “today I finally got authentication working” and more “I built a working thing, now I need to figure out whether anyone cares.”

When there’s no journey, what are you sharing?

A lot of modern building-in-public content has quietly shifted from documentation to promotion. The posts might still use the language of building in public, but the substance is often different. Instead of process notes, you see launch announcements, revenue screenshots, feature lists, waitlist links, product demos, and marketing updates.

There’s nothing wrong with promotion. Builders need distribution, and most small products die because nobody hears about them. But promotion isn’t the same thing as documenting the build. A launch post doesn’t teach much about the decisions that led there. A revenue screenshot might be interesting, but without context it’s usually more performance than explanation. A feature list can be useful for customers, but it doesn’t tell other builders what was hard, what was skipped, or what turned out to be a bad assumption.

That’s where the phrase starts to feel a bit worn out. If the only thing being shared is “I shipped this” and “here’s the link,” then we’re not really watching someone build in public. We’re watching someone market in public. Again, that might be necessary. It might even be smart. But it’s a different thing.

The bottleneck has moved

The hard part of small software used to be heavily technical for a lot of builders. Could you build the thing? Could you make the database work? Could you ship the feature? Could you keep the app online? Could you make the UI good enough? Those questions still matter, especially for serious products, but for many small apps the first bottleneck has moved.

Now the harder questions are more annoying and less satisfying. Is this a real problem or just a neat idea? Who exactly has this problem? Can you reach them? Will they pay? What words do they use when they search for it? Does the landing page explain it clearly? Is the product positioned well? Is the price sensible? Will people come back after the first use? Can the product survive outside the builder’s own enthusiasm?

That’s where most of the work is now. Distribution, SEO, GEO, social media, customer interviews, positioning, pricing, retention, onboarding, trust, and support are the places where small products get stuck. AI can help with some of that work too, but it doesn’t make the decisions for you. It can draft copy, suggest search angles, summarize customer notes, and generate ideas, but it can’t magically prove that a market exists or that your product deserves attention.

This is a less romantic version of building software, but it’s probably more honest. The code might be the thing you enjoy making, but the business is the thing that decides whether the product lives.

Maybe we’ve been building in public all along, just differently

The better version of building in public today might not be about showing every code commit. It might be about showing the actual uncertainty around the product.

That means sharing marketing experiments, customer conversations, failed landing pages, search data, onboarding problems, pricing changes, retention issues, support questions, and the awkward process of figuring out what the product is really for. It means showing how the idea changed after it touched reality. It means admitting that the MVP was the easy part and that the hard part was getting anyone to care.

For a practical builder, that’s more useful than another screenshot of a generated dashboard. I’d rather read how someone found the first ten users than how they made the settings page. I’d rather see the search queries that surprised them, the customer language they stole for the landing page, or the feature they removed because it confused people. I’d rather see the boring-looking business work that actually moved the product forward.

That doesn’t mean the technical work has no value. It means the technical work isn’t always the main story anymore. In many AI-assisted projects, the code is one part of a wider system that includes the idea, the audience, the writing, the distribution, the support loop, and the builder’s ability to keep going after the fun prototype stage is over.

When building in public still makes sense

Building in public still makes a lot of sense when the work itself is technically interesting. If you’re solving a genuinely difficult engineering problem, building open source software, writing a framework, creating a developer tool, or teaching people how something works, the technical journey is still valuable. There’s a real audience for architecture notes, implementation tradeoffs, debugging stories, and design decisions.

It also makes sense when the audience wants the technical details. If you’re building for developers, makers, sysadmins, WordPress people, AI tool builders, or technical operators, then showing the work can build trust. People like seeing how a tool thinks. They like knowing why a product uses a certain stack, why a feature was delayed, or why a messy edge case matters.

It’s also useful when the builder is honest about the limits. A public build log that says “AI generated the first version, then I spent two days fixing the assumptions” is more useful than pretending the whole thing appeared perfectly. A post that explains what had to be reviewed, rewritten, secured, or simplified is valuable because it shows the real workflow, not the fantasy version.

When it makes less sense

Building in public makes less sense when the technical implementation is thin, repetitive, or mostly handled by AI. If you’re shipping small products every week, there may not be enough depth in each build to justify a full public narrative. A simple directory, wrapper app, internal tool, or content workflow can still be useful, but the development process might not be interesting enough for regular updates.

That doesn’t mean you shouldn’t share it. It means you should be honest about what’s worth sharing. Instead of forcing a build log, share the sharper lesson. Why did you pick that idea? What did you skip? How did you decide the first version was enough? What did users misunderstand? What did search data show? What didn’t work after launch?

The weak version of building in public is a thin stream of “working on something,” “almost ready,” “new feature shipped,” and “link below.” The stronger version gives the reader something they can use, even if they never touch the product.

Should we rename it?

The phrase “building in public” might be too narrow now. It still points at something useful, but it doesn’t quite describe what many builders are actually doing.

“Building a business in public” is probably more accurate for a lot of solo founders. It includes the product, but it also includes positioning, sales, support, content, search, pricing, and the painful gap between shipping something and making it matter.

“Shipping in public” fits people who move quickly and treat each product as an experiment. It’s less romantic, but it’s honest. It says the point isn’t to document every line of code. The point is to put things into the world and learn from what happens.

“Growing in public” works when the product already exists and the interesting work is distribution, retention, and operations. “Learning in public” might be the most generous version, because it leaves room for mistakes and doesn’t pretend every update needs to be a win. “Marketing in public” sounds less noble, but sometimes that’s exactly what’s happening.

The terminology hasn’t really caught up with how software is built now. We kept the old phrase because it sounds familiar, but the centre of gravity has moved.

The useful version now

The useful version of building in public in the AI era is less about proving that you can write code and more about showing how you think. It’s about explaining how you choose ideas, how you cut scope, how you use AI without letting it make a mess, how you validate demand, how you listen to users, and how you decide whether a product deserves more time.

That’s a more interesting story anyway. Watching someone code a CRUD app for six months can be educational, but watching someone turn a rough idea into a product people actually use is more valuable. The code is part of that, but it isn’t the whole thing.

For OSJ-style projects, this matters because many useful small apps won’t have dramatic technical stories. A WordPress workflow plugin, an internal automation receipt layer, a small content tool, or a plain web app might not need a heroic engineering arc. The interesting part might be why it exists, where it fits, what it replaces, and what tradeoffs make it worth maintaining.

So, does building in public still make sense?

Yes, but only if we stop treating the old version as the default. Building in public still works when there’s something useful to learn from the build, the decisions, the mistakes, or the business around it. It stops working when it becomes a thin disguise for repetitive launch promotion.

AI has made the first version of many products faster to create, but it hasn’t made products easier to make meaningful. The hard parts have moved toward judgement, distribution, trust, positioning, customer understanding, and sustainability. That’s where the better public story lives now.

So maybe the question isn’t whether you’re still building in public. Maybe the better question is what part of the journey is actually worth sharing. If the answer is “the code,” share the code. If the answer is “the business,” share that instead. In the AI era, the most useful public build log might not be a record of someone writing software for six months. It might be the messier, more honest record of someone figuring out whether the thing they built deserves to exist.