Vibe a Business (1/4): The Economics AI Coding Tools Won't Teach You

Andrej Karpathy posted a throwaway observation in February 2025: he was building software by describing what he wanted, accepting whatever the AI produced, and running it. He called it “vibe coding.” Within twelve months, the throwaway observation became an industry. Cursor, Lovable, Bolt, Replit Agent, and a dozen other tools turned “I have an idea” into “I have a working prototype” in a single weekend. The vibe coding market hit $4.7 billion by early 2026, growing faster than anyone — Karpathy included — expected.

The pitch is real. A solo founder with no engineering background can ship a functional SaaS product in days. The design looks polished. The code runs. Stripe is connected. The landing page exists. This is genuinely new. Five years ago this person would have spent six months learning React or $30,000 hiring a freelance dev team. Now they spend a weekend and $20 in API credits.

Here is what did not change: the startup failure rate. It was roughly 90% before vibe coding. It is roughly 90% after. The bottleneck was never “can I build this?” The bottleneck was always “does anyone want this enough to pay for it, at a price that covers my costs, in a market large enough to matter?” AI coding tools removed the engineering constraint. They did not touch the economics constraint. The gap between “I shipped an app” and “I run a business” is now wider than ever — because the app part got easy and the business part stayed exactly as hard.

This is Part 1 of a four-part series. The goal is not to teach you to code. You already have tools for that. The goal is to give you the economic framework that determines whether the thing you coded deserves to exist as a business.

The validation math most builders skip

Before you write a single prompt in Cursor, before you describe a single screen to Lovable, you need to answer one question: how many customers at what price to cover my costs?

Most solo builders skip this. It feels premature — “I haven’t even built it yet, how can I know my costs?” But you know more than you think. You know roughly what you would charge. You know roughly what the infrastructure costs. You know whether you are using OpenAI’s API or self-hosting an open model. You can estimate.

A worked example. You want to build an AI writing assistant. You plan to charge $29/month. Your fixed costs: $500/month for infrastructure, $200/month for various SaaS tools, $1,300/month for OpenAI API costs at projected usage levels. Total: $2,000/month in fixed costs before you pay yourself a dime.

Break-even number of customers: $2,000 / $29 = 69 paying users.

That is the minimum to cover infrastructure. It does not include your time, your marketing spend, or your health insurance. It is the floor below which you are literally paying to give people a writing tool.

Is 69 paying users achievable? Depends entirely on the market, your distribution, and whether anyone actually wants another AI writing assistant (spoiler: that market has hundreds of entrants). But at least now you have a number. A number you can test against reality before you spend the weekend building.

Run this calculation yourself in the Break-Even Calculator. Change the price. Change the costs. See how sensitive the result is. If moving the price from $29 to $19 doubles the customers you need, that is information you want before you build, not after.

The four questions

Every pre-coding economics check reduces to four questions. Answer them honestly and you will know whether to build, pivot, or walk away.

1. Is someone already paying for this?

If no one is paying for a solution to this problem, you are not building a business — you are creating a category. Category creation is possible. It is also the single hardest thing in business, and it is not what a solo builder with a weekend should attempt.

Look for existing products that charge money for something similar. Not free tools. Not venture-funded products burning cash for growth. Products where real humans enter a credit card number and get charged monthly. If those exist, the market is validated. If they do not, the risk is an order of magnitude higher.

2. What would they pay me?

Not “what would I like to charge.” What would the customer actually pay, given the alternatives? If Jasper charges $49/month and Copy.ai charges $36/month, your AI writing assistant lives in that price band whether you like it or not. You might differentiate enough to charge more. You might need to undercut to get traction. But the band exists and ignoring it is fantasy.

Check competitor pricing pages. Read reviews to see what customers complain about paying for. Look at the Pricing Calculator to model different price points against your cost structure.

3. What does it cost to serve each user?

This is where AI products diverge from traditional SaaS, and it matters enough that Part 2 of this series is entirely about it. Traditional SaaS has near-zero marginal cost per user — the 100th customer on your platform costs about the same to serve as the 10th. AI SaaS does not work that way. Every API call costs money. Every token consumed hits your bill. Your costs scale with usage in a way that old-school SaaS founders never had to think about.

a16z found that AI companies often run gross margins of 50-60%, compared to 60-80%+ for traditional software companies. That margin compression changes every downstream number: break-even, runway, how much you can spend on acquisition, when you become profitable. If you are building on top of OpenAI or Anthropic APIs, you need to understand your per-user cost with real data, not estimates.

4. How many users to break even?

Take your monthly fixed costs. Divide by your contribution margin per user (price minus variable cost per user). That number is your break-even. The Break-Even Calculator handles the math, but more importantly, it shows you the sensitivity — how the number shifts when your assumptions change.

If break-even requires 500 paying users and you have no distribution channel, no audience, and no marketing budget, that is not a viable weekend project. It is a viable venture-backed startup, maybe. Different game entirely.

The weekend MVP trap

Vibe coding created a new failure mode that did not exist before: the illusion of validation through building.

In 2022, if you spent three months building something and nobody wanted it, that was an expensive lesson. In 2026, you spend a weekend. The cost is lower, which is good. But the psychological effect is the same — you built a thing, it works, it looks real, and now you are emotionally invested. You start telling people about it. You buy a domain. You set up a Stripe account. You are now a “founder” in your own mind, and you have not validated a single assumption about the business.

Shipping a working product to zero users proves nothing. It proves you can prompt an AI to generate a Next.js app. That is a skill, but it is not validation. Validation is someone paying. Not signing up for free. Not saying “this is cool.” Paying. As Paul Graham wrote in Do Things That Don’t Scale, the early users who matter are the ones who need what you are building badly enough to use it despite the rough edges. If you cannot find those people before you build, building will not create them.

The weekend MVP is valuable only if you built it to test a specific assumption with a specific audience. “I’ll build it and see what happens” is not a strategy. “I’ll build a landing page with a payment link and run $200 in ads to see if anyone converts” — that is a strategy.

The pre-coding economics checklist

Run this before your next build weekend. It takes thirty minutes and might save you months.

Step 1: Define the unit. What exactly is one customer paying for? A monthly subscription? A per-use fee? A one-time purchase? Get specific. “They pay $X per month for Y” is the sentence you need to be able to say.

Step 2: Map your costs. List every cost: hosting, API calls, domain, email service, payment processing (Stripe takes 2.9% + $0.30), any third-party tools. Separate fixed costs (same regardless of users) from variable costs (scale with each user). Use the Subscription Revenue Calculator to model this over 12 months.

Step 3: Compute break-even. Fixed costs divided by contribution margin per customer. Write this number down. It is the most important number in your business right now.

Step 4: Reality-check the customer count. Can you actually reach that many paying customers? What is your distribution channel? If the answer is “I’ll post on Twitter and Product Hunt,” know that the median Product Hunt launch generates fewer than 50 signups, and the conversion rate from free signup to paid is typically 2-5%. Do the math on your funnel, not your hopes.

Step 5: Compute CAC and required LTV. If you spend money to acquire customers, how much per customer? And does the lifetime value — revenue per customer over their entire lifespan, adjusted for your profit margin — exceed that acquisition cost by at least 3x? The CAC vs LTV Calculator runs this analysis. If the ratio is below 3:1, you are building a business that loses money on every customer. Scaling will make it worse, not better.

Thirty minutes. Five steps. If the numbers do not work on paper, they will not work in production. If they do work, build with confidence — you are not just vibing, you are building a business.

What comes next

This series continues with three more posts:

• The Token Tax: What AI API Costs Actually Do to Your Margins — Part 2 digs into the cost structure that makes AI products fundamentally different from traditional SaaS, and how to model it before it kills your margins.
• Pricing AI Products Without Losing Money or Customers — Part 3 covers pricing strategy when your costs scale with usage and your competitors are funded by people who do not care about profitability yet.
• SaaS Metrics After Launch: What to Track When the Vanity Numbers Look Good — Part 4 is about the metrics that matter once you are live: churn, expansion revenue, payback period, and the dashboard that tells you whether to double down or shut down.

The code is the easy part now. The economics never were.