Building Contensa in public meant shipping imperfect things, getting real feedback early, and learning faster than we ever could have in stealth. Here's the honest story.
Michael Chen
AI/ML Engineer
We started building Contensa about a year ago. We shipped the first version to real users six months in. We've been building in public ever since — sharing what we're working on, what's broken, what we're learning.
Here's what that experience has actually been like, and what we'd do differently.
The honest answer: we weren't sure it was the right call. Building in public means showing your work before it's ready. It means getting feedback on things that aren't finished. It means being transparent about failures in a space where everyone else is projecting confidence.
But we'd watched too many startups spend 18 months building in stealth, launch to silence, and spend the next 18 months trying to find product-market fit they could have found in month three.
We decided the risk of building the wrong thing was greater than the risk of building imperfectly in public.
For us, building in public meant:
It did not mean sharing everything. We kept some things private: specific customer conversations, financial details, and strategic decisions that weren't ready for public discussion.
The first version of Contensa was rough. The AI content model generation worked about 70% of the time. The UI had obvious gaps. The documentation was sparse.
But shipping it forced us to answer a question we'd been avoiding: what is the core value proposition, stripped of everything else?
The answer we got from early users was clear: the time savings on content modeling. Not the AI content generation (which was cool but not the primary value). Not the GraphQL API (which was expected). The fact that they could go from project brief to working API in 30 minutes instead of two days.
We would not have learned this as quickly if we'd waited until the product was "ready."
The people who used Contensa when it was rough and gave us feedback became our most loyal users. They felt ownership over the product. When we shipped features they'd requested, they told their networks.
This is the compounding benefit of building in public that nobody talks about: early users who feel heard become advocates. They're not just customers — they're invested in your success.
Posting weekly updates created accountability. If we said we were going to ship the visual content modeler by Friday, we shipped it by Friday. The public commitment made the deadline real in a way that internal deadlines often aren't.
This sounds like a small thing. It wasn't. We shipped faster because we were accountable to people outside the company.
Early on, we posted a lot about what we were building — the technical decisions, the architecture, the tradeoffs. This was interesting to other developers but not to the people we actually needed to reach: content teams, agencies, product managers.
We should have led with outcomes — "here's what you can build with Contensa" — and saved the process content for developer-focused channels.
Building in public attracted users faster than we expected. That was great. What we didn't anticipate was the support burden that came with it.
Early users have high expectations and low tolerance for rough edges. They're willing to give feedback, but they also expect that feedback to be acted on quickly. We spent more time on support in the first three months than we'd budgeted for.
If we did it again, we'd build more robust self-service documentation before going public, not after.
We shared our wins publicly. We were more hesitant about our failures. In retrospect, the failures were more interesting and more useful to our audience.
The post where we explained why we'd rebuilt our schema generation system from scratch — after the first version turned out to be fundamentally flawed — got more engagement than any of our feature announcements. People connected with the honesty.
We should have shared more of that.
Consistent public writing about what we were building created a body of content that drove organic traffic. People searching for "headless CMS comparison" or "AI content modeling" found our posts. Some of them became users.
This wasn't the primary reason we built in public, but it turned out to be a significant benefit.
Several of our early team members found us through our public writing. They'd been following our progress, believed in what we were building, and reached out when we posted that we were hiring.
Building in public is a recruiting strategy. The people who find you through your work are often better fits than the people who find you through job boards.
When we started talking to investors, we had a public track record. They could see our progress over time, read our thinking, and evaluate our judgment — not just our pitch deck.
Building in public is also a fundraising strategy.
Ship earlier than you're comfortable with. The version you're embarrassed to ship is probably good enough to get real feedback. The version you're proud of is probably six months away.
Lead with outcomes, not process. Your audience cares about what they can do with your product, not how you built it. Save the technical deep-dives for developer-focused channels.
Build your support infrastructure before you need it. Documentation, FAQs, onboarding flows — these are not afterthoughts. They're what make building in public sustainable.
Share the failures. The honest posts about what went wrong are more valuable than the polished posts about what went right. Your audience can tell the difference.
Be consistent. Building in public is a long game. One post doesn't build an audience. Consistent, honest sharing over months and years does.
Contensa is in a very different place than it was a year ago. The AI content model generation works reliably. The API is stable. The editor experience is polished. We have real users building real things with it.
We're still building in public. We're still sharing what we're working on, what's broken, and what we're learning. We think that's the right way to build a product — and a company.
We're building Contensa in public. Follow along and start your free workspace — we'd love to hear what you're building.
The way we build content infrastructure is changing faster than most teams realize. Here's where it's heading — and what it means for developers, content teams, and the tools they use.
Learn how to set up Contensa CMS in minutes with this step-by-step guide covering installation, configuration, and fetching your first content.
Discover how to leverage Contensa's AI content generation features to streamline your workflow and create high-quality content faster.