How to make an app: three routes and ten steps from idea to launch

What does it take to make an app?

Four things: an idea narrow enough to finish, a way to build it, a way to put it in front of people, and enough patience to fix what breaks. Notice what is missing from that list. You do not need a degree, a team or a pile of money. You do need to decide what the app does, and decide it in one sentence.

The same steps apply whether you write the code, an AI writes it, or you pay someone. What changes is who does the building and what it costs you in time or money. This page gives you the ten steps first, then helps you choose the route that fits your situation.

1. Write the idea as one sentence about one person and one problem.
2. Check that the problem is real by talking to a few people who have it.
3. Cut the idea down to a first version that does one job.
4. Choose a platform: web, iPhone, Android, or a few of them.
5. Choose a route: AI agent, no-code builder, or hiring someone.
6. Build the first screen and the one action it exists for.
7. Run it on a real phone or laptop and break it yourself.
8. Give it to five people and watch what they do.
9. Publish it, in the cheapest place that still reaches those people.
10. Decide what to fix, what to add and what to stop.

The rest of this page works through those steps. If you only read one section, read the decision table in the next one. Picking the wrong route is the most common reason a first app stalls.

Which route should you take: AI agent, no-code builder or a developer?

There are three ways to get an app built. They are not rankings. Each suits a different person.

• Code it yourself with an AI agent. You describe the app, a tool such as Claude Code, Cursor or Codex writes the code in a project folder on your computer, and you run and review it. You end up with real source code that you own. The step-by-step guide to building an app with an AI coding agent covers this route in detail.
• Use a no-code builder. You assemble screens and data in a visual editor, or describe the app to an AI builder that creates and hosts it. Examples include Lovable, Bubble, Glide and Adalo. You depend on the vendor’s platform, which is a fair trade for speed. The no-code guide goes deeper.
• Hire a developer or studio. You write a brief, someone builds it for a fee. This takes the least of your time and the most of your money. The guide to hiring an app developer covers what to ask.

You can also mix them. A common pattern is to prototype in a no-code or AI builder, show it to users, and move to a coded project or a hired developer once the prototype has proved the idea. Costs and time for each route have their own pages: what it costs to build an app and how long it takes.

How do you turn an idea into something you can build?

Start before any tool. Write one sentence in this form: “For [specific person] who [has this problem], this app [does one thing].” If you cannot finish it, no builder, human or AI, can finish the app for you.

Then check the problem with real people. Find five who have it, ask about the last time it happened and what they did next, and do not pitch. The guide to validating an app idea has the questions. This takes a few days and saves months, because the most expensive failure in app-making is building something nobody needed.

If you do not have an idea yet, you have a different job. Browse the board for ideas other people posted and will not build, or read the guide to finding app ideas. Each idea on the board comes with a generated build prompt you can paste into Claude Code, Cursor or Lovable. For a taste of how small a good first idea can be, see Fridge photo to three dinners, posted on the board: one photo in, three dinner suggestions out.

What should the first version include?

One user, one job, one way to tell it worked. That is all a first version is. Everything else goes on a “later” list that you do not show the builder, human or AI, because anything on the list will get built.

A useful test: could you describe the first version in three screens or fewer? If not, cut. The guide to scoping an MVP walks through the cuts, and what an MVP is explains why the first version is meant to be small. For a quick draft, the MVP Scope Planner turns a description into one core workflow.

Should you make a web app, an iPhone app or an Android app?

For a first version, start where your first five users already are, and take the cheapest option that reaches them. A web app opens in any browser, needs no store approval and can be changed in minutes. A native app can use the camera, notifications and offline storage more fully, but costs more to publish and takes longer to change.

Apple’s figure comes from its App Review page, which says review typically takes under 24 hours for at least 50% of submissions and under 48 hours for 90%. Google’s rule for personal accounts created after November 13, 2023 is a closed test with at least 12 testers opted in for 14 days, set out in its testing requirements.

Each store has its own page here: how to build an iPhone app, how to build an Android app, and how to publish an app on the App Store. If you want to know what is free and what is not, read how to make an app for free.

How do you build the first version, step by step?

The steps below work on any route. On the AI agent route you do them yourself with the agent; on a no-code route you do them in the editor; on the hiring route you check them against what the developer delivers.

1. Write the brief. One page: user, problem, the core flow in numbered steps, what is out of scope. The template below gives you a start.
2. Ask for a plan before anything is built. With an AI agent, request a list of files, data and screens, and correct it. With a builder, sketch the screens first.
3. Build the one screen that matters. Skip sign-up, settings and onboarding. Build the screen where the user does the job.
4. Add storage only when you need it. Many first apps work with no database at all. If you need one, the free tiers of hosted databases are enough to start, such as Supabase’s free plan, which lists a 500 MB database and pauses free projects after a week of inactivity.
5. Run it after every change. Open it, tap through it, try to break it with empty fields, a very long name, a lost connection.
6. Add accounts last. Sign-in brings password resets, privacy duties and security risk. If your first five users can use it without logging in, let them.
7. Keep secrets out of the code. API keys go in environment variables on the server, never in a screen the browser can read or in a prompt.

Build a first version of [app name].

User: [one specific person and the moment they need this].
Problem: [what they do today and why it fails].
Success: [the one result the user gets].

Platform: web app that works on a phone-width screen. No native app yet.

Core flow:
1. [user does this]
2. [app responds with this]
3. [user sees this result]

Data stored: [what, and who can see it. Write 'nothing' if nothing].
Out of scope for now: accounts, payments, settings, notifications, admin pages.
Failure cases to handle: empty input, very long input, no connection, a result that comes back empty.

Before writing code, tell me the stack you plan to use and the list of files you will create, then wait for my go-ahead.
After each step, tell me exactly how to run it and what I should see.

For a longer treatment of writing the prompt itself, see the guide to writing an app build prompt. The free AI Coding Prompt Builder fills in a similar template from a few answers.

How do you test the app and publish it?

Test in two rounds. First alone: use your own app for a day on the device your users will use. Then with five people: give them the link, say nothing about how it works, and watch them try to do the one job. Every moment they hesitate is a bug in your design, not in them.

For publishing, match the place to the stage:

• Web app: deploy to a hosting service. Vercel’s Hobby plan lists a price of USD 0 a month for web apps and personal projects, as of October 2026. Check its terms if you plan to charge users.
• iPhone app: join the Apple Developer Program, upload a build through App Store Connect, pass App Review. Apple’s App Review Guidelines say an app should go beyond a repackaged website, must link a privacy policy, and must offer account deletion inside the app if it lets people create accounts.
• Android app: register a Google Play developer account, then run the closed test if your personal account is new. Plan around the 14-day minimum.

Do not wait for polish. Publish when the one job works and you can name what you will watch for in the first week. Then decide using what users actually did, as the MVP guide suggests.

Why do first apps fail, and how do you avoid it?

• Building before asking. The fix is the five conversations in step two.
• Starting with accounts, payments and a logo. None of these tests whether the core job is useful.
• Picking a platform out of habit. A native app that nobody installs is worse than a web page that people use.
• Letting the scope grow because the builder is fast. AI tools and builders make adding features cheap, and that is the trap. Every feature you add is one more thing to test and maintain.
• Never launching. Without users, you are guessing. Share the link with five people this week, even if it embarrasses you.
• Abandoning the app after launch. Apps need updates when operating systems, stores and libraries change. Decide in advance how much time you will give it each month.

If you decide partway that you will not finish, that is allowed. Write down what you learned and post the idea so a builder can take it on. It costs nothing and needs no account.