Can I Build a Mobile App Using AI?

We worked on a currency exchange product that let travellers pass their leftover foreign notes to someone else at an agreed rate, skipping the bank and the bureau fees. Partway through the project we found out that the law, and Apple's own App Store rules, wouldn't allow that kind of direct payment between two people. The product had to change shape completely. It became location based and in person, where two users meet up and physically swap the cash.

Code was never the expensive part of an app, deciding what to build always was.

So, can you build an app using AI? Yes, and faster than most people expect. You can describe a screen and get working code back in seconds, and you can have something running on a phone the same afternoon. That part of the job really has changed.

What hasn't changed is everything around it. No model told us about Apple's payment rules, and no prompt tells you whether the thing you're describing is something people actually want. This article covers what AI app development is good at today, where it quietly leaves you exposed, and how we use it on client work without letting it make the decisions that matter.

The Short Answer: What AI Can and Cannot Build

AI writes code quickly and it writes a lot of it. Give it a clear description of a screen, a data model and a set of rules, and you get something that runs. Everything it produces traces back to what you asked for, so the quality of the output is the quality of the brief.

What you get when you build an app using AI

You get working software that does what you said. You don't get a product that knows why it exists. We saw that difference clearly on a genetics wellness app we were asked to audit. The product had been built largely by a developer team, and the storytelling and narrative had been stripped out in favour of shipping the functions. People opened the app, looked at their results and felt nothing much about them, and retention suffered for it.

AI pushes in the same direction, only faster. Ask for a results screen and you get a results screen, numbers laid out neatly, nothing in it that makes a person care. The functional answer arrives in seconds. The question of what somebody should feel when they read their own data never comes up, because nobody asked it.

So the honest answer to "can AI create an app" is yes, it can create the software. Whether that software is a product people keep on their phone is a different question, and it's settled long before any code exists.

Where AI Genuinely Speeds Things Up

The speed gains are real and we use them. Writing boilerplate, wiring up an API, drafting tests, converting a design into a first pass of front-end code, spinning up a throwaway prototype so a client can hold the idea in their hand. All of that used to take days and now takes hours.

Tools like GitHub Copilot and Cursor are said to speed up coding by 40-60% according to Agile Soft Labs, 2026, though that's their own figure rather than independent research, and the same page quotes 25-40% a few paragraphs later, which tells you how soft these numbers are. Read the claim narrowly and it still holds. Coding gets faster.

The useful thing is to see how small a slice of a project coding actually is. These parts don't compress.

• Working out what the product is for and who needs it
• Testing the idea with real people before you build
• Making the hundred small design decisions that give a product a personality
• App store review, legal checks and payment rules
• Fixing what users do that you didn't predict

A faster build phase gets you to those questions sooner. It doesn't answer any of them for you, and on the projects where things go wrong, the build phase was rarely the problem.

The Tools Worth Knowing About

The tools split into a few groups, and picking the wrong group for your situation wastes more time than any of them save. Here's how we think about them.

Low-code and no-code platforms are described as up to 10 times faster than traditional development by Forrester, and the "up to" is doing a fair amount of the carrying there. It's a ceiling, not a promise.

A tool that builds in an afternoon still can't tell you what's worth building.

Our rule of thumb is simple. Use prompt-to-app builders to argue about an idea, then rebuild properly once you know the idea is right. Treat the first version as a conversation piece and you'll get a lot out of it.

What AI Cannot Tell You: Whether Anyone Wants It

We worked on a product aimed at African communities living abroad, designed to help people keep a connection with their home communities. Technically it was viable and fairly straightforward, the sort of thing you can stand up quickly today. We ran a lot of focus groups with the target market, and what came back was that there just wasn't the desire for that kind of product. No amount of build speed fixes that.

This is where the gap between asking people and watching people gets expensive. When users are asked whether they'd use an app, 60-80% say yes, while actual usage often lands at 10-20%, according to AppTweak. AI will happily help you build for the 60-80%.

Before you prompt anything, write down how people meet this need today without your product, and how they feel about doing it that way. If they're reasonably content, you've got a feature in search of a problem.

The research question we start with has barely changed in years. What need does this fill, and how do people feel about the way they're currently filling it? Quick builds make it tempting to skip that and just launch something to see. The trouble is that a launched product with no demand teaches you the same thing a focus group does, only slower and with more money spent.

Deciding What to Leave Out

A property developer came to us wanting a concierge app for their high-rise buildings. They arrived with a budget already set and a clear picture in mind, and what they really wanted was a sign-off rather than a scope. We talked them into a proper discovery phase with focus groups and user workshops first.

What we found was that the product needed to be a lot simpler than they'd imagined. Plenty of the features on their list never got built. The focus moved to creating a human connection with the product rather than replacing a whole load of systems the building already had. They ended up with a better product at a lower cost, which is the opposite of what everyone expects discovery to do.

AI makes this harder, oddly. When each feature costs a prompt and twenty minutes, there's no natural brake on scope. The cost of building something has dropped, so the cost of maintaining it, explaining it and designing around it is what you're actually signing up for, and none of that got cheaper.

A small number of things done really well beats a long list done adequately. One bad experience is usually enough for someone to stop opening your app, and they rarely tell you why. Spend the saved build time on making fewer things feel right.

The Constraints AI Will Not Warn You About

Go back to the currency exchange product. The idea was clean, the technology was straightforward, and the thing that killed the original concept had nothing to do with either. Legal requirements and Apple's rules said no to direct peer-to-peer transfers of that kind, and we found that out partway through the project. So the product became an in-person one, where people meet up and exchange the physical currency, which is a different app with a different reason to exist.

Device capability bites too. On that product for African communities abroad, a second problem sat behind the demand problem. The phones commonly used in several of the key countries at the time were limited, and delivering half of the intended experience on those devices had very little chance of working well.

Things a model won't raise unless you specifically ask:

• App store rules on payments, subscriptions and account deletion
• Regulation in the category you're entering
• What the devices your actual users own are capable of
• Permissions people are willing to grant, and when
• What happens to your data if the model provider changes terms

Find these in week one. They're much cheaper as a constraint than as a surprise.

AI Features Inside Your App: Psychology Before Capability

There's a second version of this question, which is whether to put AI inside the product rather than use it to make the product. Same discipline applies. Taking a feature from a product that works in one situation and dropping it into yours, which works in a different situation, doesn't make it work.

The concierge app is the clearest case we've had of this. Our focus groups found that the sense of community in a building comes from familiarity, people slowly accumulating small personal facts about each other, names, jobs, children, dogs, what someone does at the weekend. The moment those details surface, belonging follows on its own.

Lifting a feature from a product that works in another situation doesn't make it work in yours.

An AI concierge that handles every request without a human in the loop sounds like an upgrade. In that building it removes the exact interactions that make residents feel they live somewhere. So we designed the product to encourage those conversations rather than to replace them with digital self-service.

Ask what emotional state your user is in when the feature fires. Someone anxious wants reassurance and a person. Someone bored wants something to play with. The capability is the easy bit now, and the judgement about whether it belongs is the part worth paying for.

Why Emotional Coherence Breaks First

The genetics wellness app is worth coming back to in full, because it shows what breaks when one part of a product is built without reference to the rest. The brand itself was luxurious and aspirational, in the packaging and everywhere online. Transformation, becoming a better version of yourself, reaching your full potential, all of it well made.

Then you ordered a kit, did the test, waited, and opened the app to find something cold and clinical. Functional copy, functional design, data presented like a lab printout. The journey held together right up to the product touchpoint and then fell apart, and it was a jarring experience for the person who'd bought into the promise.

Our audit found the brand promise was sound. The narrative about getting a real inside look at how your body works, how it's ageing and how you can improve it, was compelling and well built. What had gone was the storytelling inside the product, and the fix was to put the narrative back and give people a sense of identity within the app, rather than touch the brand at all.

Read your marketing copy and your app's empty states side by side. If they sound like two different companies, your users have already noticed.

The Cost of Skipping Discovery on Part of a Product

On a dating app project built around verified profiles and keeping bots out, the client wanted to skip discovery for the messaging side and put everything into the onboarding process. We ran a rigorous onboarding, verification and validation flow, and it worked.

Then the messaging got built generically, because nobody had done the work to say what messaging meant in a product whose entire premise was that the person on the other end is real. It allowed automated messages and fake messages, which is precisely the behaviour the onboarding existed to stop. The two halves of the product contradicted each other.

The whole messaging section had to be rewritten. That came to around £15,000 of extra budget and about two months of extra work, on a decision that was made to save a couple of weeks of discovery at the start.

This matters more now, not less. When part of a product can be generated in an afternoon, the generated part is the part nobody thought hard about, and it sits next to the part you agonised over. Users feel the seam immediately, even if they can't name it. Coherence is a property of the whole thing, so discovery has to cover the whole thing.

Does It Even Need to Be an App?

We worked on a surveying app for performance coaches, where the coach runs a session and wants the room to answer a few questions. The obvious build was a native app for the audience. We recommended against it, because asking a room full of people to visit an app store and download something for one simple touchpoint is a step too far.

What we proposed instead was a QR code. The presenter creates the survey in their native app, a code appears on screen, and anyone scanning it with their phone lands straight on a fully branded, mobile responsive page. It felt like a native app experience with none of the download friction, and a lot more people completed the survey as a result.

Web-first builds launch 30-50% faster than native mobile apps according to Agile Soft Labs, 2026, which is their own estimate rather than independent research, though the direction matches what we see.

Before you build an app using AI, ask what the app gives you that a web page doesn't. Push notifications, camera, offline use, a home screen icon people genuinely want. If the honest answer is none of those, you're adding a download step for nothing.

Who Makes the Decisions When the Build Gets Cheap

We worked on a fitness and wellness product with two co-founders who were new to app development. We'd get sign-off on a design, start building, and then they'd walk the approval back, saying they hadn't understood that was what was actually going to get built. There was no real consensus between the two of them, and approval seemed to come out of politeness rather than decision.

We kept warning them that budget was going on design iterations with no material impact on the product. That fell on deaf ears, and the project never got past design and research, because the money ran out first.

Cheap builds make it easier to keep changing your mind, and indecision was always the expensive part.

We had a similar lesson from a sports club app, where resisting iterative delivery and wanting everything launched at once put the whole thing at risk of never launching. Working with the process, and listening to the people who do this for a living, is what gets products out of the door.

Faster tools don't fix an unclear decision-maker. They just let you build more versions of an argument nobody has settled.

A Sensible Way to Use AI in Your Next App Project

None of this is an argument against the tools. We use them daily and they've changed how quickly we can show a client a real thing. The order of operations is what keeps you out of trouble.

1. Write down the need the product fills, and how people meet that need today without it.
2. Find out how they feel about the current way. Content people don't adopt new products.
3. Check the hard constraints early, which means platform rules, regulation, payments and the devices your users actually own.
4. Decide who signs off, and get both founders in the same room before any design starts.
5. Use AI to build the smallest honest version of the product, and put it in front of real users.
6. Spend what you saved on the parts people feel, which is the copy, the pacing, the moments where someone sees their own information.

Give AI the brief you'd give a good contractor, including the emotional intent, not just the functional spec. "A results screen" and "a results screen that makes someone feel capable rather than judged" produce very different first drafts.

Done in that order, AI app development takes weeks out of the build and puts them back into the thinking. Done in reverse, it gets you to the wrong product faster than you've ever got there before.

Conclusion

You can build an app using AI, and the gap between an idea and something running on a phone has genuinely closed. What that speed exposes is how much of a product was never a coding problem. Apple's payment rules reshaped the currency exchange product. Focus groups ended the product for African communities abroad before a line of it existed. Discovery made the concierge app simpler and cheaper, and skipping it on the dating app's messaging cost £15,000 and two months.

Every one of those decisions sat upstream of the build, and every one of them still sits there now. The tools have made the easy part easier, which leaves the hard part looking much larger than it used to.

So use them. Prototype faster, test more ideas, throw more away. Then spend the time you've saved on the questions a model can't answer, which are what people need, how they feel about getting it today, and what the product should make them feel when it works.

If you're weighing up an app idea and want a straight view on whether it's worth building, and what it should be, let's talk about your app idea.

Frequently Asked Questions