A client called me two months ago, thrilled. He had spent one Saturday afternoon typing into an AI tool, describing the online store he wanted for his specialty coffee business. By dinner, he had a working app. Product pages, a shopping cart, a checkout button. He sent me a link and said, "I think I just saved myself ten thousand dollars."

Three weeks later he called again, less thrilled. The checkout button looked real, but it wasn't actually charging real credit cards the way he needed. Sales tax was wrong for out-of-state orders. His accounting software had no idea any of this existed. He needed someone to go in and rebuild the parts that mattered before he could take a single real payment.

I hear a version of this story often enough that I want to walk through it honestly. Tools like Bolt, Replit, and v0 let you describe an app in plain English and watch it get built in front of you. That is genuinely impressive, and it is not a scam or a trick. But it is also not magic. These tools have a real, useful job. The trick is knowing which job that is, and which job it isn't.

What These Tools Are Genuinely Great At

Let's start with the good news, because there is a lot of it.

If you want to test whether an idea makes sense before you spend real money, these tools are excellent. You can describe a booking form, a simple dashboard, or a customer intake page, and watch it appear in minutes instead of weeks. That speed used to be impossible without hiring someone first.

They're also strong for internal tools nobody outside your company will ever touch. Think of a quick spreadsheet-replacement app for tracking shift swaps, or a simple form your team uses to log equipment repairs. Low stakes, small number of users, nothing sensitive on the line if something breaks.

And they're genuinely useful for pitches and demos. If you're raising money or trying to get buy-in from a business partner, showing something clickable beats showing a slide deck every time.

The common thread: fast feedback, low risk, small scope. That's the sweet spot.

Where They Hit Real Limits

The trouble starts when the app has to do something that matters.

Real business logic is messier than it looks from the outside. A coffee subscription needs to handle a customer who pauses their plan mid-cycle, then wants a refund for the week they missed, then changes their shipping address on the same day. Each of those small cases needs a decision, and an AI tool can only follow the rules you actually spell out, in advance, which almost nobody spells out completely.

Connecting to the outside world is another sticking point. Real payment processing, real accounting software, a real shipping carrier — these all involve secure connections between systems, called integrations. Getting two systems to talk to each other reliably, and to keep talking after one of them updates, is a skill in itself.

Security is the part that worries me most, because it stays invisible until it isn't. A 2025 industry report from Veracode, a company that tests code for security flaws, studied AI-generated code from more than a hundred different AI models and found that close to half of it contained at least one exploitable weakness. That doesn't mean the app looks broken. It runs fine. The problem shows up later, when someone finds a door you didn't know was unlocked — often a way to see other customers' orders, or to skip payment entirely.

Finally, there's the question of what happens a year from now. Apps built entirely through back-and-forth conversation with an AI tool tend to pile up small, undocumented decisions nobody wrote down anywhere. When you want to add a feature later, or hire someone to take over the project, that person has to reverse-engineer why things were built the way they were. That costs time and money, often more than building it right the first time would have.

Using AI Tools and a Developer Together

Here's the version of this I actually recommend to most clients: use the AI tool to prove the idea, then bring in a developer to build the version that has to survive contact with real customers and real money.

That's not me protecting my own job. It's the same reason an architect still draws blueprints even though 3D modeling software can generate a pretty rendering in an hour. The rendering tells you whether the idea feels right. It doesn't tell you whether the roof will hold up in a storm.

In practice, this often looks like: you build the prototype yourself over a weekend, show it to a handful of real customers, and see if anyone actually wants what you built. If the answer is yes, a developer takes what you learned — not necessarily the code itself — and builds the real version, with proper security, the integrations you actually need, and a structure someone else could maintain after you.

This does not mean throwing away the weekend you spent on the prototype. Quite the opposite. That prototype already answered the hardest question, which is whether anyone wants this at all. A developer who joins at that point isn't starting from zero. They are starting from a validated idea, which is a much better place to begin a real project than a blank page.

This is a different conversation than the one about no-code platforms, which I've written about separately — those are drag-and-drop tools, not AI-generated ones, and they run into different walls. It's also different from the question of whether a developer using AI assistance can be trusted, which I cover in a separate piece. This article is about a newer promise: skip the developer entirely and let AI build the whole thing. For a real, ongoing business, I haven't seen that promise hold up yet.

Questions Worth Asking Yourself First

Before you commit to one path or the other, sit with a few honest questions:

  • Will this app ever touch real money, real customer data, or a system I already rely on, like accounting or inventory?
  • If this app went down for a day, or leaked customer information, what would that actually cost me?
  • Am I trying to learn something fast, or am I trying to launch something real?
  • Do I have someone who understands what "secure" actually means for this kind of app, or am I taking the tool's word for it?
  • Two years from now, will someone else need to understand and change this, and will they be able to?

If most of your answers point toward "this is just a test," an AI tool is a genuinely great place to start. If they point toward "this is going to run part of my business," treat the AI-built version as a sketch, not a finished building.

Either way, you don't have to figure this out alone. Let's talk through your situation.