How to Create an App with AI: Steps, Tools, Costs and Limitations

How to create an app with AI at a glance

Seven steps take you from idea to published app. AI speeds up most of them, but it doesn't replace testing and store review.

The four ways to create an app with AI, compared

The approaches differ less in how fast they generate something than in what you end up owning, hosting, publishing and maintaining.

"AI app builder" is used for very different tools. We compared four approaches on the criteria that decide what you end up with. The table below describes each approach in general; tools within the same category differ, so the second table lists what specific tools document about themselves.

What specific tools document about themselves

Official source Each row summarizes the tool's own website or documentation, checked on October 9, 2026. These products change quickly, so follow the link for the current state.

Our assessment If the goal is to validate an idea quickly, a prompt-to-app generator is usually the fastest route. If the goal is an app in the stores that a non-technical team will update every week, the deciding questions are who builds and submits the store versions, who maintains the back end, and how content is edited after launch. Compare tools on those points, not on generation speed. We publish GoodBarber, so read our assessment with that in mind and check the documentation linked above.

How to create an app with AI: the 7 steps

Each step below says what it's for, which tools help, what you should end up with, how to check it, and the most common way it goes wrong. Where GoodBarber is used as an example, it's labelled as such; the method applies to any tool.

Before building anything, use ChatGPT, Claude or Gemini to turn a vague idea into a one-page brief.

This is where general AI assistants deliver the most value for the least effort. Ask them to:

• Define the audience and the problem. "Who would download an app for [your idea], and what problem does it solve better than a website?"


• List the core features. Ask for ten, then keep three to five. A first version that does three things well beats one that does twelve things badly.


• Map the user flow. "Describe, screen by screen, what a first-time user does in this app." Any core action that takes more than three taps is a flag.


• Group competitor complaints. Paste 1- and 2-star reviews of similar apps and ask the assistant to group them. That list tells you how to stand out.


• Choose a monetization model. Subscriptions, product sales, ads, memberships, or none.

Tools

Any general AI assistant

You should end with

A one-page brief covering the audience, the problem, 3–5 features, the main user journey and the business model

Check it

Show the brief to three people from your audience. Can each of them say, in one sentence, why they'd install the app?

Common failure

Accepting the assistant's feature list without cutting it. AI makes adding features feel free; building, testing and maintaining them isn't.

The AI app-building prompt: a reusable template

Paste your brief into this template and give it to any AI assistant or prompt-to-app tool. It asks the AI to find what's missing before proposing a solution, which reduces the rework later.

You are helping me plan an app. Before proposing any solution, list what is
missing, ambiguous or contradictory in my brief, and ask me about it.

APP CONCEPT: [one sentence]
TARGET USERS: [who they are, when and where they'll use the app]
PROBLEM: [what they can't do well today]
PLATFORMS: [iPhone / Android / web; must it be in the App Store and Google Play? yes/no]
CORE FEATURES (max 5, in priority order): [1. … 2. … 3. …]
USER ROLES AND PERMISSIONS: [visitor, member, staff, admin; who can see or edit what]
CONTENT AND DATA: [what data, who creates it, how often it changes]
INTEGRATIONS: [payments, bookings, maps, existing website, CRM…]
DESIGN: [brand colors, fonts, 2–3 apps whose look you like]
PRIVACY AND SECURITY: [personal data collected, age of users, rules that apply, e.g. GDPR]
BUDGET AND CONSTRAINTS: [monthly budget, launch date, who will maintain it, technical skills available]
DONE MEANS: [what must work for version 1 to be considered finished]

Then:
1. List missing or contradictory requirements and ask me about them.
2. Propose a version-1 scope: must-have now vs later.
3. Describe the main user journeys, screen by screen.
4. Say which type of tool fits (prompt-to-app generator, AI-assisted app
 builder, custom development) and why, given my platforms, budget and
 maintenance constraints. Say what you are unsure about.
5. Write test cases for each must-have feature.

Choose the tool for the output you need: a prototype, a web app, a native store app or a custom product. The right tool is different for each.

Tools

The comparison tables above, each tool's own documentation, and the free trials

You should end with

One approach and one or two tools to try, chosen against your brief

Check it

For each must-have feature and each platform, can you point to the documentation page that says the tool supports it?

Common failure

Choosing on the first demo, then finding out at launch that store publishing, push notifications or content editing aren't covered

Unsure whether you need a native app or a web version? Our guide How to make an app compares the two.

Get a working skeleton with the main screens and navigation, then improve it. Don't try to perfect it on the first pass.

With a prompt-to-app generator

Paste the scope from the prompt template and ask for the main navigation and screens only. Add features one at a time, so that when something breaks you know which request caused it.

With an AI-assisted app builder

You configure pre-built features rather than generating code, usually starting from a structure suited to your type of app. You give up some freedom over the structure; in return, the parts every app needs (accounts, push, content editing, store builds) already work together.

You should end with

The main navigation and one working version of each core screen, viewable on a phone

Check it

Walk through the main user journey from your brief on a real phone. Every step should exist, even if it's still rough.

Common failure

Asking for everything in one giant prompt, then spending more time untangling the result than building it step by step would have taken

Use AI to choose colors, draft text, suggest SEO terms and translate, then review everything it produces.

Most building tools now include AI for these tasks, and a general assistant can do all of them too. What matters is that a person checks the result before it reaches users: AI text can be fluent and wrong, and a generated palette can fail contrast on a real screen.

You should end with

Real content on every screen (no placeholder text) and a consistent visual identity

Check it

Check every fact, price and opening hour against your own records, and check text contrast on a phone outdoors. Apple lists placeholder content and incomplete information among frequent review issues (Apple).

Common failure

Publishing AI drafts unread. They can be fluent and wrong at the same time.

Use built-in features where they exist. When something specific is missing, describe it in plain language and have AI generate it, then test it like any other code.

Most apps need the same foundations: accounts, push notifications, payments, forms, bookings, maps. Prefer built-in or well-documented integrations for these; they're the parts where a generated version is most likely to hide security or billing mistakes.

For the feature that's specific to your project, describe the input, the output and the edge cases, not just the idea. "A shipping calculator" gives the AI room to guess; "weight in kg and destination country in, price in euros out, an error message for unsupported countries" doesn't. Then test the result with wrong inputs as well as right ones.

You should end with

Every must-have feature from the brief working end to end

Check it

Run the test cases from the prompt template, including wrong inputs (an empty field, a weight of zero, an unsupported country)

Common failure

Testing only the "happy path" the AI demonstrated

Test on real phones, covering security and accessibility as well as features. Then publish through the stores' own accounts and review processes, which apply whatever tool you used.

Test checklist

• Every user journey on at least one recent iPhone and one recent Android phone, plus a small screen.


• Accounts and data: sign up, sign in, sign out, password reset; one user must never see another user's data.


• Payments in test mode before real money.


• Accessibility: large system text, contrast, screen-reader labels (VoiceOver on iPhone, TalkBack on Android).


• Poor network: what the app shows when it's slow or offline.


• AI-generated code: no secret keys visible in the app, database access restricted to what each role needs, inputs validated.


• Real testers: 5–10 people from your audience, through TestFlight on iPhone or a closed test on Google Play.

Publish on the App Store

• Official source Account: the Apple Developer Program is "99 USD per membership year," and prices "may vary by region and are listed in local currency" (Apple). Organizations need a D-U-N-S number. Some nonprofits, accredited educational institutions and government entities can apply for a fee waiver.


• Official source Review time: Apple typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours (Apple).


• Official source Most common issue: "over 40% of unresolved issues" relate to guideline 2.1, App Completeness: crashes, placeholder content and incomplete information (Apple).

Publish on Google Play

• Official source Account: "a US$25 one-time registration fee," with identity verification (Google).


• Official source Testing requirement for new personal accounts: personal developer accounts created after November 13, 2023 must run a closed test "with a minimum of 12 testers who have been opted in continuously for at least 14 days" before publishing to production (Google). Plan for these two weeks.


• Official source Review time: Google doesn't publish a standard duration; for some accounts it says reviews can take "up to seven days or longer in exceptional cases" (Google).

How often are apps rejected? Two different measurements

You should end with

An app approved in each store you target, or a clear list of what review asked you to fix

Check it

Before submitting: no placeholder content, a privacy policy linked, screenshots that match the app, and a demo login for reviewers if the app needs an account

Common failure

Leaving store accounts until the end. Organization accounts need a D-U-N-S number, and new personal Google Play accounts need a 14-day closed test.

After launch, the work becomes content, campaigns, orders, fixes and OS updates. Choose tools that help with that, not only with creation.

Operating the app from an AI assistant

The Model Context Protocol (MCP) is a standard that lets AI assistants connect to other software. If your platform runs an MCP server, an assistant such as Claude or ChatGPT can carry out routine tasks on the live app when you ask in plain language. Keep a person reviewing anything that affects customers or money.

AI for your app's users

AI can also serve the people who use your app, most usefully as an assistant that answers from your own content rather than from the model's general knowledge, which keeps answers on topic and checkable.

You should end with

A routine: who updates content, how often, who checks reviews and crash reports, and who approves changes

Check it

Time a routine change, such as adding a product or a class and notifying users. It should take minutes, not a developer.

Common failure

Treating launch as the finish line. Apps nobody updates lose their users.

A worked example: the same app built three ways

From the same brief, the prompt-to-app tools produced something clickable within minutes to an hour. On Bolt, push, content editing and native publishing each needed an outside service or technical setup. On Base44, native push and native store publishing weren't supported at the time of the test. GoodBarber covered all nine requirements, one of them with custom code, and its iOS app went live after one rejection.

Our test To compare approaches on something concrete, we wrote one brief, AURORA, a fictional luxury travel-guide app, and built it on several platforms. Each build is written up in a published head-to-head by Muriel Santoni, Marketing Manager at GoodBarber. This section scores three of them against the nine requirements, using only what those write-ups document.

Worked achieved in the test · Partial achieved with limits or extra work · External service achieved by adding another service · Not supported at test the tool didn't offer it then · Not documented / Not built no evidence either way. "Not documented" doesn't mean "not supported", and "Worked" in a test doesn't mean production-ready.

What has changed since the test

AI tools change quickly, so we keep the historical test result separate from what each tool documents today.

What this test shows, and what it doesn't

• It shows that the speed gap is real. The prompt-to-app tools produced something clickable within minutes to an hour, faster than configuring a structured app.


• It shows where the remaining work sits: push, content editing, monetization and native store publication. On Bolt, each became a separate service or a technical setup.


• It doesn't show native build times, the total hours spent, or which plans were used; none were recorded.


• It doesn't test production readiness (security review, load, long-term maintenance) on any of the three.


• It isn't independent. GoodBarber ran the test and publishes this article. The write-ups are public so you can check every cell above.

What AI can do when building an app, and what still needs you

AI drafts at every stage, but a person still has to check and approve the result at every stage.

Can ChatGPT or Gemini make an app on their own?

They can plan an app and write its code, but they don't build, host or publish it. Turning generated code into an app on someone's phone still means setting up a development environment, compiling for iOS and Android, hosting a back end, handling payments and permissions, and passing store review. In practice, it works well to combine them: an assistant to think and write, a building tool to produce and publish the app, and the same assistant connected through MCP to help run it.

Which AI should you use to create an app?

There's no single best AI for building an app. Pick one per job, based on your platform, your skills and who will maintain the app.

Can you create an app with AI for free?

You can usually build and test for free. Publishing in the stores and running a live app always cost something.

• Building and testing: most AI tools have a free plan or trial, with limits. Base44, for example, lets you run its store-readiness scan for free but requires its Builder plan to download the store files (Base44). GoodBarber offers 30 days with every feature and no credit card.


• Publishing: Apple's developer program costs US$99 per year, with fee waivers for some nonprofits, accredited educational institutions and government entities. Google Play charges a one-time US$25 fee (Apple, Google).


• Operating: a live app needs hosting, a database, push notifications and often payments. Some tools include them in the plan; others bill them separately or rely on outside services.

How much does it cost to create an app with AI? A worked example

Compare the first-year cost of everything the app needs, plus the time it takes you, not the monthly price of the building tool.

We priced the first year of the nine AURORA requirements three ways: on GoodBarber, on the Bolt route as built in our test, and with custom development. Every figure is labeled Quoted (from the vendor's own price page, checked October 9, 2026), Assumption (our choice, stated), or Not totaled (with the reason). We don't convert currencies, to avoid adding an exchange-rate assumption.

How to read this comparison

• The Bolt route's quoted cash cost is lower. It also leaves out three things the GoodBarber figure includes: push (price unconfirmed), the chatbot (not built in the test) and the time spent on native builds, signing and code upkeep.


• The GoodBarber subtotal covers all nine requirements, but €959 of the €1,619 is three paid extensions (accounts, in-app purchase, Chatbot). Without a chatbot or paid content, the subscription alone is €660.


• What decides it is mostly time: how many hours you, or a developer, will spend building, publishing and maintaining the app, and what those hours are worth to you.


• Custom development has no defensible figure here, because its cost depends on scope, team and rates. Any number without a real quote would be invented. The formula is: year-1 cost = (build hours + maintenance hours) × hourly rate + hosting + services + store fees.

GoodBarber figures come from the live price list on October 9, 2026, in EUR; on the yearly plan, extensions are priced per year. Billed monthly, the same setup costs €1,920 (plan €840 + extensions €144, €588 and €348). Prices are shown in your currency on goodbarber.com/pricing. GoodBarber takes no commission on e-commerce sales; payment processors' fees apply. Third-party prices: Bolt, Expo, Sanity, OpenWeather, Progressier; Apple commission: 15% under the Small Business Program (developers under US$1 million in annual proceeds), higher otherwise.

6 mistakes to avoid when creating an app with AI

1. Confusing a prototype with a product. A demo that works in a browser isn't an app approved in the App Store. Decide which one you need in Step 2.


2. Prompting before planning. Vague prompts produce vague apps. Fill in the prompt template first.


3. Publishing AI text without reading it. Check facts, prices and tone before they reach customers.


4. Skipping the security check of generated code. Look at who can read and write which data before real users sign up.


5. Leaving store accounts to the last week. D-U-N-S numbers, identity checks and Google's 14-day closed test for new personal accounts all take time.


6. Counting only the subscription. Add hosting, push, content editing, store fees and maintenance time to compare tools fairly.

Frequently asked questions

How we researched this guide

• Who wrote it. The GoodBarber Team: written and fact-checked by GoodBarber's marketing team. The AURORA builds were run and written up by Muriel Santoni, Marketing Manager. The store-submission figures come from GoodBarber's publishing team and have also been published by Jerome Granados, CMO, and Pierre-Laurent Medori, Head of Backend Engineering.


• Our interest. GoodBarber has made an app builder since 2011, so we have a commercial interest in this topic. We label our own data, tests and opinions, and link to the evidence for everything else.


• External facts (store fees, review times, guidelines, tool capabilities, third-party prices) come from Apple, Google and each vendor's own pages, checked on October 9, 2026.


• First-hand evidence comes from the AURORA builds, done on or before April 2, 2026 (Base44) and June 2, 2026 (Bolt), the dates their comparisons were first published. The write-ups don't record the exact run dates, the plans used or the native build times. Where a tool has changed since, we show the historical result and the current documentation side by side.


• GoodBarber figures come from internal records, with the source, period, scope and definitions stated next to each one. Sample sizes for the store figures aren't disclosed.


• Review policy. We re-check prices, store requirements and tool capabilities at least every quarter, and whenever one of them changes. The "Last reviewed" date at the top changes only when we've actually re-checked them.

Changes. October 9, 2026: first published.