Can You Actually Build Your Own Apps Using AI?

An accountant I know spent a Sunday building a workout tracker. He typed what he wanted into a chat box, got a working app back, changed two things, and used it at the gym on Monday. He has never written code. His question afterwards was obvious. If that took four hours, what else could he build?

The answer turns on a line running through every software project. It needs a name, because most arguments about AI coding tools fall apart without one. Call it the demo boundary. On one side sits an app that runs: it opens, it does the thing, it looks fine on a phone. On the other side sits an app that can safely hold something belonging to somebody else. Their money. Their medical history. Their password. Reaching the first side is genuinely easy now. Reaching the second side is about as hard as it has always been.

Go far past that boundary and you land in categories where the engineering effectively is the product. Real money gaming is the clearest example. Shuffle is a crypto casino and online gaming platform, and its category page for online roulette for real money is the customer-facing surface of a stack that does several unglamorous things at once: prove that its random number generation behaves as it claims, hold customer balances without losing track of them, verify who people are, and move deposits and withdrawals on-chain in coins and stablecoins, where every mistake is public and permanent.

The visible part of that is a wheel and a betting grid. A capable model could produce a convincing version before dinner. Everything deciding whether the product is trustworthy sits underneath, engineered by people who can be held responsible rather than generated by a tool that cannot be. That is the demo boundary in its most extreme form, and it explains what these builders are actually good at.

The growth numbers are real

Lovable is the one people point to. It reported about US$17M in annual recurring revenue and roughly 30,000 paying customers in February 2025. By around July 2025 that had become about US$100M ARR with roughly 45 employees, around 2.3 million active users and 180,000 paying subscribers. It reported US$200M ARR in November 2025 and about US$500M annualised by mid-2026, with 146 full-time staff in February 2026. Replit reported more than 40 million users as of Q4 2025 and more than 50 million by March 2026. Vercel says more than 4 million people have used v0 since it became generally available in 2024.

Those are not vanity charts. Millions of people are making software who never could before. But revenue does not say how many of those apps ever left the tab they were born in. Keeping a subscription is a lower bar than shipping something other people depend on.

The first afternoon is the easy part

You describe an idea, you get a screen, you ask for a change, you get the change. The loop is fast and it flatters you. For a personal tool that loop is the entire job: expense splitters, a dashboard pulling two spreadsheets together, a tiny game for your kids.

Then you add a second user, and the questions change character. Who is allowed to see this row? What happens when two people edit at once? If the database falls over on a Friday night, who notices? None of those are typing problems. They are judgement problems, and a model answers them confidently whether or not it answers them correctly.

Vibe coding got a name for a reason

Building software by describing it rather than writing it goes by vibe coding, and the name stuck because it is honest. You steer on feel. You accept code you have not read.

Vercel, which builds one of these tools, has been blunt about where that leads. It calls vibe coding the world’s largest shadow IT problem, and names the failures it has watched happen: credentials pasted straight into prompts, company data published to the open internet, databases deleted through misuse of AI-generated code. Every one of those is a person who got a working app and assumed working meant finished.

What you should not build this way

Anything sitting past the demo boundary. Payroll. A patient record. A payments flow. Anything where losing the data hurts more than losing the app.

Apply the roulette version of the test. A real money wheel has to prove its random number generation, its balances and its withdrawals to an auditor before anyone plays. Your app meets a smaller version of that question the moment somebody else relies on it, and generated code will not answer it for you.

Real money gambling belongs firmly in that group, for reasons beyond the code. Those products are RNG-driven with a house edge built into the maths, and no clever system removes it. The obligations, proving fairness, keeping funds safe, checking age and identity, come from regulators and auditors rather than good intentions. If you play at all, treat it as paid entertainment, keep it to 18+ and set your limit before you start.

The failure pattern is always the same: the demo looks finished, so the risk feels handled, so nobody asks what breaks.

Where it genuinely shines

Prototypes you intend to throw away. Internal tools with five users who sit near you. The version of an idea you build to see whether you still want it in a fortnight. Learning, too: generate something, then read it line by line and ask why each piece is there.

The same curiosity that sends people hunting for advanced iPhone techniques is what makes these tools worth having. You are not trying to become a software company. You are trying to make the machine do what you want.

So, can you?

Yes, and no, and the split is not a dodge.

Yes, you can build something that works, quickly, with no background, and that was not true three years ago. No, you cannot yet safely operate it for other people without knowing what auth, data handling and payments demand of you. The gap is not typing speed. It is knowing what you do not know, and a model cannot hand you that, because it does not know what you are missing either.

My accountant friend still uses his workout tracker. He dropped the client billing tool he was considering, once he thought about where the invoices would live. He made that call himself, and it was the right one.