Learning in Public When You're the Least Technical Person

Photo by Clay Banks on Unsplash

Learning in public as a non-technical founder means writing down what you just figured out, while you still remember what confused you — and publishing it before you feel qualified. That last part is the whole difficulty. You are not the expert in the room. You will get corrected. The trade you're making is a small amount of ongoing embarrassment for a compounding asset: a public record of problems you solved, which turns into search traffic, credibility, and people who show up to help you. I've been doing it for six months while building Coding Capybaras, and the embarrassment was real. So was the payoff.

TL;DR

• Learning in public works because you're a beginner, not despite it — you still remember what was confusing, which is exactly what makes writing useful.
• Write about what you struggled with, not what you know. Julia Evans' framing: the post isn't about the struggle, it's about what got you out of it.
• Being publicly wrong is cheap. Being privately stuck for three weeks is expensive.
• Separate what you publish from what you overshare. Technical confusion is safe to post. Revenue panic, customer specifics, and half-processed feelings usually aren't.
• The compounding is slow and mostly invisible for the first few months. Ship anyway.

Why learning in public is harder when you can't code

There's a version of "build in public" that indie hackers have been doing for a decade: post the MRR chart, post the launch, post the churn number. That version is uncomfortable but socially legible. Everyone understands a revenue graph.

The non-technical version is different, and worse. When I publish something about Stripe webhook signature verification, I'm publishing in a domain where thousands of readers know more than I do. The revenue graph is just a fact. A technical explanation is a claim, and claims can be wrong in front of people who can tell.

That asymmetry is the actual fear. It's not "will anyone read this." It's "will a real engineer read this and know immediately that I don't belong here." If you've felt that, you're not being irrational — the risk is real, it's just much smaller than it feels. It's the same reflex behind non-technical founder syndrome: the assumption that you need permission you were never actually going to be issued.

Here's the thing that reframed it for me. Shawn Wang's "Learn In Public" — the essay that's been translated into more than a dozen languages and read by a very large number of developers — puts the fear directly in the text: "Try your best to be right, but don't worry when you're wrong. Repeatedly. If you feel uncomfortable, or like an impostor, good. You're pushing yourself." And then the part that actually helped me: "Wear your noobyness on your sleeve."

Not "pretend to be an expert." Not "wait until you are one." Say plainly what level you're at, then write the thing anyway. Being clearly labeled a beginner removes almost all the downside, because nobody is disappointed to find out you're a beginner when the first sentence said so.

The other thing worth naming: 80% of developers, by swyx's estimate, are "dark" — they don't write or speak or participate in public technical discourse at all. The bar for being visible is not "be the best." The bar is "show up at all." That's a much lower bar than the one in your head, and it's the bar that non-technical founders keep failing to clear because we assume the standard is expertise.

It isn't. The standard is usefulness.

What "learning in public" actually means for a founder

Let me be specific, because "share your journey" is the kind of advice that sounds actionable and isn't.

Learning in public is a loop with four steps. You get stuck. You get unstuck. You write down specifically what got you unstuck. You publish it somewhere with a URL.

flowchart LR
  A[Hit a problem<br/>you can't solve] --> B[Flail, search,<br/>ask the AI, ask a human]
  B --> C[Get unstuck —<br/>note the exact thing that worked]
  C --> D[Write it down while<br/>the confusion is fresh]
  D --> E[Publish with a URL]
  E --> F[Corrections + questions<br/>come back to you]
  F --> A

The step people skip is the third one. You solve the problem, feel relief, and move on — and within about a week you can no longer reconstruct what was hard about it. Julia Evans wrote the definitive piece on this, and her warning is the one I keep coming back to: "It's very easy to misidentify what you learned if you don't remember what it was like to struggle with the topic." She uses git as the example — she used to find it confusing, she doesn't anymore, and she genuinely can't reconstruct what got her from one state to the other.

That's a permanent loss. The window where you're most useful to other beginners is the window where you're still slightly confused, and that window closes fast.

Evans also makes a distinction that fixed my drafts. The post isn't about the struggle. "I find Rust hard" helps nobody. The post is about the specific thing that resolved the struggle — for her, that meant writing about what a reference in Rust actually is, because references were the specific blocker.

Applied to me: "Stripe webhooks are confusing" is a tweet, and a bad one. "Stripe signs the raw request body, so if your framework parses the body before your handler sees it, signature verification fails with no useful error — here's the file path where I fixed it" is a post. Same experience, wildly different value.

The second thing that changed my output: stop writing for an audience. swyx's rule is to "talk to yourself from 3 months ago," and to make the thing you wish you'd found. That's a much easier writing target than "engineers on Hacker News," and it happens to produce better posts, because the person you were three months ago had specific, real confusions that generic content doesn't address.

What to publish and what to keep to yourself

Learning in public is not the same as posting everything. Conflating those two is how people get burned and then quit.

I keep a rough split. It looks like this:

| Category | Publish? | Why | | --- | --- | --- | | A technical thing that confused you and now doesn't | Yes, always | Neutral, useful, zero social risk. This is the core of the practice. | | A tool or service you evaluated and rejected | Yes, with reasons | Genuinely helpful, and honest tradeoffs build more trust than endorsements. | | A mistake that cost you money or time | Usually | Post the lesson, not the self-flagellation. Nobody needs your shame. | | Aggregate business numbers (MRR, signups, churn) | Your call | Real audience-builder, but it becomes a treadmill. Opt in deliberately. | | Anything involving a specific customer | No | Not your story to tell, even anonymized, even flatteringly. | | A conflict with a person | Almost never | You'll process it in public, badly, and it stays indexed forever. | | Feelings you haven't finished having | No | Wait. Publish the conclusion, not the spiral. |

Evans lands in roughly the same place from the other direction. Her tactics for making public vulnerability less scary: stay mostly on technical problems, be vague when it's a people problem, spend time processing before writing, and simply don't talk about everything. That last one is permission a lot of founders need. Learning in public doesn't obligate you to full transparency. It obligates you to be honest about the things you do choose to publish.

The failure mode I've watched people hit isn't oversharing technical ignorance. It's oversharing emotional state in real time — the 2am post about almost quitting, written at 2am. There's a good essay in almost quitting — I know, because I eventually wrote mine. It gets written three weeks later, once you know how the story ends.

One more line from Evans that's worth internalizing before you publish anything: sometimes you struggled with something and you still don't have a lesson, and that's fine. Not every hard experience converts into a post. Forcing it produces content that helps nobody and reads as filler.

What it actually bought me

Six months in, here's the honest accounting.

The corrections were the point. I've had people tell me I was wrong about things — about Supabase Row Level Security defaults, about how I'd described a build step. Each correction was mildly embarrassing and took about ninety seconds to absorb. Compare that to the alternative: staying wrong, shipping the wrong thing, and finding out from a customer. Being publicly wrong is one of the cheapest ways to learn that exists. The interest rate on being privately wrong is brutal.

The writing made me understand my own product. This one surprised me. Explaining the three-region architecture (/platform, /website, /product) to a reader forced me to justify it, and in a couple of places I couldn't — so I changed the architecture. Evans describes the same mechanism: publishing "really forces me to think about whether the lessons I think I learned actually make sense." Writing is a debugger for your own reasoning.

People started showing up. Not many, and not fast. But a handful of engineers now reply to things I post, and the replies are substantive. swyx describes the mechanism precisely: senior people help visible learners because "by teaching you, they teach many." You amplify them. That's not charity, it's a trade, and you have something to trade — a beginner's mind, and a public surface.

The archive compounds. This is the part that's invisible for months and then isn't. Patrick McKenzie's "Don't End The Week With Nothing" is the clearest articulation I've found of why. His point is about capital formation — human, social, and reputational capital that you own rather than rent. And critically, he notes that his most career-valuable writing was from 2006 to 2008, when he was "struggling through not understanding anything" and had fewer readers than his brother's blog about superhero novels.

It was still valuable. Not because of the audience at the time, but because years later he could point at it. "Prefer to work on things you can show. Prefer to work where people can see you. Prefer to work on things you can own."

What learning in public did not buy me: an audience, quickly. Traffic in month one was effectively zero. If your reason for doing this is distribution, you will quit before the compounding starts. Do it because the writing makes you better at your job, and treat the audience as the byproduct.

How to start this week if you've never done it

Four concrete moves, in order.

1. Keep a stuck log. A single text file. Every time you get blocked for more than twenty minutes, write two lines: what you were trying to do, and what you'd already tried. When you get unstuck, add a third line with what actually worked. This costs nothing and it solves the "I have nothing to write about" problem permanently. You have plenty to write about; you're just not capturing it.

2. Pick the entry where you were most confused, and write 600 words. Not a comprehensive guide. Not a listicle. One problem, one resolution, one file path or command or setting that mattered. If you've been debugging with Claude Code as a non-developer, you have a dozen of these already sitting in your terminal history.

3. Say what you are in the first paragraph. "I'm a non-technical founder and this took me four hours" pre-empts every dismissive comment and costs you nothing, because it's true and people can tell anyway. It also reframes the post for the reader who needs it most — the one at your level.

4. Publish somewhere you own. swyx is blunt about avoiding walled gardens like Slack and Discord because they aren't public. McKenzie makes the same argument about GitHub-only projects: if the credit accrues to the platform rather than to you, you've done the work and rented the result. A blog on your own domain, even an ugly one, is the version you keep. I wrote more about this in building in public as a non-technical founder.

Then do it again next week. The single biggest predictor of whether this works is not writing quality. It's whether post two exists.

Frequently asked questions

Isn't learning in public just going to expose how little I know?

Yes. That's the mechanism, not a bug in it. The alternative — quietly not knowing things — has all the same knowledge gaps plus none of the corrections. Label your level explicitly in the first paragraph and the exposure stops feeling like exposure and starts feeling like context.

What if I publish something technically wrong?

You will. Fix it in place, add a short note saying what changed, and move on. Readers are far more forgiving of a corrected post than of a post that quietly gets edited or one that stays wrong. The reputational cost of visible correction is close to zero; the cost of being confidently wrong and never updating is much higher.

How is this different from building in public?

Building in public shares progress and metrics: launches, revenue, milestones. Learning in public shares transferable lessons. They overlap, but you can do either without the other. Learning in public is the more durable of the two, because a solved-problem post is useful to a stranger three years from now and an MRR screenshot isn't.

Do I need an audience for this to be worth it?

No, and expecting one early is the main reason people quit. The first-order benefit is that writing forces you to check whether you actually understood the thing. That benefit exists at zero readers. Treat the audience as a lagging indicator, not the goal.

How often should I publish?

Whatever cadence you'll sustain for a year. Weekly is plenty. Consistency beats volume, and it beats quality too, at least at the start — one decent post a week for a year produces something no amount of sporadic brilliance does.

What if my competitors read it?

They will, and it will matter less than you think. Almost nothing that makes a small SaaS work is a secret; it's execution, taste, and support. If a competitor can beat you by reading your blog post about a Supabase policy you misconfigured, the blog post wasn't the problem.

Learning in public is a bet on the version of you that exists in a year

The uncomfortable truth about learning in public as a non-technical founder is that it doesn't get comfortable. Six months in, I still hesitate before publishing anything technical. What changed isn't the feeling — it's that I stopped treating the feeling as information about whether to publish.

Every post is a small deposit into something McKenzie describes better than I can: capital you own rather than rent. Skills you can point at. A record of problems you solved. People who know your name because you were the one who showed up and wrote the thing down. Amy Hoy's metaphor, which he quotes, is the right one — brick by brick, the wall gets higher, and it only looks like a sheer wall of awesome from the outside.

You're not behind. You're just early, and you happen to be early in public.

I write about this stuff weekly on the Coding Capybaras blog — the boilerplate itself is free if you want to see how a non-technical founder actually built and shipped it.