Build in Public: An Operator’s Distribution and Trust Engine

Pillar: Brand  |  Reading time: ~10 min

Last updated: June 2026

What Does “Build in Public” Mean for an Operator (And Why It Compounds Distribution)?

For an operator, building in public means publishing the real operating numbers and decisions behind a running business — the delegated labor you replaced, the self-hosted stack on your own VPS, the margin it freed — so that transparency itself becomes a distribution and trust engine. It is not a beginner’s “share your journey” pep talk. When you publish operating specifics that are hard to fake — your AI-agent count, your inference cost, your tool stack — you compound reach and inbound from the exact people who already pay for delegated labor and software and want to run leaner. Thinkific’s 2024 Online Learning Trends Report (2,500+ U.S. adults) found 62% of respondents prefer creators who produce educational content over entertainment — and operational specifics are the most educational content an operator can publish.

As of 2026, Goldman Sachs Research (2024) valued the creator economy near $250 billion, projecting $480 billion by 2027 — and inside that expanding market, the operators publishing verifiable specifics are capturing disproportionate trust while everyone else broadcasts polish.

Here is what happened the first time I published the numbers I was genuinely afraid to share. I wrote a post detailing the full cost structure of running my operation — the exact VPS bill, the inference costs, the tool stack, the number of automated agents. Everything. I hit publish and immediately felt that specific dread of having gone too far. Within a week, that post had the highest engagement of anything I’d written. People weren’t copying it. They were writing back to say it was the first time they’d read something from someone running a real operation who wasn’t selling a course about it.

That is when I understood what building in public actually is for an operator — and what it isn’t.

Build-in-Public as Marketing vs. as a Distribution Engine

The difference between performative transparency and the operator version is the direction information flows, and what it produces. The table below is the distinction I wish someone had drawn for me earlier.

Dimension	Build-in-public as marketing	Build-in-public as a distribution engine
What gets shared	Polished wins, revenue only when it’s impressive	Operating math: labor replaced, stack, cost at each layer
Direction of flow	Broadcast: creator → audience	Feedback loop: a starting point for dialogue
Who it attracts	People who want the outcome, not the work	Operators doing the work who want a real model
Defensibility	Easy to fake; depreciates with the result	Hard to fake; compounds as evergreen inbound
Business payoff	Vanity reach, low-intent followers	Inbound collaborations, higher-intent customers

As the comparison above shows, most “build in public” content sits in the left column — personal brand marketing wearing transparency as a costume. The creator shares a revenue number, but only when it’s impressive. They document a failure, but only after they’ve already recovered and can frame it as a growth lesson. The operator version lives in the right column: it publishes the working math — the labor an automation stack takes off your plate, the VPS bill, the inference cost — because someone else is trying to decide whether the model is viable at their scale.

Why Most “Build in Public” Content Is Still Marketing in Disguise

The giveaway is that the information only flows one way. Marketing flows from creator to audience: “Here’s what I know, here’s how I succeeded, here’s what you can buy to get where I am.” Even packaged as transparency, the underlying dynamic is broadcast — polished content designed to maintain an image.

The operator version creates a feedback loop. When I document that I run 20 AI agents across 8 sites on ~$47/month in metered AI (most inference runs locally on the RTX 5090 at $0 marginal), I’m not announcing a trophy. I’m inviting a conversation about whether that is sustainable, what I’m missing, what others running VA-heavy or e-commerce operations are doing differently. The post is a starting point for dialogue, not a finished product — and that loop is exactly what turns a one-time read into recurring inbound.

What I Actually Share — and What I Don’t

I’ll give the full breakdown later, but the short answer: I share operating specifics, strategic pivots, costs, tool stacks, results including the failures, and the reasoning behind decisions. I keep private the personal financial details that aren’t relevant to the case study, third-party information shared in confidence, and anything where transparency would harm someone else without helping the reader.

The test I run: Would this have been genuinely useful to me, as an operator, two years ago? If yes, it gets published.

---

Why I Started Publishing My Operating Numbers

The Sushi Chef Who Went Online (And Why the Kitchen Logic Still Holds)

Before I ran a content and commerce operation, I was a sushi chef. And before you romanticize that: professional kitchens do not typically reward sharing knowledge. There’s a culture of withholding. Recipes are guarded, techniques are kept close, on the logic that your knowledge is your competitive edge.

But here is what I watched over years in kitchens: the chefs who shared — who taught their team, who explained the reasoning behind every technique — consistently ran better kitchens. Not just happier ones. Better-performing ones. When your team understands the why, they can adapt when something breaks. When you hoard knowledge, you become the bottleneck. When you share it, the whole operation levels up. That is the same reason an operator documents the stack instead of guarding it — the documented system is what scales past you.

The internet gave me a bigger kitchen. The logic didn’t change.

What I Was Afraid to Share — and Why I Published It Anyway

The fear that stopped me earliest wasn’t “what if competitors copy me.” That concern is real but overblown, and I’ll address it later. The deeper fear was more personal: what if people think this operation isn’t impressive enough?

There is real exposure in publishing numbers that don’t read like a success story yet. When the YouTube channel had a fraction of the 37K subscribers it has now and the shop was profitable but not life-changing, sharing those specifics felt like admitting I hadn’t arrived. The income-report culture had convinced me you only publish numbers when they’re worth bragging about.

What I eventually understood is that the audience worth having wasn’t interested in the success version. They wanted the working version — someone several years in, who has figured out some things, is still figuring out others, and will say so. Those readers are the operators who follow a model because they want to build something real, not chase a six-figure month in 90 days.

The First Time Publishing the Real Math Paid Off

That post about my infrastructure costs — the one I almost didn’t publish — became the single most-shared piece I’d written up to that point. Not because the numbers were impressive. Because they were honest. I published what I was actually spending (~$47/month in metered AI, with most inference running locally on the RTX 5090 at $0 marginal, adding up to roughly $100/month all-in for the full software stack) and what it bought, including the parts still messy. (It ran about $260/month during the heavy build phase, when I was on the $200/month Claude Max plan; once you’re not actively building, the plan steps down and it’s roughly $100/month to keep running.) The response was: finally, someone showing the actual math.

That feedback loop changed how I approach everything here. The goal isn’t to impress. It is to be genuinely useful to an operator working through the same problems one stage behind me — and that usefulness is what brings them back and brings their peers with them.

---

The Business Payoff of Publishing Real Operating Data

Trust Compounds Faster Than Any Paid Channel

I’ve run most of the standard marketing playbooks — SEO listicles, social calendars, lead magnets tuned to maximize signups. They all work to a degree. But nothing compounds trust the way consistent, specific operating transparency does, and trust is the cheapest distribution an operator can build.

Here is why it works: trust is earned by repeatedly being right about what you say you are. When I publish that I run 20 AI agents and then show the actual architecture, the claim and the evidence sit in the same place. When I say I’m pivoting the tea line and explain the reasoning while it’s happening — not after it succeeds — readers see a decision-making process, not a highlight reel. That is far harder to fake, which is precisely why it builds more trust. According to psychologist Robert Cialdini’s research on influence, reciprocity — the felt obligation to return value when someone gives first — is one of the most powerful persuasion principles (Cialdini, 1984). Transparency creates reciprocity: when you give genuine operating information first, operators reciprocate with trust and attention.

Transparency doesn’t just build trust. It attracts the specific kind of trust you want — from operators who value operational honesty over inspirational positioning.

The Audience You Attract With Operating Data vs. Hype

Hype attracts people who want the outcome but not the work. Operating transparency attracts people who are already doing the work and want a realistic model. These are fundamentally different audiences, and they behave differently on your books.

The transparency audience asks sharper questions. They push back on things that don’t add up and point out inconsistencies constructively. They become the best community members, the most valuable subscribers, the most loyal customers — because they arrived with accurate expectations. They weren’t sold a fantasy. They signed up for a case study they can act on.

How Publishing My Agent Stack Turned Into Real Business Relationships

I’ve had more genuinely useful professional conversations starting from “I read your post on how you set up your n8n workflows” than from any amount of networking or LinkedIn activity. People who read operating details are people who are trying to operate. Those are the conversations worth having — and they arrive as inbound, not outreach.

Two collaborations I’m currently in came from people who found this site, read the specifics of how I built the operation, and reached out because they were building something adjacent. Not because the numbers were impressive — but because the detail showed I actually knew what I was talking about and wasn’t hiding the working parts. That is distribution you can’t buy. If you want the full system behind it, I lay it out in The Solopreneur Blueprint.

Building Authority Without Credentials

I don’t have an MBA, a decade of agency experience, or a marketing certification. What I have is an 8-site operation I’ve been running, documenting, and iterating on for years, and I’ve published most of that documentation in the open.

In a world where anyone can claim expertise, operational transparency is its own credential. It is harder to fake than a title. When I say “here is the exact set of tools I use, here is what each costs, here is the workflow that connects them, here is the result” — that is a claim you can interrogate and verify. Credentials say you’ve been trained. Operating transparency shows you’ve been running something real.

---

What I Actually Publish (The Full Operator Playbook)

The 8-Site Network, 20 Agents, ~$100/mo — Why I Publish These Numbers

Let me be specific, because specificity over abstraction is the whole point.

The operation currently runs 8 sites across multiple niches: alldayieat.com (Japanese food and cooking), shop.alldayieat.com (tea e-commerce), community.alldayieat.com (the partner hub), gardengrowthguru.com, sonycameracentral.com, wordsareyourwand.com, airfrycentral.com, and digitalgardenprofit.com (which you’re reading right now). All 8 run on a single Hetzner VPS at $21/month — not a managed host like Bluehost or SiteGround. The metered AI costs — primarily for the 20 agents running content, SEO, advertising analysis, and operational workflows — run ~$47/month (most inference runs locally on the RTX 5090 at $0 marginal cost), with the full software stack coming to roughly $100/month. The YouTube channel has 37K subscribers across two channels. Pinterest has 4.6K followers.

I publish these numbers because they’re live data points in an ongoing case study, not a trophy frozen in time. The ~$100/month software budget is meaningful to an operator deciding whether an AI-agent stack is viable at their scale instead of another VA hire or SaaS renewal. The 8-site structure speaks to anyone weighing portfolio breadth versus focus. The agent count matters to anyone designing their own automation. These aren’t boasts — they’re the context that makes the case study usable.

The System I Share: Content, SEO, AI Agents, Email, Products

Across this site and the broader operation, I’ve documented:

• The full content pipeline from keyword research to publication, including the AI tools at each stage and which delegated tasks they replaced
• The SEO architecture — how I structure pillar pages, cluster articles, and internal linking across all 8 sites
• The automation stack — 20 agents, their functions, and the n8n workflows that connect them
• The product strategy for the tea business, including the live pivot in the tea line and the reasoning behind it
• The email architecture, including sequence design and the platforms behind it. According to Kit’s 2024 State of the Creator Economy survey, 27% of creators ranked email as their best audience engagement channel — higher than Instagram (15%) or any other single platform (Kit, 2024).
• The cost structure at each layer: infrastructure, content production, advertising, fulfillment

This isn’t a curated highlight reel. It includes decisions that didn’t work, experiments that failed, and pivots made under uncertainty. For the underlying toolset, I keep a running list of what I actually use in my operator tool stack, and the agent layer specifically is broken down in the solopreneur AI stack.

“Who Maintains It When It Breaks?” — The Honest Answer

The first objection a serious operator raises isn’t cost — it’s maintenance. If agents run your content, SEO, and ops, who fixes it when one silently stops working overnight? I publish that part too, because pretending a self-hosted stack is zero-maintenance would be exactly the kind of polished dishonesty this whole post argues against.

The honest answer for any self-hosted operator is a monitoring layer: something that watches the jobs and flags a failure before it cascades. It is not magic and it is not free of effort — there is real steady-state work to keep a system like this running. But publishing the maintenance reality, not just the savings, is what makes other operators trust the savings. That is the whole discipline of building in public: you share the part that takes ongoing work, not only the part that looks effortless.

What I Keep Private (And Why That’s Still Building in Public)

Building in public doesn’t mean publishing everything. Here is what I keep private and why:

• Personal financial details beyond what the case study needs. The ~$47/month in metered AI is relevant. My personal savings rate is not.
• Third-party information shared in confidence — vendor terms, collaborator details, anything where publishing would breach someone’s trust.
• Anything that would harm someone without benefiting the reader. This is the filter that matters most. If information would hurt someone and the only person it helps is me — by making me look more transparent — it doesn’t get published.

The underlying principle: transparency serves the reader, not the brand. Those aren’t always the same thing, and it’s worth being honest about the difference.

---

The Digital Garden as a Philosophy, Not Just a Metaphor

The “digital garden” framing that grounds this site isn’t only a branding decision. It is a philosophy that directly informs how I think about building in public — and about owning the land your distribution grows on instead of renting it from a platform.

Growing in Public: Systems Develop Over Time

A real garden doesn’t hide its work-in-progress. You see the seeds planted, the seedlings come up imperfect, the pruning. The harvest isn’t a surprise — it’s the visible result of a process you’ve watched all along.

Most publishing works the opposite way. You do the work privately, polish it until finished, then publish the finished product. The reader gets the harvest but never saw the garden. That makes the output look more authoritative, but it severs the relationship that turns readers into a durable audience.

When I publish a “seed” — a rough idea, an open question, an experiment in progress — I’m inviting operators into the garden while the work is happening. That’s different from publishing a polished framework. Both have value. Only one builds the kind of relationship where readers feel invested in the outcome and bring you their own.

Why Some Posts Are “Seeds” and Some Are “Harvests”

The three stages I work with — Plant, Cultivate, Harvest — map directly onto the kinds of content I publish:

• Seeds: Rough ideas, open questions, early experiments. Published as-is, clearly labeled as works in progress. The value is in sharing the thinking before it’s complete — inviting input, documenting the starting point.
• Cultivating: Work in progress. Documented experiments with preliminary results. “Here’s what I’m trying and why; here’s what I’ve learned so far.” Updated as the experiment evolves.
• Harvests: Completed guides, case studies, definitive frameworks. The polished outputs most publishing looks like — richer when readers watched them develop.

Not everything starts as a seed. Some topics are well enough understood to go straight to harvest. But the seed-to-harvest arc is what creates the “I’ve been following this” feeling that turns a casual reader into a committed one.

The Long Game of Open Knowledge-Sharing

Pieter Levels has been building products in public for years — Nomad List, Remote OK — and the body of published work he’s accumulated is itself a compounding asset. Arvid Kahl documented the entire lifecycle of building and selling a SaaS product publicly, and that documentation became the basis for a book, a course, a community, and an authority that outlasted the original product.

The long game works because trust doesn’t depreciate the way reach does. A post I published years ago documenting an early version of my stack still generates inbound from people who find it through search. The transparency built into it — the specific numbers, the honest failure points, the “here’s what I was figuring out at the time” framing — makes it evergreen in a way that polished content rarely is.

---

How to Start Building in Public (Without Oversharing)

Start With the Process, Not the Results

The most common mistake I see from operators who want to build in public: they wait until they have results worth sharing. That’s the wrong starting point. Results are backward-looking and intermittent. Process is continuous and immediately useful.

Document the decision you made this week, not the outcome you achieved last month. Share the workflow you’re testing, not the one you’ve already proven. Write about the problem you’re solving now, not the one you already solved. The value to your reader is in watching someone navigate uncertainty in real time — not in consuming a packaged lesson from the other side of it.

The One-Rule Framework: Share What You Wish You’d Known

If you want a single filter for what to publish, this is the one I use: share what you wish you’d known.

If you spent three hours figuring out something that should have taken twenty minutes — write it down. Your reader is someone at the stage you were at three hours ago, about to lose the same afternoon. If you made a decision that turned out to be a mistake and can articulate exactly what you’d do differently — that’s worth more than any success story. If you found a tool, a workflow, or a framing that changed how you think about a problem — document the before and after.

This framework also solves the “what if I’m not an expert?” problem. You don’t need to be the foremost authority on a topic to publish something useful. You need to be one step ahead of your reader. That’s it.

Formats That Work for Build-in-Public Operators

Not every format works equally well for this style. Here is what I’ve found most effective:

• The monthly/quarterly update: Metrics, pivots, decisions made, what changed. Not a highlights reel — a full accounting. This is the backbone of any build-in-public practice.
• The decision post: “I’m weighing X vs. Y. Here’s the reasoning. Here’s what I’m going to do.” Readers engage because they’re often facing the same decision.
• The process breakdown: “Here’s exactly how I run X.” Not a tutorial — a documentary. A tutorial teaches the ideal way; a process breakdown shows the way you actually do it.
• The failure post: The hardest to write and the most valuable. Be specific about what you tried, what happened, and what you’d do differently. Don’t rescue the story with a silver lining unless there genuinely was one.
• The newsletter: The most natural build-in-public medium. Regular cadence, inbox delivery, direct relationship. My newsletter is essentially a running build-in-public artifact — each issue a live update on what’s working, what’s changing, what’s being built.

You don’t need all of these. Pick the format that fits how you actually think. If you’re analytical, the metrics update is natural. If you’re narrative-driven, the decision post comes more easily. Start with one and do it consistently before adding others.

---

---

FAQ

What does “build in public” mean for an operator?

For an operator, building in public means documenting the real work, decisions, and operating numbers behind a running business as you build — not just sharing polished highlights after the fact. In practice that means publishing your content system, the labor an AI-agent stack replaced, the cost at each layer, and what worked versus what didn’t. The goal is to create genuine value for an audience of fellow operators by letting them learn alongside you. It’s the opposite of the “launch and announce” model: instead of hiding the work until it’s finished, you share the work as it happens — and that openness becomes a distribution channel.

Why would you publish your entire operating playbook publicly?

Because transparency builds faster trust than any paid channel I’ve found, and for an operator trust is the cheapest distribution there is. When I publish specific numbers — my server cost, agent count, tool stack — I signal that I have nothing to hide, which attracts the exact audience this site is built for: operators who want real information, not aspirational hype. And the fear that competitors will copy you is almost always overblown. Execution is the moat, not the plan. Anyone who can read everything I’ve published about the operation and actually replicate it was going to figure it out anyway. The people who benefit most are operators trying to learn — and they’re not your competitors, they’re your inbound.

How do you decide what to share and what to keep private when building in public?

My rule: share processes, frameworks, and operating results that would help an operator one stage behind me. Keep private the personal finances beyond what the case study needs, third-party details shared in confidence, and anything where transparency would harm someone else. The question I ask is: “Would I have wanted to know this two years ago?” If yes, I publish it. If the only person who benefits from publishing something is me — because it makes me look more transparent, successful, or relatable — that’s not a good enough reason. Transparency is in service of the reader, not the brand.

What kind of audience does transparent building attract?

Operating transparency attracts builders and operators doing real work, not people chasing aspirational results. These audiences ask sharper questions, engage more constructively with failures, and stay loyal longer because they signed up for a case study, not a highlight reel. They value specificity and honesty over polish, which means your community tends to be higher quality even when it’s smaller — and higher-intent when it comes to buying what you build.

Does build in public actually help your business grow?

Yes, but not in linear ways. Trust compounds slowly, then faster than any traditional marketing tactic I’ve used. The real benefit is audience quality — you attract collaborators, customers, and community members who already understand your model and your values. You spend less time explaining and selling because the transparency did that work upfront, which is why publishing real operating data behaves like a distribution engine rather than a marketing cost.

---

I’ve been running this operation in public long enough to say it with confidence: the exposure of genuine transparency pays off in ways polished personal branding never does. Not overnight. Not in a straight line. But compounding, the way most things that actually work tend to compound.

What are you building? Reply and let me know. I read every response.

---

Related reading: The Solopreneur Blueprint: How One Person Runs an 8-Site Operation  |  The Solopreneur AI Stack  |  My Operator Tool Stack