How to Build a Working Mobile App With AI and No Code

A team just rebuilt a photo cleaning app that reportedly earns millions a month, and they did it on a phone and an iPad in about an hour without ever opening a code editor. That is the headline everyone repeated this week. It is also the least interesting part of the story, and I want to argue the opposite of what most people took away from it.

The popular reading is that anyone can now get rich building apps because the code writes itself. I think that reading is not just wrong, it is backwards. The code was never the reason most small businesses failed to build software. Making the code cheap does not hand you a business. It hands you a faster way to build the wrong thing. I am Madhuranjan Kumar, and after watching a lot of these no code builds and doing plenty of my own, I have come to a blunt conclusion: the AI removed the one skill that was never your bottleneck, and left every hard part exactly where it was.

The build was always the easy 20 percent

Look closely at what actually happened in that build. A person typed a plain English request, an AI coding agent studied a reference app, and within minutes there was a working screen that loaded photos, scanned for duplicates, and let you swipe to delete. Impressive. But notice what the human was really doing the whole time. They were deciding what the app should do, judging whether each result was good enough, catching bugs, and choosing what to fix next. The AI wrote the syntax. The human supplied every ounce of judgment.

That split matters because in the old world, the syntax was maybe 20 percent of the effort and 100 percent of the gatekeeping. You could have a perfect idea and still be locked out because you could not write Swift. So the syntax felt like the whole mountain. Now the syntax is a footpath, and everyone is celebrating the footpath while the actual mountain, knowing what to build and getting people to use it, is untouched. The barrier did not disappear. It moved to a place that is harder to see and much harder to fake.

The one hour app is real, and it proves my point

I am not disputing that the app got built fast. It did. The team hit exactly one real error the entire time, on a swipe to delete view, and they fixed it by pasting the error message straight back to the agent, which patched itself. They generated an app icon and a splash screen from a single image prompt. They stood up a simple landing page with terms and privacy links. From the outside it looks like software fell out of the sky.

But run the tape again and count the decisions. They learned that stacking three edits into one prompt confused the agent, so they switched to one focused change at a time. They learned to prove the core feature worked before touching design, because once the function is solid you can just say keep everything working and make it look like this. They learned that as the agent's memory filled up it would break working features while fixing others, so they had to set hard boundaries, telling it you are only changing this one screen, do not touch anything else. Every one of those lessons is a judgment call about how to manage a tool that does not understand your intent. The speed did not come from the AI being smart. It came from a human who already knew how software should behave steering a fast but clueless assistant. Hand the same tool to someone with no product instinct and you get a fast pile of confident nonsense.

The bottleneck moved, it did not vanish

Here is the contrarian core of my argument. The industry keeps announcing that technical skill is dead. What actually died is the specific chore of typing code. What replaced it as the binding constraint is a cluster of skills nobody wants to admit is hard: writing a crisp specification, testing honestly, recognizing when an output is subtly wrong, and knowing which feature is worth building at all.

Watch how the winners of this build behaved. They tested after every single prompt, refreshed, clicked through, and wrote down every bug in plain language before fixing anything. That discipline is the entire game now. The person who treats the AI's first output as finished ships garbage. The person who treats it as a rough draft to be interrogated ships something real. That is not a coding skill. It is a quality of attention, and it is rarer than the ability to write a for loop ever was.

This is also why I get uneasy when someone says they will build their whole company on a weekend vibe coding session. Speed with no judgment is not an asset, it is a liability with a fast deploy button. The faster you can ship, the faster you can ship a data leak, a broken checkout, or a feature no customer wanted.

Where the no code dream quietly breaks

The demo ends when the app runs on the builder's own device. The business begins after that, and that is precisely where the free ride stops. Shipping to a real app store has its own checklist that no prompt makes disappear: permission strings, a build pipeline, review that can bounce you for reasons the agent never mentioned. Plan an extra day minimum, and that is the optimistic case.

Then comes the part the one hour framing ignores entirely. An app with no users is not a business, it is a hobby with an icon. Getting installs means promotion, and that is where the real money and the real skill live. A polished app still needs someone running Facebook and Instagram ad campaigns to put it in front of the right people, and it needs the intent traffic you only get from ranking in Google Ads and SEO and organic search when someone types the exact problem your app solves. The leads and sign ups those channels produce have to land somewhere they get followed up, which means a CRM and website stack sitting behind the pretty screen. None of that got built in the hour. None of it can be. The AI compressed the cheapest part of the journey and left the expensive parts, distribution and retention, sitting exactly where they always were.

A worked example: the studio that almost built the wrong app

Let me make this concrete with the studio the original write up imagined, because it perfectly illustrates the trap. A photography studio delivers hundreds of images after a wedding and clients struggle to pick favorites. The obvious move, the one the AI makes trivially easy, is to build a swipe to keep app so clients cull their own photos. Swipe right to keep, swipe left to skip, land on a clean shortlist. You could build it in an afternoon.

But here is the contrarian catch. Building it is not the decision. Should you build it at all is the decision, and the AI cannot make it for you. Say the studio shoots roughly 40 weddings a year and each client currently costs the studio about 90 minutes of back and forth email to finalize selects. The app might cut that to 15 minutes per client. That is real: call it 40 clients times 75 minutes saved, around 50 hours a year back. Worth an afternoon of building. But now weigh the parts the demo never mentions. Will clients actually install a native app just to pick photos, or will they resent the friction and email you anyway. If installs are the wall, the smarter build was a link in the browser, not an app store submission. That single judgment, made before a line of code exists, determines whether the 50 hours are saved or wasted.

So the way I would run it for the studio is judgment first, code second. Build the core swipe on real images and confirm clients will actually use it before adding any styling. Generate the icon in the studio colors and the splash screen once the function is proven. Set hard boundaries so the agent does not rework what already works. But the first hour of thinking, deciding whether an app is even the right shape for the problem, is worth more than the whole afternoon of building, and it is the one hour the AI gives you no help with at all. The illustrative culling numbers only turn positive if that upfront call was right.

The skills that actually decide who wins now

If the code is cheap and the judgment is dear, then the smart response is to invest in the judgment, and that is a different curriculum than learning to code ever was. The person who gets value out of these tools is the one who can write a specification a stranger could follow, because the AI is effectively a very fast stranger with no context about your business. Vagueness in equals vagueness out. When the team in the original build learned to give one focused instruction at a time and to state clearly what the agent must not change, they were not learning to code. They were learning to communicate intent with a precision most people never practice, and that precision is now the scarce resource.

The second skill is honest testing, which sounds trivial and is not. The instinct with a slick AI output is relief and acceptance, because it looks finished. The discipline is to distrust it, to click through every path, to try the input that breaks things, and to treat the first result as a hypothesis rather than a verdict. In the build, the only real error surfaced on the swipe to delete view precisely because they were testing after every change instead of at the end. Bugs found in the moment cost seconds. Bugs found by a customer after launch cost trust. That gap is entirely a function of whether the human bothered to look, and looking closely is a habit, not a feature you can prompt for.

The third skill is taste, the sense of which feature actually matters and which polish is worth keeping. When an agent adds something you did not ask for, you have to judge whether it is noise or the missing piece. Nothing in the model supplies that judgment. It comes from knowing your customer and your problem, and it is exactly the thing a small business owner tends to have in abundance and a generic AI has none of. That asymmetry is the good news hiding under all my skepticism.

The uncomfortable takeaway

So here is my position, stated plainly. The no code app revolution is real, and it is smaller than it sounds, because it solved a problem that was never the reason businesses lacked software. It made typing code cheap. It did not make good judgment cheap, it did not make distribution cheap, and it did not make knowing what to build cheap. If anything it raised the value of those skills, because now the only thing separating a working app from a pile of confident nonsense is the human deciding what is worth building and whether the output is actually good.

That is genuinely good news for a small business owner, but not for the reason the hype suggests. You should absolutely try this, because a first working version is now an afternoon of your own time instead of a five figure quote and a three month wait. You can validate whether customers even want the tool before spending real money. Just do not confuse a fast build with a finished business. The app is the easy part. It was always the easy part. The hard parts, the ones that decide whether anyone ever uses the thing, are still yours, and pretending the AI handled them is the fastest way to ship something beautiful that nobody opens. If you would rather have someone scope the idea honestly, tell you when an app is the wrong answer, and build and ship the right thing the first time, you can do it yourself or bring in an expert to do it with you.