Why We Build in Public: What We Share and What We Keep Private

We build in public because writing down how the studio works, in the open, makes us think more clearly, keeps us honest about what is and is not working, and lets the people who might use our products see how they are made. Building in public does not mean publishing every number or every customer conversation. It means sharing the decisions, the reasoning and the lessons, so anyone reading can follow how a small team runs several software products at once.

This post explains what building in public means for Unavoidable Studio, what we share and what we keep private, and what we think it gives us in return.

What does building in public actually mean?

Building in public means explaining your work while you are doing it, not only once it is finished and polished. For us that is mostly this blog: notes on how we choose what to build next, how we run several products with a small team and how we decide what infrastructure to share across them.

Different people mean different things by the phrase. Some founders publish their revenue every month. Others livestream themselves writing code. We sit at the quieter end. We write about how we make decisions and what we have learned, because that is the part we think is most useful to other people and most honest about us.

Why do we do it?

We do it for three reasons: it improves our thinking, it keeps us accountable, and it builds trust before anyone signs up for anything.

Writing forces clearer thinking

A decision that feels obvious in your head often turns out to be fuzzy when you try to explain it to a stranger. Explaining a decision, such as how we decide what to share across products, means spelling out rules that might otherwise be applied by instinct. Once rules are written down, they are easier to follow, easier to challenge and easier to hand to someone else.

Saying it in public keeps us honest

It is easy to tell yourself a product is going well. It is harder to write that in public if it is not true. Knowing we will explain our choices openly nudges us towards decisions we are happy to defend, and away from the kind we would rather nobody looked at too closely.

Trust comes before the sale

People are rightly careful about which software they trust with their customers, their calls or their wedding guest list. Showing how we think about things like keeping customer data separate, or why we prefer customers to pay usage costs directly rather than through us, gives them something real to judge us on. It is a better signal than a list of features.

What do we share, and what do we keep private?

We share the how and the why, and we keep private anything that belongs to someone else or could hurt a customer if it were public.

Things we are happy to write about:

• how we choose between product ideas and what we say no to;
• how the team divides its time across several live products;
• what we build once and share, and what we keep separate;
• mistakes in our own process and what we changed afterwards;
• how we test an idea before committing months of work to it.

Things we will not publish:

• anything about an individual customer, their data or their business;
• security details that would make any product easier to attack;
• commercial terms with suppliers or partners;
• other people's work or words without their agreement.

The line is simple. If sharing something would only cost us a little embarrassment, it is usually worth sharing. If it would cost someone else their privacy or security, it stays private.

Is there a downside to building in public?

Yes. The most obvious is that competitors can read it too. We think that matters less than it sounds. The reasoning behind a decision is only useful if you also have the products, customers and context it was made for. Copying a blog post does not copy a business.

A more real cost is time. Every hour spent writing is an hour not spent building. We keep posts short and practical, and write about things we have already had to think through for our own work, so the writing mostly sharpens work we were doing anyway.

The last risk is the temptation to perform: to make everything sound more decisive or successful than it was. We try to resist that by writing plainly, admitting when we changed our minds and keeping the focus on what a reader can take away.

How does it shape the products themselves?

Writing in public makes us explain each product in plain language, and that clarity feeds back into the products. If we cannot describe who Unavoidable CRM is for in a sentence, or why Aisle Reply does what it does for couples, that is a sign the product itself needs focus, not just the copy. The same goes for Unavoidably Secure, where clear explanations are a large part of what customers want.

It also invites feedback we would not otherwise get. When someone reads a post and tells us we have missed something, that is free advice from a person who cared enough to write.

What would we suggest to another small team?

Start small and start with decisions. You do not need to share numbers or record videos. Write a short note each time you make a choice that you had to think hard about, and explain why. Keep customers and their data out of it. Admit when you get something wrong. After a few months you will have a record of how your business really works, which is useful whether or not anyone else reads it.

You can see the products behind these notes on our portfolio page, read about the model in what a venture studio actually does, or get in touch through our contact page if you want to compare notes.

← Back to the blog