The vibe coding distribution problem is two loops with opposite shapes.
It is not motivation. It is not marketing. It is not the deploy gauntlet. The prompt-to-preview loop is solo, fast, and synchronous. The preview-to-users loop is social, slow, and asynchronous. The workflow has no step that switches you from one to the other.
Direct answer, verified 2026-05-20
Vibe coding optimizes the prompt-to-preview loop. A preview that works on your screen does not produce users. Distribution is a second loop with a different shape (a stranger opens the URL, reacts, comes back) and the vibe coding workflow has no built-in step that triggers that second loop. The first loop closes again and again, the second loop never starts, and people call that the distribution problem.
Verified against the existing public takes on dylanbeattie.net and the mk0r implementation (file paths quoted below).
The discourse keeps missing the shape
The two main camps both have a piece of the answer and both miss the whole. The first camp lectures vibe coders for not knowing what real software needs: encoding, internationalization, concurrency, authentication, telemetry, billing, branding, mobile, deploy. That list is correct, but it is a symptom. The reason vibe coders never learn the list is not laziness, it is that those items live in a different loop and the workflow does not put the builder anywhere near it.
The second camp says the problem is the deploy gauntlet. Sign up for a host, point DNS, get SSL, set env vars, push. That list is also correct, also a symptom. The deploy gauntlet is what the outer loop looks like from inside the inner loop, when you cannot yet see that you have crossed into a different shape of work. Solving the gauntlet does not solve the loop. It just removes one wall in front of the loop, which is necessary but not sufficient.
What neither camp names is the shape mismatch. Vibe coding's joy is the inner loop. The inner loop has none of the traits the outer loop has. Treating them as a single skill called “shipping” is what makes the gap feel mysterious.
What actually happens in a vibe coding session
The last arrow is the whole point. The first six arrows close. The seventh has no built-in trigger anywhere in the session. There is no button at the end of a turn that says “show one stranger,” and there is no convention in the workflow that the session ends with a handoff. The session ends when the preview matches the spec in your head, which is an inner-loop condition. Sessions can run for hours satisfying that condition without the outer loop ever being addressed.
The two loops, side by side
Here is the comparison in concrete terms. Read it as two engineering loops with different non-functional requirements, not as “coding versus marketing.” The point is that they select for opposite traits in the same person.
| Feature | Inner loop (vibe coding) | Outer loop (distribution) |
|---|---|---|
| Number of participants per cycle | 1 (you) | 2 or more (you and a real reader) |
| Latency | Seconds (token stream, hot reload) | Hours to days (post, wait, reaction) |
| Failure mode you see | Compile error, broken UI | Silence (nobody opens, nobody reacts) |
| What progress feels like | Linear, additive (each prompt improves it) | Lumpy, mostly nothing then a spike |
| What blocks you | Model misunderstanding the spec | Other humans not opening the URL |
| Skill it rewards | Depth (one more iteration) | Breadth (one more conversation) |
| Where vibe coders have practice | A lot, by definition | Often very little, also by definition |
Notice the last row. The vibe coding scene self-selects for people who love the inner loop, which mechanically means it self-selects for people with little practice in the outer loop. That is not an insult, it is a definition. Telling someone whose entire workflow is solo synchronous depth that they need to do social asynchronous breadth is telling them to be a different person in their off hours. Some make the switch. Most do not, and that is the distribution problem in a sentence.
The three escape attempts (and why each one stays inside the inner loop)
People feel the gap and try to bridge it without leaving the comfort of the inner loop. The three moves below are the most common attempts. Each one is real, each one fails the same way: it keeps you in solo synchronous depth while pretending to do social asynchronous breadth.
Attempt 1: post the screenshot
You tweet a screenshot of the app, or a screen recording, with the prompt that built it. Engagement on the post becomes a proxy for the app working. The post gets likes. The URL gets two clicks. The outer loop did not start, because what you measured was the inner loop's output, not somebody using the thing.
Screenshots are inner-loop artifacts in outer-loop clothing. They show that the prompt-to-preview loop closed, which is the easy part. They do not test whether anybody can open the URL on a phone in line at a coffee shop and figure out what to do with it.
Attempt 2: launch it on Product Hunt
You submit, you ask friends to upvote, you reply to the comments. The day passes. You get a hundred clicks. Nobody comes back. You conclude the idea was wrong. Sometimes it was. More often the launch was a single outer-loop pulse instead of a habit, and one pulse never compounds.
A launch is a useful one-time event, not a distribution strategy. The outer loop needs to run repeatedly with the same audience to do anything at all. A single spike followed by silence reads exactly like an idea that did not work, even when the real cause is that nobody followed up.
Attempt 3: ask an AI to do marketing for you
You prompt the model to write your launch post, your replies, your cold DMs. It produces fluent text that lands in feeds. The text gets ignored, because the part of the outer loop that matters is not the text, it is being a recognizable specific person whose taste is worth listening to. The model can't be a specific person on your behalf.
The inner loop's tool (a model that produces fluent output) is exactly the wrong tool for the outer loop, where what gets attention is recognizable particularity. Trying to outsource the outer loop to the same model that runs the inner loop is the most common failed escape. It feels like progress because text is being produced.
The honest minimum: a human in the loop, exposed as code
mk0r's bet against the distribution problem is two things, and one of them is the one I want to actually defend. The first is the preview URL: the output of a build session lives at <vmId>.mk0r.com with no signup, no wrapper, and a one hour TTL set at src/core/e2b.ts line 33 as E2B_TIMEOUT_MS = 3_600_000. An hour is enough for the one outer-loop pulse that most vibe-coded projects ever get (the DM, the X reply). It is the opposite of an evergreen URL on purpose.
Anchor fact
The publish flow at src/app/api/publish/route.ts ends with line 16: const NOTIFY_TO = "i@m13v.com";. When a user submits a custom domain through the UI, the server sends an email to that address with the session details, and a human wires the DNS. The reason this is honest rather than lazy is visible one file over: at src/core/e2b.ts line 2334, startDomainVerification throws the literal string “Domain publishing is not yet supported on the E2B backend.” That message is what every other AI builder hides behind a smooth UI. mk0r exposes it.
0 human in the loop, on purpose. The argument is not that this is elegant. The argument is that at the precise stage a vibe-coded project crosses from inner loop to outer loop, talking to a specific person for two minutes is cheaper than learning DNS, and the conversation forces a real check on whether the project deserves the next step.
But isn't this just marketing?
The counterargument writes itself. Yes, of course the outer loop includes marketing, the way the inner loop includes typing. But collapsing the whole outer loop into the word marketing loses the structure that makes the loop hard to start. Marketing is the part of the outer loop that produces awareness. The outer loop also includes: the recipient opening the URL on the device they actually use, the moment they figure out what to do with it, the moment they react, the moment they come back. Posting more does not fix any of the four. They are separate problems with separate shapes.
The other version of the counterargument is “sounds like a you problem.” Sure. The whole point of the article is that the workflow does not put you anywhere near the outer loop, so the you-problem is structurally produced. Naming the structure is what lets you do something about it that is not willpower.
What I want you to take from this
Do one outer-loop turn per day, however small. Not a launch, not a marketing plan, not a content calendar. One specific person opens the URL on their phone, taps one thing, and says something back to you. If the URL does not exist yet, make it exist, even if the app is half done. The first time the outer loop closes, you find out whether the project deserves the inner loop you have already been running on it. That is what the discourse is calling distribution. It is mostly a habit, not a skill, and almost nobody is building the habit because the workflow does not ask them to.
Want to run one outer-loop turn this week?
Bring whatever you've built (or haven't yet). I'll generate a URL on mk0r live with you, we'll send it to one specific person, and we'll watch what happens. Two-minute call, no slides.
Frequently asked questions
What is the vibe coding distribution problem in one sentence?
Vibe coding optimizes the prompt-to-preview loop, but a preview that works on your screen does not produce users. Distribution is a second, structurally different loop (a stranger opens the URL, reacts, comes back) and the vibe coding workflow has no built-in step that triggers it. So the second loop never starts, and people call that 'the distribution problem.'
Isn't this just the same as 'marketing is hard'?
No, and that conflation is most of why the problem is hard to talk about. Marketing is one part of the outer loop (how strangers learn the app exists). The outer loop also includes the part where they open it, the part where they react, and the part where they come back. Vibe coders who try to fix this by 'doing more marketing' usually still skip the parts of the outer loop that are not posting. Treating the loop as a single skill called 'marketing' loses the structure.
Why is the inner loop incompatible with the outer loop?
Three reasons stacked. The inner loop is solo, the outer loop is social. The inner loop is synchronous (you prompt, you see), the outer loop is asynchronous (you post, you wait, somebody reacts hours later). The inner loop rewards depth (one more iteration makes the app better), the outer loop rewards breadth (one more conversation finds one more reader). None of those traits transfer. People who are great at the inner loop are often physically uncomfortable in the outer one. That is not weakness. It is the same person being asked to use a different muscle.
What does mk0r actually do about this, concretely?
The output of a build session is a live URL on the open internet at <vmId>.mk0r.com. No signup, no install, no wrapper UI. The recipient clicks and the app loads. The proxy that decides this is src/proxy.ts in the open source repo. The catch is that the URL has a one hour TTL (E2B_TIMEOUT_MS = 3_600_000 at src/core/e2b.ts line 33). That hour is shaped for the X-reply or DM moment, which is the only outer-loop moment most vibe coded projects ever get. After the hour, if the project is worth keeping, you go through the publish flow.
What does the publish flow look like and why is a human in it?
The publish flow lives at src/app/api/publish/route.ts. When a user submits a custom domain, the server sends an email to the operator at NOTIFY_TO = 'i@m13v.com' (line 16) with the session details, and a human wires the DNS. The reason is honest: the function startDomainVerification at src/core/e2b.ts line 2334 throws the literal string 'Domain publishing is not yet supported on the E2B backend.' Most AI builders hide this kind of edge with a UI that pretends to be automated. The mk0r codebase exposes it as a human-in-the-loop step on purpose, because at the point where a vibe coded project is good enough to keep, talking to the operator for two minutes is cheaper than learning DNS, and it forces a real conversation about whether the project deserves the next step.
So is the answer 'vibe coding does not scale'?
It is not. The framing 'does not scale' borrows the language of the inner loop and applies it to a question the outer loop is supposed to answer. The right question is not whether vibe coding scales, the right question is whether the specific app you vibe-coded earned its outer loop. Most do not, and that is fine, the point of being able to build a hundred things is that you can throw away ninety nine. The distribution problem appears bad because people count the ninety nine, instead of measuring the one that survived against the right baseline (which is one stranger reacting, not 'product market fit').
What is the smallest test of the outer loop having started?
One specific person, who you do not live with, opens the URL on their phone, taps something, and reacts in a way you did not script. Not a like on your tweet, not a 'cool' reply, an actual reaction to the app. That is the unit. If you can produce that today with what you built, you crossed the loop. If you cannot, you are still on the inside, and no amount of marketing language is going to change that until the URL works.
Why does the existing discourse miss this?
Two reasons. The pages that lecture vibe coders for not knowing what 'real' software needs (encoding, auth, billing, telemetry, etc.) are correct about the list but wrong about the cause. The list is the symptom of staying in the inner loop too long. The pages that reduce the problem to deploy mechanics (sign up for Vercel, learn DNS, get a domain) collapse a structural shape problem into a checklist. Neither side names the shape mismatch directly, so neither has a good prescription. The prescription is not 'learn deployment' or 'do marketing', it is 'do exactly one outer-loop turn per day, however small, even if the app is half done.'
The walls that show up after this one
Adjacent reading
Why Vibe Coded Apps Never Ship
Build was the fast part. The five steps between 'preview works' and 'live URL' (account, hosting, DNS, SSL, env vars) are a different skill set, and nobody crosses them on motivation.
AI App Build Is Easy, Distribution Is Hard
The handoff tax nobody is pricing. Signup walls, install gates, expired sandboxes. The 53-line proxy that decides whether your share link does any of that.
Vibe Coding to Paying Users
What it takes to cross from 'a stranger reacted' to 'a stranger paid.' A different loop again, with its own shape.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.