You Don’t Have a Marketing Problem
Why producing more software does not mean creating more value.
Most people don’t understand AI, but not in the way they think.
They think the misunderstanding is technical. Like: “people don’t get how the model works,” or “they overestimate hallucinations,” or “they don’t know the difference between Sol and Terra” or whatever. That’s not the core misunderstanding. The core misunderstanding is economic.
Not macroeconomic. Not “the job market.” I mean the economics you can’t avoid if you’re building anything: opportunity cost, risk/reward, and the weird units where software actually becomes valuable—scale, repetition, leverage.
AI has made it dramatically easier to produce software. And somehow people jumped from “I can produce software” to “I can create value.” Those two are not the same thing. They were never the same thing. We just got away with conflating them because producing software used to be expensive enough that it filtered who could play the game.
Now the filter is gone.
So you get a wave of builders shipping things that work, that look fine, that have authentication, pricing pages, onboarding flows, and a bunch of features that compile. And then the builders say, with a straight face: “Marketing is hard.” or “We have a marketing problem.”
No. What you have is a value problem. And value is harder than software.
Here’s the uncomfortable claim: most of this AI-written software will be garbage. Not because the code is wrong. Not because the UI is ugly. Not because the product is “bad.” Garbage because it will absorb time and attention and money and produce nothing on the other side. No value out. Not even learning out.
And that’s a particularly deceptive kind of waste, because it feels like progress. It feels like creation. You get the dopamine hit of shipping. You get the illusion of momentum. You can point to a URL.
But nobody uses it. Or ten people use it. Or a few people try it once and leave. Or worse: some people do use it, and now you’ve bought yourself the privilege of running a system you didn’t really want to run. You wanted to build. You didn’t want to operate.
The bottleneck was never just the software.
That’s the part that’s hard for people to accept, because for a long time the bottleneck really did feel like software. If you were a non-technical founder, you had to find an engineer. If you were a junior engineer, you had to level up. If you were a small team, you had to spend months building the first version before you could even show it to anyone. “Shipping” was the hard part.
So the story became: once we can ship faster, we’ll win more.
But the startup story, the thing people romanticize, has always had two giant components. One is making something. The other is getting it into the world, watching how it behaves, listening to people, adjusting, fixing, supporting, deciding what not to do, handling failures, and doing that over and over. The second part is not a “marketing add-on.” It’s the business. It’s the operation.
And now that the first part is cheaper, the second part becomes brutally obvious.
Think like a CEO for a second. I once heard a line that stuck with me: the job of a CEO is to reduce risk. That’s it. Not to write code, not to craft pixels, not to ship features. Reduce risk.
If you take that seriously, building with AI becomes way clearer.
With AI, you’re placing bets. You can place more bets per week than you could before. You can prototype faster. You can get to a working demo faster. You can generate “a product” faster. That’s real. That’s not hype. It’s a big deal.
But placing bets faster doesn’t reduce risk. In fact it can increase risk, because you can now generate an infinite amount of surface area—features, code paths, integrations, promises—without having earned the right to maintain them.
If you’re not consciously reducing risk while you ship, you’re just manufacturing liabilities at higher throughput.
But those liabilities arrive later, while the reward of building is immediate.
This is why the “vibe coding” wave is so appealing. It feels like pure creative expression. Software has always been kind of magical: you can encode rules into a screen and it reacts. It’s interactive. It’s like writing a living thing into existence. And for the first time, people who couldn’t code are now shipping real software. They’re building authentication systems, connecting payments, creating dashboards, generating landing pages, setting up pricing.
I’m not here to sneer at that. It’s genuinely impressive. It’s also genuinely fun.
But fun is not value.
And this is the part people keep missing: AI makes the building cheap. It does not make getting anyone to care cheap.
You can ship an app in a weekend. You can ship five apps this week. You can ship a dozen “products” before you’ve had a single uncomfortable conversation with reality. Before you’ve had to earn attention. Before you’ve had to be chosen over doing nothing. Before you’ve had to find out if anyone comes back.
That’s the trap. AI is like a machine that turns imagination into artifacts. And artifacts are seductive, because they look like progress. But the world doesn’t reward artifacts. The world rewards things that people actually use, repeatedly, in a way that changes their behavior.
So when people say “we have a marketing problem,” what they often mean is: “we built something and reality isn’t cooperating.”
That’s not a marketing problem. That’s the actual problem.
It’s not that distribution is irrelevant. It’s that distribution is not a sticker you slap on top of value. Distribution is where you discover whether value exists at all. It’s where your neat business model in your head collides with what people actually do.
And that collision is exactly what a lot of builders are trying to avoid.
If reality rejects the product, you have to reconsider it. If reality accepts it, you have to operate it. Either way, shipping is only the beginning.
A lot of builders are going to learn the hard way that the bottleneck was never the software. The bottleneck was always: can you get someone to care, repeatedly, and can you keep the thing running while they do?
That’s operations.
Operations is not a department you hire later when you “scale.” Operations is the ongoing activity of making a promise and paying the cost of keeping that promise. It’s answering complaints. It’s handling refunds. It’s reading confused emails. It’s figuring out why your system ran out of memory at 3 AM. It’s fixing broken flows. It’s noticing that people churn in onboarding and actually doing something about it. It’s deciding what not to build. It’s monitoring. It’s support. It’s reliability. It’s the emotional labor of caring about users when you’re tired and the product isn’t glamorous anymore.
Marketing is where that promise first meets the people who can accept or reject it.
This is why the “marketing is hard” complaint is such a tell.
When someone says “marketing is hard,” what they often mean is: “I don’t want to do the part where reality gets a vote.”
Marketing, in the broad sense, is just getting your product into the hands of the people it’s for. That includes distribution, yes. It includes messaging, yes. But it also includes understanding what those people value, what alternatives they have, what pain they’re actually trying to solve, and why they would pick you over doing nothing.
If your product doesn’t fit into someone else’s life as a clear win, no amount of “marketing” saves it. If you can’t position it cleanly in their mind, if they can’t immediately understand what it’s for and why it’s for them, your software being beautifully engineered is irrelevant. You’re building a thing that doesn’t have a home in the world.
And AI doesn’t solve that. AI can brainstorm with you. It can generate copy. It can produce variations. It can role-play. But it cannot do the one thing that matters here: decide what is valuable for your users in the context of their lives and then build a system that reliably delivers it.
That’s your job.
Because value is determined in the user’s life, not inside the software, “it works” is a weak argument.
People keep defending their AI-built apps like: “but it works.” Okay. A lot of garbage works. Working is table stakes. Working is not value.
Value is created relative to other people. Not your internal model of the world. Your internal model is a starting point, sure. But value is something you negotiate with reality. With markets. With segments. With communities. With people who recommend things to each other and who have their own definitions of quality and their own alternatives and their own constraints.
This is messy. It’s not deterministic. You don’t get to just build in a vacuum and then declare value. You have to bring the model in your head into contact with the world as other people experience it. You have to discover where the bottleneck is for them, not for you.
And here’s the kicker: even if you find something people like, that’s still not the end. Now you have to run it.
We look at software companies and we see the facade. We see the app. We see the interface. We see the flow. We see the product screenshots. We see the “ship.”
We don’t see the machinery behind it.
Take a company like Airbnb. People call it an “app” because that’s the part you can screenshot. But the real thing is an operation: trust, disputes, support, edge cases, fraud, user behavior, and all the messy human things that don’t fit neatly into a product demo.
That’s not a dunk on Airbnb. That’s the point. The value is not “the app.” The value is the machine behind it. The part that keeps working when humans behave like humans.
If you think the app is the business, generating the app can look like generating the business. It isn’t.
This is why the fantasy of “I’ll just automate everything” is so misleading.
Yes, you can automate more things now. You can generate code that does real work. You can build internal tools, scripts, integrations, workflows. You can build an MVP in a weekend. Great.
But the real businesses—the ones that actually create and capture significant value—have a huge operation behind them. That operation doesn’t magically appear because you used an LLM to write your backend.
And if you’re solo, or a tiny team, you can’t escape that. You can pretend you can. You can build ten apps at once and tell yourself you’re building a portfolio of bets. But when one of them actually starts to grow, you’ll discover a constraint that is not a matter of willpower.
When you’re actively maintaining a growing piece of software, you can only do one. Maybe not literally one, but effectively one. Because growth creates demands: more users, more support, more bugs, more requests, more infrastructure load, more edge cases, more expectations. The moment people depend on your thing, the cost of caring rises.
And that cost doesn’t scale down just because you can generate code faster.
This is the part vibe coders are mostly not pricing into their behavior. They’re building nonstop. Many projects at the same time. Sometimes chasing unverified features.
But seriousness isn’t measured by how much you build. It’s whether you’re willing to run the system.
And the reason most of this will be garbage is not that the builders are incompetent. It’s that they’re optimizing for the part that feels creative and controllable, and avoiding the part that feels slow and social and uncertain.
It’s not easy to listen to users. It’s not easy to constantly re-prioritize. It’s not easy to do customer support when you’d rather ship new features. It’s not easy to go to market. It’s not easy to handle the reality that users don’t care about your cleverness. It’s not easy to accept that sometimes the most rational move is to kill the thing you just spent two weeks building.
So instead, people keep building. Because building feels like progress. And AI makes building feel like flying.
There’s another misunderstanding hiding here, and it shows up a lot among engineers.
We grew up with deterministic software. By definition, software was logic. If this, then that. You can prove things. You can test. You can be confident. A lot of engineering education is built on this worldview: precision, guaranteed outcomes, repeatability.
Now we have a new kind of software that is probabilistic. Agents. LLM-driven systems. Outputs that vary. Behavior that is shaped by prompts and context. People call it “unreliable” because it can hallucinate.
And some experienced engineers reject it instinctively. They say: if it can be wrong, it’s unusable. And they’re not completely wrong.
But humans are probabilistic too. If you hire an employee, you don’t get a mathematical proof they’ll do the right thing. You get guardrails: culture, incentives, expectations, laws, accountability. You build systems around humans because humans are not deterministic machines.
So the real skill with AI isn’t pretending it’s deterministic. The skill is learning how to constrain it, shape it, and govern it.
Once execution becomes cheap and probabilistic, the scarce skill moves upstream: deciding what matters, defining acceptable behavior, and taking responsibility for the result.
That’s management.
Building with AI is not “tell the model to do it and then cash the value.” It’s: define what matters, choose the lane, constrain the output, review it, fix it, integrate it, test it, and then keep doing that while the world changes.
If you’re reading this as a PM or founder or CTO, here’s the part I actually want you to feel in your gut:
The relevant measure of speed is not how much software you produce. It’s how quickly that software reduces uncertainty.
If you are shipping faster and learning the same amount, you’re not accelerating. You’re just wasting time at higher throughput.
Because early on, before anything has pull, the job isn’t “ship more.” The job is to reduce uncertainty. To find out what people do when you put your thing in front of them. To find out what they ignore. What they misunderstand. What they come back for. What they’d pay for—or what they’d only use if it were free. To find out whether your product is actually a product, or just a demo you like.
You can build a prototype faster than ever. That should change how you prototype. It can even change the order of prototyping. It used to be that software was the most expensive, highest-fidelity step. You’d sketch. You’d storyboard. You’d do low-fi mockups. Then maybe you’d build.
Now you can build first. That’s wild. It can be faster and better to produce an interactive prototype than to draw a napkin sketch.
But this creates a new trap: because you can produce high-fidelity experiences immediately, you start putting fidelity where you haven’t earned it yet. You build the full thing. You polish it. You add features. You lock in design decisions. You spend your time making it feel real.
And then when you show it to users, they judge it by the wrong things. They comment on the color. They comment on the look. They get distracted by the surface. Or you get emotionally attached, because it’s not a sketch anymore—it’s a product. You’ve already invested.
High fidelity doesn’t merely cost more. It changes the experiment: users become more likely to evaluate the surface, and builders become less willing to revise the premise.
Prototyping used to be staged for a reason. It’s not because we lacked imagination. It’s because staged fidelity helps you learn the right things in the right order.
AI can compress time-to-prototype. It doesn’t remove the need for learning stages.
If anything, it makes discipline more important, because the temptation to skip the learning loop is stronger than ever.
And this is where I think the “CEO reduces risk” lens becomes the only sane way to build with AI.
If you’re placing bets, the goal is not to place the maximum number of bets. The goal is to reduce risk per unit time. That means your process needs to constantly ask: what’s the biggest uncertainty here? Where is the bottleneck? What would make this real?
Sometimes the bottleneck is technical. Fine. Use AI to crush it.
But most of the time, at the stage where people are vibe coding, the bottleneck is not technical. The bottleneck is: do people want this? Will they switch? Will they pay? Will they trust it? Will they keep using it? Can you deliver the promise reliably? Can you handle complaints? Can you keep it alive when it breaks? Can you operate it when it grows?
Those are risks. And they don’t go away because you can generate code.
In fact, the ability to generate code faster can hide those risks. It can let you avoid them longer. It can let you build a more elaborate castle before you discover nobody wants to live in it.
That’s how you end up with “garbage”: lots of time in, no value out, not even learning.
And when I say learning, I mean learning about the business. Navigating the idea maze. Reducing uncertainty with contact, not with imagination.
Yes, sometimes when startups fail, people say “at least you learned something.” And that can be true in a personal sense: you did a bunch of things, you got sharper, you built skills. That matters.
But the specific poison of LLM slop is that it can produce neither: no real progress through the idea maze, and no meaningful sharpening either. Just output. It looks like building. It feels like motion. But it doesn’t buy you truth.
Shipping without learning is just output. It’s content production.
And content production is not what most people think they’re doing when they say they’re “building a startup.”
That doesn’t mean AI lacks leverage. It means the leverage appears after you have found something worth multiplying.
Once the machine works, using AI is much simpler. If you already have a system with pull—users, demand, a product that survives reality—then AI is an incredible optimizer. You can look for bottlenecks and opportunities. You can automate pieces. You can speed up delivery. You can reduce costs. You can do what a good consultant does: find the constraint, remove the constraint, repeat.
That’s not trivial, but it’s legible. It’s operating on an existing truth.
What’s much harder is creating value out of nowhere. The part where your neat subscription model in your head collides with the fact that customers don’t care, don’t trust, don’t switch, don’t pay, or don’t even understand what you built.
That’s the part where shipping is cheap and learning is expensive. And where a lot of people choose cheap shipping over expensive learning, because it feels better.
I’m not saying you shouldn’t build. Build. Building is powerful. Prototyping is powerful. One-off software is powerful. The fact that someone can now create a tool for their own life that used to be too expensive to justify is genuinely a new kind of freedom.
But don’t confuse that freedom with leverage.
Lowering the cost of creation expands what is personally worth making. Leverage requires something more: repeated value for other people.
The promise of software, the reason software is such an insane economic instrument, is leverage: you can serve massive scale with the same code. That’s the dream people are chasing when they sign up for expensive model subscriptions and build three apps a week.
If nobody uses your code, you have no leverage. You have an artifact.
If ten people use your code, you might have a nice toy. You might have a useful internal tool. You might have something that makes your own life better. That has value. But it’s not a value engine in the way people mean when they say “I’m building a business.”
If people use your code and depend on it, then the work begins. Because now you owe them something. Now you’re in operations. Now you’re in the business of keeping a promise.
And that is where most AI-built products will die—not because they couldn’t be built, but because nobody wanted to pay the cost of caring.
So here’s the distinction I want to leave you with, sharpened, not motivational, not a lesson, just a hard line you can use to judge your own work:
Producing software is when you can point to a working thing and say, “It runs.”
Creating value is when other people rearrange their behavior around your thing—when there’s pull, when it survives reality—and you can keep the promise you made to them tomorrow, and the next day, and the next.
AI makes it easy to produce software.
It does not make it easy to create value.
If your week ends with a working product and zero new information about what people will actually do with it, you didn’t build a business asset. You produced a convincingly engineered form of waste.
Credits
Image by Patrickamackie2 (Patrick A. Mackie), CC BY-SA 4.0, via Wikimedia Commons
Speech-to-text with Handy and Whisper Large v3.