Why we're building bakeqee in public

Building bakeqee in public. What we show, what we don't, and why this transparency makes business sense at all.

Before we had bakeqee, we had an idea, a few sketches, and 12 versions of a welcome email. Now we have a website, a bit of code, and 100 free Founding Member spots. What happened in between, we describe in public. That's called "Build in Public," and in this article we explain what we mean by it, and why we do it.

What Build in Public concretely means for us

We regularly write down what we're building. What works, what doesn't, where we miscalculated, where we learned.

Concretely:

On this blog, roughly every two weeks. Longer articles that go into depth.
In the welcome emails to Founding Members, with an honest status of what already works and what doesn't.
In updates on LinkedIn, shorter, with numbers where possible.
In the feedback area in the app, visible to Founding Members.

What we don't make public:

Personal conflicts between us (rare, but they happen)
Concrete revenue figures from the moment they become strategic
Our users' data
Contracts with service providers and lawyers

Why we do it

Four reasons.

First, because it forces us to be honest. When we write down twice a month what we did, it's hard to fool ourselves. A bad week is easy to hide when no one asks. When you know an update is due on Friday, the question "what did we actually achieve this week" becomes routine.

Second, because it attracts a certain kind of person. People who want to know how something really comes about. Not the ones who read polished pitches, but the ones who want to look behind the stage. Those exact people make the best Founding Members. They tolerate that something doesn't work yet, because they've built something themselves before.

Third, because it frees us from the writer's-block phenomenon. Anyone waiting for the "perfect" moment to publish waits forever. Build in Public means: we write about the unfinished version. The finished version may never exist.

Fourth, because it's more honest. Most apps act as if they were born out of nowhere, finished and complete. That's not true. Every app, every product, every book is a process. We show the process, because that's closer to the truth than the polished end result.

What we're not trying to achieve with it

In recent years, Build in Public has become a marketing strategy. "1,000 days in public, now 10K MRR" is something you often see on LinkedIn and X. We don't want that.

We don't want to:

Celebrate vanity metrics ("We now have 800 newsletter subscribers!")
Stage crises so we get more engagement
Turn Build in Public into a content funnel whose only purpose is to generate more sign-ups

What we want is simpler: we want the people who follow us to get a realistic picture of how bakeqee comes about. If that makes them Founding Members, great. If it makes them decide that bakeqee isn't for them, that's okay too.

What we don't expect

We don't expect this Build-in-Public approach to make us go viral. Most of our updates will be read by fewer than 100 people. That's okay. 100 people who really understand what we do are worth more than 10,000 who drop by once and forget.

We also don't expect something exciting to happen every week. Some weeks are boring. We'll have fiddled with a config file, or gotten annoyed at some API documentation, or spent half a day on the question of whether a button should be red or amber. We'll write that up just as it is. Boring is a story too.