Build in Public: why we show how our systems work

We write publicly about how much time our automations save, what they cost and where they have broken. Some peers think that is a mistake.

Their argument: you are giving away your business model. After two years I can say it works the other way round.

Build in public means making the work visible while it happens. Numbers, architecture, setbacks. Here I write down why we do it, where our line runs and what it actually costs.

Why openness works particularly well in the automation business

Automation is a trust business with a structural problem: the customer cannot judge the result in advance.

Someone who buys a website ends up looking at a website. Someone who buys an automation gets something that runs in the background and ideally never gets noticed. It is judged against a promise. Which is exactly why this industry is full of promises.

Openness replaces the promise with evidence. When we write that order processing at mate dropped from 4 hours a day to 15 minutes, the description of how it was built sits right next to it. Anyone who wants to rebuild it can. Anyone who would rather buy it now knows we understand what we are talking about.

The second effect is pre-qualification. Someone who has worked through an article about costs does not open the conversation asking whether this takes three weeks. They come with a specific question. Our calls are shorter because of it, and our close rate is higher.

What we show

Four things, consistently.

Numbers from our own operation. Around 65 percent of our support requests run automatically. Roughly 40 percent of all requests are where is my parcel. Across all processes we save 33 to 46 hours per week. At MUSTAX reporting went from 2 days to 2 hours. These numbers are identical everywhere, because we maintain them in one place.

The architecture, beyond the result. Which systems talk to each other, where an approval sits, where it breaks. Our articles on human in the loop and the customer service guide are built so that someone with a bit of technical background can rebuild it.

The mistakes. At nano, orders regularly went out wrong before we automated. One of our automations nearly paid out a refund for a return that never arrived at the warehouse. A model once promised a return window we never had, and we honoured it.

What we advise against. We have a whole article about when automation makes no sense, and one about when an agency is the wrong choice. On paper both cost us deals. They bring us better ones.

Where the line runs

Openness without a line is negligence. Four things never leave the building.

• Customer data in any form. No names, no shops, no screenshots with recognisable orders. When we write about client projects, it is a furniture brand or a client in food retail. Even then we check whether the combination of industry and number makes someone identifiable.
• Anything that grants access. API keys, endpoints, internal URLs, account structures. That sounds obvious and in practice it leaks through screenshots. We redact consistently.
• Prices in detail. We name orders of magnitude and payback periods. We do not publish a calculation per project. A price without the scope behind it creates false expectations on all sides.
• Other people's numbers. A client's time savings belong to the client. We only publish them with explicit approval, and mostly we do not even ask.

On top of that comes a less obvious rule: we show nothing that is not running stably yet. A build we discard two weeks later is dangerous as a template for other people. We write about things that have been in operation with us for months.

What it costs

The uncomfortable part of this text is the price, and build-in-public posts almost never mention it.

Time. A usable article about a real build costs us half a day to a full day. That is time not going into client projects. In a two-person operation you feel it.

Exposure. Publish numbers and you get measured against them. If our automation rate drops to 55 percent in a given month, that stands against our own published figure. It disciplines you and it makes you restless.

Copying. Yes, competitors read along. Some rebuild our ideas. That is the objection we hear most often and the one that hurts least. The build is the easy part. Knowing which process to touch first at which client appears in no article.

Commitment. Hold a public opinion and it gets harder to move away from it. We wrote early on that we self-host n8n. When we thought internally about switching, the published position was an extra source of resistance. In the end we reviewed it and kept it, and the reflex was noticeable.

Who this is wrong for

I do not recommend build in public across the board. Four cases where I would advise against it.

When your edge is in the method. There are business models whose only advantage is a non-obvious way of doing things. Then silence is the right strategy. Our advantage is experience and speed, and neither can be copied off a page.

When the numbers do not carry yet. Openness about a business that is currently not working quickly turns into a performance of struggling. That creates sympathy and no customers.

When you cannot hold a cadence. Three articles and then six months of silence is worse than nothing. Visible openness creates an expectation you have to serve.

When you work in a regulated industry. In medicine, finance or anywhere statements need approval, half a day of writing turns into weeks of sign-off.

And one objection that applies to us too: build in public tempts you to build what is showable instead of what is useful. If you notice you are touching a process because it tells well, stop. We check that with a simple rule. It runs in operation for three months, then we write about it.

What it has actually got us

So this does not stay at the level of principles, three effects we could measure.

The first is call length. Two years ago half of a first call went into fundamentals. What a workflow is, why an approval step makes sense, why we are not done in three days. Today most people have read two articles beforehand. The conversation starts at the question of which process comes first.

The second is the type of enquiry. Someone who has read a piece about when automation makes no sense reaches out less often with a project that makes no sense. We say no less often, because less unsuitable work arrives.

The third concerns us. Writing something up so a stranger can rebuild it exposes gaps. While working on the text about our approval steps we noticed we had no clear rule for two cases at all. We settled them while writing. That was the return on the day.

How we do it in practice

In case you want to try it, our approach in four points.

• One source for numbers. All metrics live in one place. When one changes, it changes everywhere. Contradictory numbers in two articles cost more trust than both together build.
• Write out of operations. The trigger for an article is always something that just happened. An automation that got finished. A mistake we made.
• Anonymise by default. Never as a case-by-case call. Weigh it up fresh in every text and you will eventually make the mistake.
• Publish mistakes together with the fix. An error report without the handling is a warning about yourself. With the fix it is evidence of competence.

How we handle employees and AI systems working on such content together is in using AI in your team.

Conclusion

We show our systems because our product is invisible. The evidence has to come from somewhere else.

The price is time, exposure and being bound to your own statements. The return is conversations with people who already understand what they are buying. For us the maths works. Whether it works for you depends on where your edge sits.

If you want to know what such an automation would look like at your company: talk to us at Flowhouse. We will show you the build, even if you end up building it yourself.