In early 2025, Andrej Karpathy, one of the people who helped build the technology behind modern AI, posted something that changed the conversation. He called it vibe coding. The idea: describe what you want an app to do, let the AI write the code, and steer the outcome from there. You do not need to understand the code. You just need to know what you want.
For anyone who has ever had a clear idea for a business tool but no way to build it, that landed hard. Suddenly the gap between having an idea and having working software felt smaller than it had ever been.
And if you have been thinking about building something, a job tracker, a client portal, an internal tool that replaces the spreadsheet nobody trusts anymore, you have almost certainly wondered whether you could just do it yourself. Spend a few evenings with one of these tools, describe what you need, and have something usable by the end of the week.
This article is about what actually happens when you try. Not the demo version. Not the fifteen-minute tutorial where someone builds a to-do list and makes it look effortless. The real thing. A real business app, with real data, for real people who need it to work every single time.
What vibe coding actually is
The tools that make vibe coding possible, Cursor, Bolt, Lovable, Replit, GitHub Copilot, Claude, have become genuinely impressive. You describe what you want in plain English, and they produce working code. Not perfect code. Not finished code. But real, functional code faster than you could write it yourself even if you knew how.
For the right kind of project, this is extraordinary. A personal script. A throwaway prototype. Something to test an idea before committing real time to it. The technology is not a gimmick. It is a legitimate shift in how software gets made.
The question is not whether these tools work. They do. The question is whether they work for building a reliable business app, something your team depends on, something real data lives in, something that needs to keep working on a Tuesday morning six months from now when you are not watching it.
That is a different question, and the answer is more complicated.
Step one: picking a tool. Which is harder than it sounds.
The first thing most guides skip is that there is no single vibe coding tool. There is an ecosystem of them, each with different strengths, different interfaces, different pricing, and different limits on what they will help you build before they ask for money.
Cursor is a code editor with AI built in, meaning you still need to understand where files go and how to run a project. Bolt and Lovable try to abstract that away with a browser-based interface. Replit is closer to a full environment. Claude and ChatGPT can write excellent code but will not deploy anything for you. Each one is genuinely good at something slightly different.
Before you have written a single prompt describing your app, you are already making decisions that will shape everything that comes after. Which tool fits the kind of app you are building? What is the free tier, and what happens when you hit its limit mid-build? Some of these tools charge by usage, meaning the larger and more complex your project becomes, the more each conversation costs. Others have monthly plans with hard caps on how much the AI will generate before you need to pay more.
Most people do what makes sense: pick one, sign up, and start. That is fine. But it is the beginning of a much longer relationship than the homepage suggested.
The first session. This is genuinely exciting.
The first hour of vibe coding a real business app is one of the more remarkable experiences available to a non-technical person right now. You describe the app. A job tracker for a trades business, for example, a real thing real businesses need. Within minutes you have something on the screen. A table. Rows. An add button. Status fields. It looks like software. It behaves like software.
This is not a trick. The AI is genuinely good at this. It can take a plain English description and produce working code faster than most professional developers you have ever watched.
You make a few changes. The columns update. You ask for a different colour scheme. It adjusts. You ask it to add a notes field per job. It does it. You show someone else and they are impressed. You are impressed.
The problem is not the first session. The first session is almost always good.
Iterations one through five: this is working
The early refinements go smoothly. You are having a conversation with a very capable assistant who seems to understand exactly what you mean. You ask, it delivers. The gap between what you described and what appeared on screen is small enough to bridge with one more prompt.
At this stage, the experience matches the promise. You are building something real. You are not a developer, but you are producing software. That feeling is genuine and it is worth acknowledging before describing what comes next.
That part above is not spin. The first few sessions really are good, and I wanted to say that before we get into what tends to happen next.
I did not write this to steer you toward Merebase. I wrote it because I have watched business owners spend weeks in this loop and come out the other side with something that half-works and a maintenance problem they were not expecting. If vibe coding gets you where you need to go, use it. But if what you are building is something your team depends on every day, it is worth having the full picture before you start, not after thirty-five iterations.
Iterations ten through twenty: the drift begins
Around here, something starts happening that nobody warns you about properly.
Large language models are non-deterministic. That is the technical term for something you are about to experience in very plain terms: the same instruction does not always produce the same result twice. And more importantly, a new instruction does not simply add to what already exists. The model re-evaluates the entire context of the conversation each time it responds, and it rewrites based on that full picture.
So when you ask the AI to change how the status field works, it might change the status field. Or it might change the status field and subtly adjust three other things in the process, because the model re-evaluated the whole component and made decisions that seemed logical to it based on everything you have asked for so far.
Not maliciously. Not even incorrectly, by its own internal logic. Just differently from what was working before.
"You might not notice immediately. The app still looks right. But something that was working is now broken and you do not have the code knowledge to go find it."
So you ask it to fix the new problem. Which it does. And in doing so it may introduce something else. You are, at this point, not building an app in any traditional sense. You are managing a conversation with a system that is trying its best but has no reliable memory of what the intended final state was supposed to look like. It does not hold a picture of your app in mind the way a developer would. It responds to what you just said, informed by everything said before, and that is a fundamentally different thing.
Iterations twenty through forty: the pivot problem
You have spent three evenings on this. The core functionality works well enough. Now you need to add user logins. Different staff members need to see different jobs, and you do not want everyone having full access to everything.
This seems like a small addition. It is not.
Authentication is one of the hardest things to add to an existing vibe coded app, not because the AI cannot write authentication code (it can), but because adding it properly means restructuring how the entire data model works. Every piece of data now needs to be tied to a user. Every screen needs to know who is looking at it. Every query needs to filter accordingly.
The AI will give you something. It may work on the surface. But it may also have security problems you do not have the background to evaluate. Are passwords stored correctly? Is session handling safe? Are there ways for one user to see another user's data through a URL parameter someone guessed? These are not hypothetical concerns. They are the kinds of things that end up in data breach reports. The AI will not fail visibly on them. They will just be wrong in ways you will not discover until something goes badly.
This is the moment in the journey where most people either push through into territory they do not fully understand, or they stop and start counting the hours they have spent.
A business owner described it well: "I kept asking it to fix things and every time it fixed one thing, something else shifted. By iteration 35 I had an app that was about 70% right and I genuinely could not tell what was causing the 30% that was broken. I asked the AI and it gave me a confident answer that turned out to be wrong."
This is not a failure of the tool. It is the nature of how these systems work. Understanding that before you start saves a significant amount of frustration.
Now you have to deploy it. To where, exactly?
Assume the app works. Assume you are happy with it. Now where does it live?
This is a separate problem, and it is one most vibe coding guides treat as a footnote. It is not a footnote. It is the difference between having code and having an app your team can actually open on Monday morning.
Some AI coding tools will host the app for you, on their platform, on their terms, at their pricing. This solves the immediate problem. It also means your business is now dependent on that platform's decisions about pricing, availability, and continuity. If they raise prices, you pay more. If they discontinue the product (and many tools in this space have short track records) your app may stop working. If their servers go down, your team cannot work.
If you want to host it yourself, on your own domain, with your own data, with real control over what happens to it, you are now learning about servers, environment variables, database configuration, SSL certificates, deployment pipelines, and the particular quirks of whichever hosting provider you chose. None of these things are impossible. Each one has documentation. But together, at the end of a forty-iteration build, they form a wall that a significant number of people do not get over.
And even once it is deployed: who maintains it? When a bug appears, and bugs appear in every piece of software, what is the process? You go back to the AI tool with a description of what is broken. You start another conversation. You iterate again. You hope the fix does not introduce new drift.
This is the part of the ongoing cost that is hardest to estimate before you start.
The honest time count
Here is the number that most vibe coding content avoids.
A realistic first build of a simple business app, something with a few screens, a database, user access, and a working deployment, takes most first-time builders somewhere between fifteen and forty hours of actual time. That is not a criticism of the tools. It is genuinely faster than learning to code from scratch. But it is also not a weekend afternoon.
Fifteen hours is the optimistic case: you had a clear idea, the AI understood it, the iterations went smoothly, and deployment was straightforward. Forty hours is the realistic case for most business apps with any complexity: there was drift, there were broken things, deployment took two evenings, and there were a handful of dead ends you had to reverse out of.
| Your hourly rate | 15 hours | 25 hours | 40 hours |
|---|---|---|---|
| $20/hr | $300 | $500 | $800 |
| $30/hr | $450 | $750 | $1,200 |
| $40/hr | $600 | $1,000 | $1,600 |
| $60/hr | $900 | $1,500 | $2,400 |
This is not a gotcha. It is a genuine calculation worth doing before you start. If vibe coding this app yourself costs you twenty hours and your time is worth $30 an hour, you have spent $600 in real terms, and you still have an app that may need ongoing attention every time something breaks or needs to change.
There are situations where that trade makes complete sense. There are situations where it does not.
When vibe coding is genuinely the right call
This matters, so it is worth being direct about it: vibe coding is excellent for certain things and we would not suggest otherwise.
Personal tools only you use. If something breaks, only you are affected. You can take your time fixing it. The stakes are low.
Throwaway prototypes. You have an idea and you want to see if it is worth pursuing before committing real time or money. Vibe coding a rough version to test the concept is a smart use of the technology.
Learning. If you want to develop intuition for how software works, how data is structured, how logic flows, how interfaces connect to databases, building something imperfect through vibe coding is a legitimate way to do that. The experience has real value.
Low-stakes internal experiments. Something your team uses occasionally, where downtime is a minor inconvenience rather than a business problem.
In all of these situations: go for it. The tools are impressive and getting better every month. The ceiling is rising.
When it is not the right call
If the app is for your team, and people depend on it to do their jobs, that is a different situation.
If real data lives in it, customer records, job information, financial figures, anything that cannot be lost or corrupted, that changes the equation.
If it needs to work reliably, every time, including Tuesday mornings when you are not watching it, that is a production requirement, and production requirements have costs that vibe coding does not make disappear.
If you are replacing something that currently runs your business, a spreadsheet that has become load-bearing, a legacy tool that everyone hates but everyone uses, the migration and reliability requirements are real and they do not get simpler just because the build was AI-assisted.
None of this means you cannot vibe code a business app. Some people do it successfully. But those people typically have some technical background, significant patience, and time they are genuinely willing to spend on it. For most business owners, the honest question is not whether you are capable of doing it. It is whether that is the best use of your time, relative to what you are actually trying to accomplish.
What if you ever need a second app?
Here is something worth thinking about before you start, even if you are only building one app right now.
Most vibe coded apps are islands. They have their own database, their own data structure, their own logic for how things are stored and related to each other. Nobody designed any of that with the future in mind because the AI did not ask about it. It just built what you described, in whatever way made sense at the time.
That is fine if you only ever need one app. But most businesses that solve one problem with software eventually find a second problem worth solving. A job tracker leads to a client portal. An inventory tool leads to a reporting view. A booking system leads to a staff schedule. The pattern is consistent: software that works tends to reveal the next thing that needs to work.
In a vibe coded environment, that second app is a completely new project. It starts from scratch. It has its own separate database with its own separate tables, built with no knowledge of the first app. If you want data from app one to appear in app two, you are asking the AI to solve an integration problem between two systems it built independently, at different times, with no shared design. In practice, most people find this either extremely difficult or simply impossible without professional help.
When an app is built properly, on a considered data foundation, the second app is not starting over. It is extending what already exists. The core tables are already there. The relationships between your data are already defined. The second app reads from the same foundation, adds what it needs, and connects naturally to the first. Over time, you are not managing a collection of isolated tools that cannot talk to each other. You are building something that compounds.
You still own all of it. The code, the data, the structure. That does not change. The difference is that what you own was designed to grow, not just to work once.
The problem that starts before the first prompt
Most custom software fails before anyone writes a line of code.
Someone describes what they need. Someone else interprets it. Those two things are never quite the same. What gets built is close. Close is expensive. You don't find out how close until it's done.
Vibe coding doesn't solve this. It removes the moment where the gap could have been caught. You describe something. Something gets built immediately. You discover what was misunderstood by using it. Each session fixes the last misread. The speed that felt like an advantage becomes the thing that compounds the problem.
A build architect's entire job is that gap.
They work with you until the scope says exactly what you mean. Not what's easiest to build. Not a reasonable interpretation. The actual thing. You read it. You approve it. Nothing gets built and no money changes hands until you do.
That is not a slow-down. It is the only part of the process that guarantees what you described is what you get.
What getting it built properly looks like
There is a version of this where you describe what you need in plain language, the same way you would prompt an AI tool, and a person who does this every day reads it, comes back to you with a clear scope showing exactly what you will get, and builds it in days.
No iteration hell. No deployment evening. No question of where the data lives or who maintains it. No platform you are dependent on. The code is yours. The hosting is yours. If something needs to change later, you have someone to contact and a process for how that works.
That is what Merebase does. One app, one job, A$499. The scope is agreed in writing before anything is built and before any money changes hands. If it does not match the scope, it gets fixed. Two rounds of revision are included.
The comparison is not really vibe coding versus Merebase. It is your time versus someone else's. If you would spend twenty hours building something that half-works, and your time is worth $30 an hour, you have already spent more than the alternative costs, and you still have a maintenance problem.
If you enjoy the process, if you want to learn, if the stakes are low, vibe code it. It is worth experiencing.
If you need it to work, and you need it to keep working, the most efficient path is probably a shorter one.