I Have an App Idea: Where Do I Start?

Eight results hold the front page for this question. Two are community threads, one four years old and one ten. One is a video. The remaining five are published guides. Three of them, read in full on one day, tell a reader with an idea to do roughly the same thing: write it down, research the market, draw a picture of the customer, list the features, pick a way to charge, sketch a screen, work out a budget, and then, somewhere around step seven, find somebody who can build it. That order made sense while building was the expensive, slow part of a project. A description typed into an AI builder now produces something that runs, and almost every question those guides put ahead of the build has a better answer once the thing exists.

The first move is a rough working version of the idea, made this week with an AI builder, inside accounts in your own name. Research, features and pricing all get sharper answers once something runs. The step every list puts seventh is now the cheapest one on it.

What to do first when you have an app idea and cannot write code

Five things to have before you start: a plain description of what one person does with it in one sitting, an account in your own name at whichever builder you pick, somewhere for the data to live, one real person who will look at it, and a decision to stop after the first version instead of continuing.

The order matters: each one makes the following one cheaper.

A plain description of one sitting. One person, one session, one thing they finish, rather than the product or the roadmap. A vet nurse opens it, records what a dog weighed, and closes it. A tutor opens it, marks who turned up, and closes it. If you cannot say what one person does in one sitting, the builder will invent something, and you will spend the week reading its guess instead of your own idea.

An account in your own name. Whatever tool you use, sign up with your own email and your own card. This costs nothing extra and it is the difference between owning the thing later and asking somebody for it. The same rule covers wherever the data ends up and whatever service sends email.

Somewhere for the data to live. Most builders offer you one, and taking the offer is fine at this stage. What matters is knowing which service it is and being able to reach it as the owner: directly, when the data lives in a separate provider account, or through the project’s own data view when the builder manages the backend inside the project.

One real person who will look. One person in the situation your idea is about, who will open it while you watch, rather than a survey or a waiting list. Finding them takes an afternoon and beats any amount of desk research.

A decision to stop. Write down, before you start, the point at which the first version is finished. It is the only thing on this list that gets harder to do later, because a running app invites another prompt, and another one, and three weeks disappear.

Somebody asked a builder community in July 2026 a question that is this page in nine words: “Trying to get my hands on vibecoding. Where do I start?” The same position turns up constantly in public posts, phrased with more detail and the same missing piece:

“I am a veterinarian and I want to build a app/site with AI on the background… I have zero experience.”

Nothing in that sentence is a problem for the first version. Zero experience is the normal starting condition now, and it stopped being disqualifying at roughly the moment these tools got good at going from a description to something that opens. A third person put it more simply: they were not a developer, they had something they wanted to exist, and the tools covered the distance between the two. One owner had sat on a plan for a long time before an assistant turned it into something that ran, and the building itself stopped being the slow part. That is one person telling their own story, not a schedule, an average or anything to hold yourself to.

Two things are worth settling before the week starts. Some ideas are a poor match for what these tools produce, and settling that comes before any of this starts. If your idea only makes sense on a phone, check whether a builder can produce a phone app at all before you pick one, because the answer differs by tool and it decides your whole route.

How a builder is actually driven, prompt by prompt, from an empty project to something that runs, is not on this page. What a first version is called, and which page answers which question about one, is a map rather than a step.

What the answers ranking for this question tell you to do, and when they were written

Each ranking answer described here was opened once on 1 September 2026, and is named for the first move it tells a reader to make, rather than summarised whole; where this page says a guide does not mention a builder, that was checked against the page’s own source and not against a reading view.

None of the five is linked below. Four of them sell app work or app building software, so each is named and its address is written out for anyone who wants to check the reading: www.koombea.com/blog/i-have-an-idea-for-an-app-now-what/, www.alphasoftware.com/blog/how-to-convert-your-ideas-into-a-mobile-app, squareroot.ie/blog/i-have-an-app-idea, www.goodbarber.com/blog/how-to-make-an-app/ and www.adjust.com/blog/i-have-an-app-idea/.

The koombea guide runs nine headings and ends on finding a developer, marketing and publishing. Before any of that it says building an app is not cheap and that you should partner with an app development company, which tells you what kind of page it is. No AI builder and no AI coding tool appears anywhere in the source. The letters AI do occur eighteen times, and every one is the publisher’s own: its site name in the page’s head tags and schema block and in its header and footer branding, its navigation and footer links to the AI services it sells, a subtitle on its newsletter block, and a promotion in the sidebar for its own AI service with the link that goes with it.

The alphasoftware guide is nine numbered steps, from writing the ideas down through market analysis, a persona, a feature list, a way to charge, prototypes, picking software, working out cost, and marketing. Its own low code and no code products get three headings, which is context a reader should have before taking the sequence at face value. The nine steps name no AI builder. The source does carry the phrase vibe coding and one assistant’s name, and both sit inside a block of thumbnails advertising other articles rather than inside the guide.

The squareroot guide is seven steps: pen the idea down, research the market and the competitors and the customer, write a value proposition, work out budget and funding, choose how to charge, develop, launch on the stores. Its development step sends you to three named directories to find an app development company and to agree a written plan of the stages with them. Nothing in the source names an AI builder or an AI coding tool. The word AI appears seven times, all of them inside the publisher’s own menu of AI services: six links to services it sells, and the menu item that opens those six. The only matches for the string cursor are two declarations in the page’s styles.

The goodbarber guide is the exception, for an obvious reason. The publisher sells a no code app builder, so it is the one page here whose body has to talk about what AI does to app building. It has a section on how AI speeds up no code app creation, names three assistants that can drive an app through a protocol server it publishes itself, and names several builders in its comparison. It also carries this year’s date, having been changed three days before this reading.

That leaves adjust. As of 1 September 2026, adjust’s page on this question does not return content to an automated read. Five attempts on the day, three of them reading the raw source rather than a reading view, all came back with a security checkpoint and a rate limit code instead of the article. The search snippet shows a checklist opening on researching the market and competition and setting a budget, dated Jul 9, 2024. That is snippet evidence rather than a reading, so nothing is claimed here about what the page mentions.

Two things follow. The first is the pattern: of the four answers that could be read (the fifth stays out of the count, because a page nobody could read cannot be counted either way), three do not mention, anywhere in the guide itself, the class of tool that changed the answer, and the one that does mention it sells one. The second is the honest explanation, and carelessness plays no part in it. Those sequences were written when the build was the expensive, slow, irreversible part of the project. If it takes months and a team to find out whether an idea works, then of course you research first, because research is the cheap way to avoid paying for the wrong thing. Every step ahead of the build was there to protect the build. Take the cost out of the build and the protection is worth less than the thing it was protecting you from.

What research is for once the app can exist first

Research still matters, and what it is for has moved. It used to be how you avoided paying for the wrong app. Now the wrong app costs a few evenings, so the running version becomes the research instrument, and the question changes from whether people want this to whether this person opens it a second time.

The old question was hard because it was hypothetical. You asked people about a thing that did not exist, they answered politely about a thing they had imagined, and you built the thing you had imagined.

Somebody in a founder community asked, in August 2026, a title that is the whole of the old approach: “How do you properly validate a B2C SaaS idea before building it? What questions sh…”. The honest answer now is that the word before carries much less weight than it once did. You can put a thing that runs in front of one person in a week, and one person opening it twice tells you more than thirty people saying they would.

What is still worth doing before you start is narrow and takes an afternoon. Search the stores and the web for the thing you are picturing and see whether it exists already, because it usually does, and knowing which version of it exists changes what you build. Read what people complain about in the existing ones, which is free and specific and better than any question you could ask. Find out whether the people you have in mind pay for software at all, because a good idea aimed at people who never pay for anything is a hobby. None of that requires a persona document.

Then build, and change the question. Give it to one person. Watch where they stop. Come back a week later and check whether they went in again without being asked. That second visit is the strongest early signal you can get, and no amount of desk work produces it; pick the window to match how often the job naturally recurs, a week for a daily task and longer for a monthly one, and treat one person’s return as a signal to build on rather than proof the idea works. It is worth seeing what people have actually built this way before deciding your own idea is unusual, because most of the ideas people arrive with are ordinary and get built.

Another person described starting from nothing but a plan and no technical training at all, and being some way past that point now. That is their account of their own project rather than a schedule anybody should copy, and what makes it useful is the shape of it: the thing existed early, and everything since has gone on what came after it.

What actually separates the apps that work

Features are no longer the answer. What makes an app successful is no longer what is in it, because features arrive free and first now, generated in bulk from a description, and every app in your category has them. What separates the ones that work is what happens on the second visit, the second person, the failed payment and the shared link.

Search for what makes a good app and you get lists: tips, qualities, features every successful app needs. Those lists meant something when a feature was a fortnight of somebody’s salary, because a feature list was then a statement about what a company had chosen to spend money on. A builder produces eleven of them before lunch. Here is what actually pulls apps apart once several of them exist and do the same things.

What happens when the second person signs in. Almost everything built from a description works beautifully for its first user, because that is the case that got described. The second account is where you find out whether the app knows who is asking. People see each other’s records, or the settings one person changed apply to everybody, or the invite goes nowhere. This is the single most common gap between a demonstration and a product.

What happens when something half fails. A card is declined, a network drops, an upload dies at ninety percent. Working software has an answer for each. Generated software very often has an answer for the success case only, and the half failure leaves the user looking at a screen that says nothing while something in the background thinks the job is done.

What happens when somebody sends a link to somebody else. Real use spreads sideways. A link gets forwarded, and now a person who never signed up is looking at your page. Whether that works, and whether it works without showing them things they should not see, decides whether the app can grow at all.

Whether it is still true next month. Rules change, a supplier changes theirs, a form gains a field. An app that is right on launch day and wrong six weeks later is a snapshot rather than a product.

None of these is exotic or a feature; all of them are about the second, third and hundredth use, which is exactly the part a description does not describe.

Building an app to sell, and what changes if selling is the point

Plenty of people arrive at this question wanting to build an app to sell, either as a product with customers or as an asset somebody else buys. Both are reasonable, and both change what the first version has to be.

If you mean selling access, somebody else’s money and somebody else’s data are now involved. Money means a payment provider, so a half finished payment becomes a real problem rather than a rough edge. Data means the second person signing in has to work before anybody signs in at all. It also means somebody answers email when it breaks, and that is you until you decide otherwise.

If you mean building the app and selling the whole thing, the buyer will look at things you may never have looked at: whether the accounts are in your name, whether the code can be moved, whether anything essential depends on a tool you can stop paying for. All of those are easy to arrange at the start and awkward to arrange later, which is the whole argument for signing up in your own name in week one.

Either way the store question arrives sooner. If people have to install the thing, you need to know what is involved in getting a first app onto the App Store without writing code, and the honest summary is that the building is the easy half. Everything that has to be true before an app reaches the App Store is a store problem rather than an idea problem.

What does not change is the order. Selling is a reason to be careful about the second version rather than a reason to plan the first one for six weeks.

What will be missing three weeks after it runs

The app will exist and work for you. What will be missing is the part nobody prompted for: the second account, the failure paths, the emails, the place data is kept and who can read it. That gap is where the honest work starts, and it is where most people arrive at this blog.

One person put the good half of this plainly:

3 months, no coding background, one Claude Code subscription. An idea in my head turned into an app.

That is real and it is worth saying clearly, because half the advice on this question still treats it as impossible. An idea did become an app, made by somebody who could not have made one three years ago. Their timing is their own and not a number anybody should plan against.

The other half is what the three weeks after look like, and it is consistent enough to predict. Nobody prompted for the missing parts, so they are simply absent: a builder answers the description it was given, and a description never mentions what happens when a stranger guesses a web address. The parts that only matter under real use, like whether two people can act at once without treading on each other, do not show up while one person is testing. And the bar the app is being judged against moves once other people rely on it, without anybody saying so out loud, which is why the app that felt finished in week one feels unfinished in week four with nothing having changed in the code.

All of that is a reason to know what you are signing up for, and to stop at the first version rather than prompting your way into a bigger version of the same gaps; planning longer before starting would not close them. When you get there, the practical question is whether what you have is ready for people who are not you, which is a short check rather than a project.

AxonBuild reads AI-built applications one at a time and writes down what it finds; the fixed cohort of applications behind this blog and how it was read is set out on its own page, and nothing from it is restated here.

Deciding what to do with a first version that exists and stops short is a different job from deciding to start one.

What to do this week, in order

Five moves to develop an app idea into something that runs, each one a decision you can make today, each ending in something you can check.

1. Write the one sitting sentence. One person, one session, one thing they finish. Check: read it to somebody who does not know your idea and see whether they can repeat it back.
2. Open the accounts in your own name. Builder, data, email. Check: log into each separate account directly, and for a backend the builder manages inside the project, confirm you can open its data view and export from it as the workspace owner.
3. Build the version that does the one sitting sentence and nothing else. Check: you can do the whole thing yourself, start to finish, without touching anything you were not going to show anybody.
4. Put it in front of one real person and watch. Do not explain, do not help. Check: write down the first place they stop.
5. Stop, and decide. Either that person came back on their own, or they did not. Check: a date one natural cycle of the job later, a week for most, and an honest answer.

That is the week. If the answer at step five is yes, the next questions are about other people using it, and the order a launch runs in is a real sequence rather than a matter of taste. Putting a working version in front of strangers has an order to it, and that order starts after this page ends.

If the answer is no, you have spent a week and learned something true, which is roughly what the ranking guides ask you to spend on a persona.

Common questions about having an app idea

What should I do first if I have an app idea and cannot code?

Build a rough version yourself, this week, using one of the AI builders, and keep it to the one thing a single person would do in a single sitting. You do not need to read the code and you do not need a technical partner to get that far. Everything the ranking guides put ahead of the build gives you a better answer once something is on a screen.

The one preparation worth doing first is writing down what one person does with it in one session. Builders answer descriptions, so a vague description costs you a week of reading somebody else’s guess at your idea.

Do I need a technical cofounder to build an app?

Not to get a first version working. The tools produce something that runs from a written description, and a great many people with no technical training now have apps that exist because of that. What a technical partner changes is the part after the first version, and you will be able to describe that part far better once you have hit it yourself.

The question comes up constantly, usually in this shape:

How do I approach a technical co-founder as a non-technical founder? And do I actually need one?

Approaching one with something that runs is a completely different conversation from approaching one with an idea, and it is the reason to build first. Nobody has to take your word for what you are proposing when they can open it.

How do I protect an app idea before anyone else sees it?

Mostly you cannot, and mostly it does not matter. Ideas for apps are not protected by copyright, which covers the code and the artwork rather than the concept, and patents are slow, expensive and a poor fit for most app ideas. The practical protection is being the person who built it, because execution is what is scarce now and a description is not.

If you are showing it to somebody you are considering paying, the sensible precautions are ordinary ones. Protecting the idea on paper, and choosing a person to pay once something already runs, belong where hiring is the subject.

Can I sell an app I built with an AI tool?

Yes, and people do. What changes is the diligence somebody will run before buying: whether the accounts are in your name, whether the code can be exported and moved to another host, whether anything essential depends on a tool the buyer would have to keep paying for. All three are easy to arrange when you start and awkward to arrange afterwards.

Selling access to customers is the more common version and has its own requirements, because taking money means the payment path and the second person signing in both have to actually work rather than mostly work.

Do I need to do market research before I build anything?

A short version, yes. An afternoon: search whether the thing exists already, read what people say about the versions that do, and check whether the people you have in mind pay for software at all. That is the part that still saves you time.

The long version, the persona and the survey and the competitive matrix, was built for a world where getting it wrong meant paying for months of development. Now the running version answers those questions better and faster than the document does.

What if someone has already built my app idea?

Assume somebody has. Almost every idea that arrives at this search already exists somewhere, and that is closer to good news than bad, because it proves people want the thing and it tells you exactly what the current version gets wrong. The reviews of the existing app are the most specific research material you will ever get, and they are free.

What matters is whether you can be better for one particular group. Most successful software is a narrower version of something that already existed.

How much of the app can an AI builder actually finish?

The visible part, almost all of it, and quickly. Screens, forms, lists, a way to log in and something that looks like a real product are what these tools do well, and that is genuinely most of what an idea consists of in your head.

What tends not to arrive is the part that only shows up under real use: what happens with a second account, what happens when a payment half fails, what happens when a stranger finds a page they should not see. Those are not hard to fix, but they are almost never in the description, so they are almost never in the build.

How do I know whether my app idea is any good?

You do not, before it exists, and neither does anybody you ask. The reliable early test is whether one real person, in the situation your idea is about, opens the running version a second time without being prompted. That single behaviour tells you more than any number of people saying they would use it.

Set the test before you build so you are not moving the target afterwards. One person, one cycle of the job later, unprompted. It is a low bar and most first versions do not clear it, which is exactly why it is worth having, and clearing it is an early signal rather than a verdict.

Can I submit an app idea to a company instead of building it?

Almost never in the way people mean. Companies do not generally accept unsolicited app ideas, and the ones that appear to are usually looking to sell you development work rather than buy your concept. Searching for somewhere to submit an idea is nearly always a search for somebody to build it.

Which is a fair thing to want, and it is a much better purchase once something already runs, because then you are paying for named work on a real thing instead of paying somebody to interpret a description.