I Have an App Idea. Now What? Your First Two Weeks, Day by Day

This guide is for the moment right after the idea, when you are wondering where to start, who to trust and whether someone will steal it. It is not a pitch for a development shop. Prices and plan details were checked on each company's own page on November 6, 2026.

I have an app idea. Where do I start?

Start with the people who have the problem, not with the app. The order that wastes the least time and money is:

1. The problem. Who has it, how often, and what they do about it today.
2. The people. Real conversations with people who have it.
3. The page. One sentence on a page with a signup form, shown to strangers.
4. The prototype. A clickable mockup of the one main action.
5. The build. Only after the first four say yes.

Most first-time founders do it the other way round: they spend months building, then go looking for users. The cost of that order shows up in the data. CB Insights studied 431 venture-backed startups that shut down since 2023 and found a reason for 385 of them. Poor product-market fit was a factor in 43%. Running out of money was a factor in 70%, which the report calls "almost always the final cause of death, not the root problem." Those were funded companies with teams. A founder with no money can't afford to learn the same lesson by building first.

The good news is that the first four steps cost almost nothing, and two weeks is enough to get a real answer.

What to do with an app idea on day one

Write it down on one page, today, and put the date on it. Five short sections are enough:

• Who has the problem. Not "everyone". A person you could describe to a friend: "nurses who swap shifts", "parents who coach a kids' soccer team".
• The problem, in their words. What annoys them, how often, and what it costs them in time or money.
• What they do today. The spreadsheet, the group chat, the paid tool, the paper notebook. If they do nothing, that is important too: it may mean the problem is not painful enough.
• What your app does instead. One main action, in a verb: "swap a shift in two taps", "send the team the weekend schedule".
• Why you. What you know about this problem that most people don't. It can be as simple as "I have done this job for six years".

This page does three jobs. It forces you to be specific, it becomes the script for every conversation in the plan below, and the date on it starts a record of your work, which matters for the next section.

Then do the five-minute check everyone skips: search the App Store, Google Play, Google and Product Hunt for apps that already do this. Finding competitors is usually good news, because it means people want the outcome. Read their 1-star and 2-star reviews. They are a free list of what users hate about the current options, and one of those complaints may be your way in.

Will someone steal my app idea?

This is the fear that stops more people than any other, so here is the honest version. It is general information, not legal advice, and the details differ by country.

Copyright and patents do not protect bare ideas. In the US, copyright law excludes "any idea, procedure, process, system, method of operation, concept, principle, or discovery", in the words of the US Copyright Office. Copyright protects what you actually write or draw: the code, the designs, the text. Patents don't cover bare ideas either. The USPTO puts it plainly: "abstract ideas cannot be patented, nor can only an idea or suggestion." Some software inventions can be patented, but the same page warns that the cost of legal help "can be prohibitive" for independent inventors.

NDAs won't help much at this stage. The law firm Cooley says professional investors "nearly always refuse to sign NDAs", and that many see the request as a sign of inexperience. Asking the people you want to interview to sign one will mostly stop the conversations from happening. An NDA does make sense with someone you are about to hire, who will see your code, customer data or accounts.

What is worth doing:

• Keep dated notes. Your one-pager, your interview notes, your emails and later your code history make a dated record of what you did and when.
• Share the problem freely, keep the keys private. Talk openly about the problem you are solving. Never share passwords, code access or account logins with someone who has not signed a contract.
• Get a written contract that assigns the work to you when you hire. This is the one that catches people out. In the US, a commissioned work only counts as "work made for hire" if it falls into one of nine categories listed by the Copyright Office, and software is not a category of its own. So without a written assignment, the freelancer who writes your app may keep the copyright in the code. Any contract should say the code, designs and everything made for the project belong to you once paid.

The real protection is speed and the people you collect. A copycat can copy your screens. They can't copy the people who signed up because they trust you to solve their problem, or the conversations that taught you what to build.

I have an app idea, what do I do? The 14-day plan

Here is the whole plan, one deliverable a day. Treat the days as an order, not a deadline: if day 4's conversations take until day 6, that's fine. Don't skip ahead to building.

Days 1 to 6: the problem and the people

Days 1 and 2 are the one-pager and the competitor check above. Days 3 to 5 are conversations, and they matter more than anything else in the plan.

Your 20 people are not friends who will be nice to you. They are people who have the problem: colleagues, people in a group you belong to, people who posted about this exact annoyance online. If you can't name 20, that is your first finding, and our guide on how to find early adopters shows where to look.

In each conversation, ask about the past, not the future. "Tell me about the last time this happened" gets you the truth. "Would you use an app that did this?" gets you politeness. We keep a full list of customer discovery interview questions to copy, plus the ones to avoid.

On day 6, write one sentence that the people you spoke to would recognize themselves in. Build it from their words, not yours. If three nurses said "I hate chasing everyone in the group chat to cover a shift", your sentence is close to: "Swap a shift without chasing anyone in the group chat." If you can't write it yet, you need more conversations, not a better sentence.

Then write down your signup number for the week ahead (more on choosing it in the gate section below). Writing it before you share the page is the whole point: a number picked afterwards will always look good enough.

Days 7 to 11: the page and the prototype

On day 7, put up a page. It needs very little: your sentence as the headline, one line on the problem, one picture (a sketch of the main screen is fine), a signup form and one optional question, such as "How do you handle this now?" If you are new to the idea, here is what a pre-launch waitlist is and why it works as a test. You can make the page for free with a waitlist landing page builder (LaunchList's is one; more on that at the end), and there is a guide to setting up an idea validation landing page specifically.

On day 8, share it. Send it to your 20 people with a personal line, and post it where your users already gather online, following each group's self-promotion rules. Add a different tag to each link you share (for example ?source=reddit) so you can see which place brought signups.

On day 9, make a clickable mockup of the main action: five screens or fewer, made in Figma or in an AI app builder. On day 10, watch three people who signed up try it while you stay quiet. The places they hesitate are your real design brief. If you are unsure whether you need a mockup, a prototype or a minimum viable product, our guide on MVP vs prototype vs proof of concept explains which to build first.

On day 11, email every signup a short personal note with one question: "What did you hope this would fix for you?" The replies tell you which part of your sentence worked, and the people who answer are your next interviews.

Days 12 to 14: the commitment and the decision

On day 12, ask for something that costs the person something: a pre-order, a small deposit, or 20 minutes on a call. Kind words are free. A card number or a calendar slot is not. If you want to take money before the app exists, here is how to pre-sell a SaaS without making promises you can't keep.

Day 13 is choosing how the app gets built, using the sections below. Day 14 is the decision.

Day 14: build it, change it or stop

This is the gate. It is deliberately short here, because the full method for testing an idea, with the tools for each step, lives in our guide to idea validation tools. What matters on day 14 is that you decide using the number you wrote on day 6, not how you feel.

Choosing the number. No number works for everyone, so set your own. For a first-time founder with no audience, we suggest this bar: about 20 signups from people you don't know in the week you share the page, with at least five of them willing to talk to you. It is our judgment, not a benchmark: small enough to reach by hand, big enough that it can't just be your friends. Signups from friends don't count toward it. To see how many signups real waitlists got in their first week and first month, use the free Waitlist Benchmark.

Reading the result:

• Build it. Strangers passed your number and some of them committed. Move to the cheapest way to build the one main action.
• Dig deeper. People signed up, but nobody would talk or pay. The problem may be real but mild. Go back to the conversations and ask what they use today and what it costs them.
• Fix the page. People visited but didn't sign up. The sentence or the audience is off. Rewrite the sentence in the words of the people who came, and run one more week.
• Stop or switch. Nobody recognized the problem in conversations, and the page got no response. That is a result, not a failure. You spent two weeks, not two years, and you can run the same plan on the next idea.

If you just want a quick gut check before you start, the idea validation scorecard asks the questions an experienced founder would.

I have an app idea but no money

Good news: the testing part costs close to nothing, and in 2026 a simple first version can too. Here is what each step really costs, checked on each company's own page on November 6, 2026.

So the honest answer to "how much money do I need to start an app?" is: nothing to find out whether you should, a few hundred dollars a year to publish a simple version you built yourself, and five figures if you hire an agency.

Four things to know about the $0 path:

1. Free tiers are for testing, not for running a business. Five build credits a day goes fast when you are changing things often. Plan to pay for a month or two once you are building in earnest.
2. Don't raise money for an idea. With no users, investors have nothing to judge except you, and you give away a lot of the company for very little. Evidence from the 14 days (signups, conversations, pre-orders) is worth more than a pitch deck.
3. Pre-sales are funding. If people will pay before the app exists, that money can pay for the build. It is also the strongest yes you can get.
4. Keep your job while you test. Two weeks of evenings is enough for this plan. If it works and grows, here is how to judge when a side project should become a startup.

How can I turn my idea into an app?

Once the gate says build, there are four broad ways to get from a tested idea to a working app. Pick the cheapest one that can deliver your one main action.

A clickable mockup

Good for: testing whether people understand the app before anything is built. Where it stops: nothing is saved and nobody can really use it. It answers "do they get it?", not "will they use it?"

An AI app builder

Tools such as Lovable and Bolt turn a description into a working web app, and they are the reason "I can't code" is no longer the end of the conversation. Good for: a first version you can put in front of your signups within days. Where it stops: free credits run out quickly; changes get harder as the app grows; and anything that stores other people's data needs a careful check before strangers use it. Security researchers have found exposed secrets and personal data in public apps made this way, so run the security checklist in our guide for after you build an app with AI before anyone else's data goes in.

A no-code builder

Tools such as Bubble let you build with visual blocks instead of prompts. Good for: apps with lots of screens and rules that you want to control piece by piece. Where it stops: you are tied to the platform, a live app needs a paid plan, and Bubble's own pricing page says publishing to the app stores needs one too.

Someone else writes the code

A freelancer, an agency or a technical cofounder. That choice deserves its own section.

Cofounder, freelancer, agency or solo?

A cofounder is a marriage, not a hire. Paul Graham listed the single founder first in his 2006 essay on startup mistakes: "Have you ever noticed how few successful startups were founded by just one person?" A good technical cofounder brings judgment as well as code. The catch is that good ones are choosy, and an idea alone rarely convinces them. Your 14 days of evidence (signups, interview notes, a pre-order or two) is exactly what makes the conversation work. Y Combinator runs a free cofounder matching platform if you don't know anyone.

A freelancer works well for a small, clearly written first version. An agency brings a whole team, and the price of one. Clutch, which collects client reviews of development companies, says most app projects on its site fall between $10,000 and $49,999, with an average of about $90,780, and puts the average agency rate at around $25 to $49 an hour.

How to avoid getting ripped off by a dev shop

The fear of being scammed comes up in nearly every forum thread on this topic, and it is reasonable. These habits protect you whoever you hire:

• Test first. Never pay anyone to build an idea nobody has signed up for.
• Write a one-page spec. The main action, the screens, and a list of what version one does not do. A vague brief is how quotes double.
• Buy a small first milestone. A fixed price for a clickable prototype or one working feature tells you how they work before you commit to the whole app.
• Pay against working software. Pay per milestone you can click and test, not per hours reported. Avoid large payments upfront.
• Own every account. The code repository, the App Store and Google Play accounts, the domain, the hosting and the database are in your name. They get access, not ownership.
• Get the assignment in writing. As above: the contract says the code and designs are yours once paid.
• Talk to two past clients. Ask to see apps they built that are live in the stores, and ask those clients what went wrong.
• Walk away from guarantees. Anyone promising your app will succeed is selling, not building. As the FTC puts it in its warning about invention marketing scams: "no one can guarantee your invention's success."

And budget for after launch. An app needs fixes, updates for new phone operating systems and someone to answer users. The build is not the last bill.

Can I sell my idea for an app?

Almost never as an idea alone, for the legal reasons above: there is nothing on paper to sell. Large companies go further and refuse to look. Apple's policy on unsolicited ideas says it does "not accept, review or consider any unsolicited ideas", and that anything sent anyway becomes Apple's property "without any compensation to you."

Be careful with anyone who offers to sell or license your idea for an upfront fee. The FTC warns that dishonest invention marketing firms "might say you have to pay several thousand dollars upfront", and that US federal law entitles you to their record, including how many past clients ended up with a net profit.

What does sell is evidence. An app with users, a list of people waiting for it or a few months of revenue can be sold, licensed or used to bring in a partner. The 14-day plan is the first step toward having something worth buying.

I built an app. Now what?

That is the next stage, and it has its own guide: I built an app with AI. Now what? covers the stranger test and security checks to run before you invite anyone, then how to find your first 10 to 100 users by hand. If you followed this plan, you will start that stage with a head start most founders don't have: a list of people who already asked for it.

Where LaunchList fits

LaunchList is pre-launch waitlist software for founders, and it covers day 7 of this plan and what comes after it. It does not build your app, and it does not find people for you: the conversations are still yours.

• A page from one sentence. Describe your idea and the AI writes a waitlist page you can edit and publish at its own launchlist.page address. You can add one question to the signup form, so each signup doubles as a tiny interview.
• A form inside your app later. When you build with an AI app builder, you can add the waitlist to an app built with AI and keep the same list.
• A referral link for every signup. Each person sees their place in line and gets a link that can move them up when eligible friends join, which tells you whether people care enough to share.
• Email when you are ready. When the app is ready, you can email the whole list or part of it, starting on the Collect plan.

The page, the form and referral links are on the Free plan, which holds 100 contacts. LaunchList takes no payments, so pre-orders run through a payment tool of your choice.