This is the third essay in my series on learning to program and building in the midst of a software paradigm shift. In “Free Range Apps“, I argued that cheap software creation could unlock a long tail of micro-applications built by and for specific communities. In “Surfing the Claude Wave“, I walked through how I rebuilt Wave Floral’s website with Claude Code. This piece is not only about what I’ve watched ship in the year since, but what’s still missing.
If you’re new here: I’m Megha. I freelance for early-stage startups as a software and product consultant, and I run Wave Floral, a floral design studio in San Francisco. I was previously co-founder of Whimsy, an AI-native backend for event professionals.
I write about my life across floral design, sports, life in San Francisco, and at times: programming! I started learning to code five years ago and feels empowered by the current paradigm shift, and wants others to feel that way too.
When I wrote “Free Range Apps” last summer, I was bullish on vibe coding as a populist force. I still am. But I’ve spent the last six months getting my hands dirty: freelancing for early-stage startups, consulting with companies ranging from stealth startups to Fortune 100s on AI adoption, running workshops to help non-technical folks ship their first apps, and watching every major vibe coding platform race to fill in the gaps.
Some of what I predicted has played out. A lot of what I worried about is still broken. And the part of the market that everyone is racing to commoditize, the prototype layer, is, in my view, basically over as a place to build a defensible business.
The interesting question now is: what happens after the prototype?
You may find this essay useful if you are:
Building applications that let users generate code using AI, vibe coding or otherwise
A product manager or engineer at a larger company who wants a landscape view of what’s possible and what’s actually happening
What’s saturated, and what shipped
The typical flow of building software, from idea to live product, looks roughly like this:
Idea → UI → Backend → Auth → DB → Payments → Deployment → Scaling
A year ago, vibe coding tools had gotten good enough at the first three steps, but were still struggling to chain together the remaining steps in hosting and maintaining a production application.
However, there’s been a lot of movement in the last year, with many existing vertical SaaS companies developing and shipping an AI product.
What’s actually shipped since last year:
Payments. Lovable now integrates with Stripe and Paddle. Replit offers Stripe and RevenueCat (for mobile apps), so users can accept payments directly.
Security. Most platforms have become SOC 2 compliant. Lovable partners with Aikido for pentesting and bridges the process for builders who need SOC 2 and PCI compliance.
Auth. Google Sign-On and basic identity and access management (IAM) have become standard. MCP-based auth providers like Clerk and WorkOS slot in cleanly with agentic flows.
Email. Transactional email, the kind of service that used to require setting up Sendgrid or Postmark, is increasingly bundled as an embedded feature in the platform. Lovable sends from your branded domain; Replit integrates with Resend.
Deployment. Vercel’s V0 and Replit’s hosting have made “your app is live at this URL” the default state. I’ve started calling this deployment-as-a-prompt: getting builders to the happy path of sharing their product. It requires obfuscating CI/CD, DNS, and a lot of other plumbing.
If you only needed software to look pretty and accept a credit card, we’re roughly there. The prototype layer is a commodity.
This saturation point has created a workflow arms race, which means much of the defensibility now lives in platform lock-in and in owning the rest of the pipeline.
The messy middle: where vibe coding still breaks
Anecdotally, I’d argue market penetration of vibe coding is close to maxing out. Whoever is curious enough to start using these tools now likely already has. By the time the rest of the population gets there, AI-embedded tooling will just be normal software. The Internet is already littered with hundreds of personal to-do apps, the canonical first vibe-coded project.
One useful way to think about programming (borrowed from Shravan Suryanarayana’s framing) is in three layers:
Service layer — what your application does (when a user does X, the app does Y)
Infrastructure layer — the plumbing (how data is displayed, who can see what)
Deployment layer — the delivery (how the app moves from your machine to many machines)
Vibe coding platforms have commoditized the service layer. But context windows, leaky memory, and the current state of AI-driven code mean the infrastructure and deployment layers still need work. The way that large platforms choose to solve this problem now will likely define how exactly a commoditized AI-native world will look for our software in the next decade or so.
Given we’re heading toward saturation at the top of the funnel, the next natural step is figuring out what to build for people who want a real, working, often-monetizable product.
Everything between “this works on my machine for one user” and “this serves 1,000 paying customers without falling over” is what I’m calling the messy middle. It’s where vibe coding without software knowledge still mostly fails, where the next wave of differentiation will happen.
Concretely, the messy middle includes:
Multi-tenant architecture. AI-generated code overwhelmingly assumes a single-user application. It loads one person’s data, runs one person’s session, and breaks the moment two users hit the same endpoint. There is no implicit understanding that “users” means “many people, isolated from each other, with permissions.”
Concurrency and latency. What happens when ten people submit the same form at once? When a database query gets called from twenty sessions simultaneously? Most vibe-coded apps haven’t been stress-tested past the original builder’s local machine.
Database design and migrations. Schemas built by prompt tend to be brittle and susceptible to row-level security breaches, especially between production and dev environments. In plain English, users may be able to see other users’ data on applications with AI-built databases (and human-built databases, for that matter) Just to start, what does a row-level security (RLS) issue mean to a non-technical user? What’s a better way to communicate that?
Version control. Many platforms abstract Git away entirely, which feels great until you need to roll back a bad change or collaborate with another person. This is where the recurring “will GitHub become obsolete?” question shows up, and I think the answer is no — but its interface might. People may never have to learn how to rebase a change ever again.
Security and secrets management. Knowing what an environment variable and API key can not be expected of the average vibe coder; yet most platforms lack in-product education around this. The consequences of an AI agent reading environment variables, especially in the hands of a bad actor, could mean getting hacked.
These aren’t sexy problems. They are also the entire reason software companies exist as companies, which is why whoever solves them for non-technical builders captures the actual long tail.
Vercel vs. Lovable vs. Replit vs. Base44: a breakdown
A quick read on where the major vibe coding platforms sit, and what I think each is best positioned to win:
Vercel
Vercel is a dark horse for non-technical builders, given its long history as a hosting and deployment platform. That edge is what I think makes Vercel the best positioned out of all vibe coding apps in terms of staying power. Vercel’s core business is hosting, deployment, environment management, secrets, and edge infrastructure.
That is the messy middle. V0 is a relatively commoditized no-code app builder, but it doesn’t have to win on prototype quality. It just has to feed the rest of the Vercel stack. The hard part of running a real application is what Vercel has been quietly building for a decade.
I’ve used Vercel in the past for my old startup, and currently use it for my side projects, such as Hawk Hill PR. This application uses wind data to calculate whether or not it’s favorable to attempt a PR on a popular cycling segment in San Francisco. I wanted to try v0 to quickly add a feature enhancement that I’ve been putting off: displaying the wind and PR conditions by hour.
v0 checked out a new branch, made a consistent design change, checked with me, and then deployed the feature.
What I especially liked was being able to directly deploy on the platform, though I’d be curious how this scales in a large engineering team.
Given that, v0 and Vercel are likely best for more technical folks due to the long tail of hosting, deployment, and server features that are the platform’s core offering.
Lovable
On the other hand, Lovable is the most design-forward and clearly built for non-technical users. They recently shipped Lovable Aesthetics, giving users more autonomy over the design system.
Their templates remind me of website builders like Squarespace or Framer, with landing pages that are designed to convey to users, building your own product is easy and beautiful. Additionally, Lovable moved fast on integrating and/or building payments, auth, and email.
Tellingly, they let you export a project to GitHub but not import one, a product decision that tells you everything about who they think their user is: someone starting fresh, not someone with an existing codebase.
Replit
Replit is the inverse. They’ve leaned into technical users with code import, a real IDE, and Vercel deployment integration. What’s most interesting to me is how aggressively Replit has in-housed the messy middle: their own database, app storage, auth, and domain handling. This is either a brilliant moat or a giant maintenance burden, depending on execution. I suspect many of these were features the Replit team had already built for their original IDE business, which makes the strategy more defensible than it first appears.
Base44
Base44 is in an interesting position, as their parent company is Wix, the website builder giant. Unsurprisingly, they’ve built a robust template marketplace featuring both free and paid templates from the Base44 team alongside power-user submissions. This is the Squarespace/Wix playbook applied to apps.
The pattern across all of them: the prototype builder itself is becoming a loss leader. The business is in what comes after.
The product questions that will define this category
If you’re building a vibe coding tool, or working at one, I’d push on a few questions.
Is everyone really a builder?
Perhaps a better way to frame this question: does everyone need to be a builder?
The original promise of vibe coding was that anyone could build their own software. However, the more workshops I run, the more I see a bimodal distribution: some people genuinely get it and run, others want the outcome without the building and get frustrated when their prompts don’t generate the output they wanted. Both types of users are valid to build for, but require a completely different set of product features, user interfaces, and integrations.
Currently, vibe coding platforms seem to be facing the same question when figuring out how technical and self-starting their ideal power user is.
The honest move might be to develop a marketplace of power users who build for others — the way Framer and Squarespace eventually grew an entire freelance economy around them. This feels like it cuts against the founding pitch, but I don’t think it does. There’s always arbitrage, and skilled vibe-coders-for-hire are an extension of the long tail.
Bethany Crystal, founder of Build First (an AI learning lab where I am a co-facilitator), frames it well: are you a maker or a user of the tool?
So, the question builders of these platforms should be asking is: are we building with embedded AI for users or makers?
Who is the end user of your end user’s product?
Answering this question as a platform helps you unlock user retention. Put a different way, this is really the question of how your platform helps your users make more money.
Typical user personas in this space:
Solopreneurs building a monetizable product
Teams shipping internal apps for features that would have otherwise been deprioritized
Curious tinkerers looking to build personal apps, typically for entertainment
Tech-cautious users using generative AI as another search engine
There’s a real distinction between building for solopreneurs trying to monetize and building for internal teams who want to ship apps that would otherwise have been deprioritized. I’ve heard compelling versions of both use cases, and the product implications are different.
What’s the easiest way to describe cost and token usage?
Users are inherently mistrustful of the token and usage limits they keep hitting. Platforms need a better way to anticipate and communicate costs before they focus on reducing them.
Generative AI platforms are racing to build new features and user interfaces, while simultaneously iterating on token optimization in the interim. It’s possible that tokens become commoditized by the time that we figure out how to actually explain what a token is to your uncle at a dinner.
In the interim, there are some product user interfaces that could improve transparency, and therefore, user trust and retention in the product:
Acting like a fuel gauge: translating the token usage into the user’s actual task, with some context on the previous prompts. E.g. “About 8 more long conversations” or “roughly 30 more code edits at your current prompt usage”
Itemized receipts: Showing the cost after the prompt, itemized, the way receipts often are. Users may tolerate surprise pricing far better when they can see what they paid for. The worst version of this is the silent meter; the best version is the post-task summary that says “this run used X because you attached a 40-page PDF.”
How much should you configure for users versus letting them configure themselves?
Teaching workshops on AI adoption, in addition to scoping calls with consulting inquiries, requires a strong intuition of where I’m losing my audience vs. guiding them towards the vision or curiosity of what they want to build. I worry constantly about whether participants understand the workflows I give them, or are just copy-pasting their way to a finish line they can’t reproduce.
Platforms have the same problem. Too prescriptive and you’ve built another horizontal SaaS. Too open and you’ve recreated the original problem of non-technical users facing infinite decisions.
The trap most platforms fall into is treating this as a single dial — “how much hand-holding?” — when it’s really two separate dials that need to move independently. There’s the initial state dial (what does a blank canvas look like?) and the escape hatch dial (how easily can a user override the defaults once they have an opinion?). Most platforms get one right and the other wrong. Notion famously started with a blank page and a learning curve so steep that an entire YouTube genre grew up around it. Squarespace went the other way — gorgeous defaults, almost impossible to break the grid once you wanted to. Both are valid; neither is the answer for vibe coding, where the user’s goal often is to break the grid eventually.
The pattern I keep coming back to is what I’d call scaffolded defection. Start the user inside a working template — not a blank page, not a wizard — and make the act of customizing feel like a series of small, reversible defections from the default. The first edit should be one word in a header. The tenth edit might be a database schema. The platform’s job is to make sure step ten doesn’t require understanding everything between steps one and nine. The workshops that work for me are the ones where participants leave with something that runs and that they could, in principle, take apart later — not the ones where they leave with something they built from scratch and can’t explain to themselves a week later.
The deeper question is whether your platform is teaching a skill or hiding one. Both are legitimate businesses. But you should know which one you are, because the configuration choices flow from there.
Who do you partner with, and who gets left out — build, buy, or punt?
Vibe coding platforms are constantly making build-vs-buy calls. The companies that win partnerships will be the ones with clean API documentation and MCP servers, investing in a modern, agent-friendly tool stack.
The interesting wrinkle is that “agent-friendly” is becoming a real product category, not just a marketing claim. An API designed for a human developer to read once and integrate over a sprint looks very different from an API designed for an LLM to read fresh on every call. The former tolerates ambiguity, optional parameters, and “see the docs for more”; the latter punishes all of it. Stripe’s API was famously legible because it was written for human developers under cognitive load. The next generation of legible APIs will be written for agents under context-window pressure, which is a stricter constraint.
Agent-friendly examples
A small feature I love on modern developer docs is the “copy as markdown” button, offering a one-click way to paste docs directly into an LLM that’s coding on your behalf. Stack Auth and Stripe both do this well. If you sell to developers in 2026, this should be table stakes.
What does pricing look like in a world where everyone can build?
The old model was free for personal apps, paid for professional apps. That breaks down when a “personal” app might serve fifty people in a tight-knit community. The pricing model that wins is going to look more like usage-based metering than seat-based SaaS, but I haven’t seen anyone nail this yet.
The fundamental issue is that the unit of value has shifted. Seats made sense when software was a tool a person used. They make less sense when software is a small program a person deploys to do work on their behalf: sometimes for themselves, sometimes for a group, sometimes for an audience that never logs in at all. A wedding planner who builds a client intake form that 200 couples fill out a year isn’t a 200-seat customer; she’s a one-seat customer with 200 anonymous beneficiaries. Charging her per seat is absurd. Charging her per submission feels closer, but punishes her for success in a way that subscriptions don’t.
The pricing models I find most interesting are the ones experimenting with tiered usage with soft ceilings: a generous floor for personal use, metered overage for anything past it, and a separate (much higher) tier the moment the app starts generating revenue or handling regulated data.
The biggest gaps nobody's filled yet
Better non-technical onboarding is the highest-leverage gap. Vibe coding apps should be asking users questions up front that flow into the infrastructure and security layers:
How many users do you expect to visit this product?
Do they all need the same level of visibility?
Who is allowed to see what?
Does your application handle sensitive data?
And a few specific product opportunities nobody has nailed yet:
A non-technical terminal. Nearly every vibe coding platform is UI-and-frontend-heavy by design. This is a great onboarding strategy and a terrible teaching strategy. Concepts like deployment, branches, environment variables, and the command line don’t go away when you hide them — they reappear the moment something breaks. I’d love to see a “terminal for the rest of us” that explains why you’re typing what you’re typing instead of abstracting it away entirely. Docker’s recent MCP catalog hints at this kind of layer, but for AI infrastructure specifically.
Multi-tenancy as a service. Plug-and-play identity, permissions, and data isolation for small groups. Not enterprise-scale IAM, not single-user assumptions. The actual constraints of an app serving twenty to two hundred people. Onboarding should ask about types of data, types of users, and the permissions each level of user needs.
Natural-language database design with safety rails. Letting non-technical builders specify data models in plain English, with the platform handling migrations, consistency, and the inevitable “I need to change this schema after launch” moment.
Operational handoff. The day a vibe-coded app starts making real money is the day its builder needs to think about monitoring, error handling, and uptime. Nobody is building “AWS for non-technical operators” yet, and the gap is widening. I would be interested to see a service line at vibe coding companies where builders could hire experienced engineers to audit applications and/or debug when things go wrong.
What stays, what doesn’t
A few things I think persist across whatever paradigm shift is coming:
GitHub will emerge as a clear winner and never be vanquished. The interface might change, but version control as a concept is too fundamental, and GitHub is too central to integrating with anything on the internet. If anything, the GitHub-shaped layer is going to get more important as more non-technical builders ship code they don’t fully understand.
Product sense stays, and becomes more important than ever. The cheap-prototype era doesn’t reduce the need for product thinking, it amplifies it. When everyone can ship a UI in an afternoon, the differentiator is what you chose to build and why. I’ll write more about this in the next piece.
Companies in the productivity spaces need to invest in strong API documentation and MCP servers. Any personal/professional tooling company would strongly benefit from developing a MCP featureset, unlocking easy integration capabilities for builders who want to automate their workflows. Companies that don’t will quietly get routed around.
What I’m watching next
The most interesting thing about this moment, to me, is that the platforms racing to fill the messy middle are simultaneously racing to define what software is for non-technical builders. Whatever defaults they pick — about data, about pricing, about who gets to be a builder versus a buyer — will shape the next decade of how regular people relate to software.
I still believe in the free range apps thesis. I just think the year ahead is less about whether vibe coding works, and more about who gets to build the boring, essential, deeply underrated infrastructure that turns a prototype into a thing your friend’s bakery can actually run on.
If you’re building in this space, especially on the messy middle problems, I’d love to hear what you’re working on.
The messy middle is exactly where the demo-to-done gap lives. The first screen comes out looking like magic, then you hit the part where Lovable stops carrying you and you have to understand what it actually built. Most people quit there and call vibe coding overrated. It’s not overrated, it’s just front-loaded.