Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersWhat to do if you have an idea for an app
If you have an idea for an app, you have four realistic paths: build a rough first version yourself with an AI coding agent, test the idea with real people before building anything, pay someone to build it, or post it publicly so a builder can take it on. Most people should test first, then build small. Copyright does not protect the idea itself, so secrecy matters less than speed.
What are your options when you have an app idea?
Most advice on this question comes from agencies, and their answer is to hire an agency. That is one option out of four, and it is the one that costs the most before you know anything. Here are all four, side by side.
| Path | Time to something real | Money | Skill needed | You keep | What you get |
|---|---|---|---|---|---|
| 1. Build a first version yourself with an AI coding agent | Days to weeks | A tool subscription, your own time | Little coding; patience to read what it produces | Everything | A rough working version you can show people |
| 2. Validate before building | About a week | Close to nothing | Talking to strangers | Everything | Evidence on whether anyone has the problem |
| 3. Pay someone to build it | Weeks to months | The largest outlay of the four | Writing a clear brief; judging quality | What the contract says you keep | A finished product, built by someone else |
| 4. Post it publicly for others to build | Minutes to post; unknown after | Nothing | Writing a clear description | The credit, not control | A chance a builder takes it on, plus feedback |
These are not rivals. The strongest order for most people is path 2, then path 1. Paths 3 and 4 are for when path 1 is not realistic for you, or when you would rather see the idea exist than build it yourself.
Which path should you take?
Answer these in order and stop at the first line that fits.
- You cannot say who has the problem, or when they last had it. Take path 2. Nothing else is worth paying for yet.
- You can name the person and the moment, and you can spare a few evenings. Take path 1 and build the smallest version. The guide to building an app with Claude Code shows the steps.
- The product needs things an AI-built prototype handles badly: payments between strangers, regulated data, real-time systems at scale. Run path 2 first, then path 3 with a tightly scoped brief.
- You have no interest in building or running it. Take path 4. A public post costs nothing and the idea stops sitting in your notes.
If you cannot decide, run the free Idea Checker. It reviews how complete your description is and points out what is missing. It cannot tell you whether people want the product, but it shows which gaps to fill before you spend time or money.
Where do you start in the first seven days?
Do these in order. Each takes an hour or two. None of them requires code or a payment.
- Day 1: write it down in one sentence. Use the form “For [specific person] who [has this problem], this [does this one thing].” If you cannot finish the sentence, the idea is not ready. The brief template below gives you the full page.
- Day 2: search for what already exists. Search the problem in plain words, then search app stores and Reddit. Competitors are good news: they show someone pays for the problem. Note what they get wrong, in the users’ own words.
- Day 3: list five people to talk to. Real people who have the problem, not friends who will be polite. Name the place you could find each one.
- Day 4 and 5: talk to them. Ask about the last time the problem happened and what they did next. Do not pitch. The guide to validating an app idea has the questions and a way to log answers.
- Day 6: decide. Continue, narrow, change, or stop. Write the decision before you look at your notes, then check the notes against it.
- Day 7: act on the decision. If continue, cut the idea down to one workflow with the guide to scoping an MVP and start building. If stop, post the idea (see below) and move on.
The App Idea Validation Planner can draft the interview questions for days 3 to 5 from a description of your idea.
What if you have an app idea but no money?
Then paths 2 and 4 are free, and path 1 is cheap compared with hiring. Money is rarely the first obstacle anyway. The first obstacle is not yet knowing whether anyone wants the thing.
- Do the validation week. It costs time only. Skip paid ads, logos and company registration until someone has shown they care.
- Do the work by hand first. If your idea is a tool that summarises feedback, summarise feedback for one person manually. If the result is not worth your effort when done by hand, software will not fix that.
- Build a thin first version. A prototype that does one thing needs little hosting. Check what each AI coding tool currently charges, including any free tier, before you start; plans change often and this page does not quote them.
- Do not pay a developer to find out if the idea is good. A paid build answers “can this be made”, which is rarely the open question.
- Give the idea away if it needs capital you will not raise. An idea that needs a team, a licence or a large budget is a poor candidate for a solo build. Posting it on the board costs nothing.
What if you have an app idea but no programming skills?
You have more options than a few years ago. AI coding agents such as Claude Code, Cursor and Lovable can produce a working first version from a clear description. They differ in how much they expect you to read code, so pick by how you like to work; the comparison page Claude Code vs Cursor vs Lovable covers that.
Be realistic about what you are signing up for. You do not need to write code, but you do need to describe what you want precisely, run what you get, notice what is wrong, and ask again. An agent builds what you ask for, including a vague request. The skill that matters is writing a clear brief, which is the same skill you need to hire someone.
- Start with one screen and one action. “A page where I paste a receipt photo and get the total” is a better first prompt than “an expenses app”.
- Keep the first version private. Show it to the five people from your validation week before anyone else.
- Be careful with sensitive data. Anything that handles payments, passwords, health or children’s data deserves a review by someone experienced before real users touch it.
- Ask for a build prompt. Every idea on this board gets a generated build prompt you can paste into Claude Code, Cursor or Lovable. Use one as a model for how a good brief reads, even if your own idea is not on the board.
If the idea is bigger than a few evenings can carry, your options are to partner with a builder or to pay one. The next sections cover both.
Can you protect an app idea?
Mostly, no. Not in the form most people hope for. The U.S. Copyright Office states that copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed. Your idea for an app is an idea. The code, the written description and the design of a finished product can be protected. The concept cannot.
| Protection | Covers | Does not cover | Practical catch |
|---|---|---|---|
| Copyright | Original expression: code, text, artwork | The idea, system or method of operation itself | Arises with a finished work; protects the work, not the concept |
| Patent | A new, useful, non-obvious invention that you can describe in enough detail to make and use | Abstract ideas, or only an idea or suggestion | Needs a concrete invention; the USPTO suggests hiring a registered patent practitioner, which costs real money |
| Non-disclosure agreement | What a signing party may do with what you tell them | Anything you did not tell them, or anyone who did not sign | Developers and investors often decline to sign one for an early idea |
| Trade name or trademark | Your product’s name and logo | The underlying idea | Applies once you have a name in use |
On patents, the USPTO says that laws of nature, physical phenomena, and abstract ideas cannot be patented, nor can only an idea or suggestion. It also notes that the invention must be new and not obvious, and that you need a clear description of how to make and use it. A patent can cover some software methods, but that is a specialist question, and it is rarely where a first-time app idea starts. The USPTO’s own guidance is to hire a registered patent practitioner for a real application.
On non-disclosure agreements, it is commonly reported that developers, investors and advisers decline to sign them for early-stage ideas, partly because they hear many similar ideas and do not want a legal dispute over resemblance. Asking for one is not wrong, but if you insist on it before any conversation you may find nobody to talk to. If the idea is truly sensitive, ask a lawyer rather than copying a template.
What protects a product in practice is not secrecy. It is that you ship first, learn from users, and keep improving. Ideas are cheap, and the same idea occurs to many people at once. Execution, distribution and the people who trust you are harder to copy.
A reasonable middle path: share the problem and the plan freely with the people you interview, keep any real private details (customer lists, your own data, unreleased code) to yourself, and put any commissioned work under a written agreement. If you do plan to publish an idea on a board like this one, understand that publishing here is permanent and public.
Who do you go to with an idea for an app, and what should you ask?
You have three kinds of people to ask: a freelance developer, a small studio or agency, and a technical co-founder. The first two work for pay. The third works for a share of the business and will want proof that you have done more than have the idea. Prefer people who respond to your brief with questions. Someone who quotes instantly has not read it.
Do not take a figure on trust from a page that does not know your project. Ask for quotes on a defined scope and compare them yourself. These are the questions that separate careful people from careless ones.
| Ask | Why it matters | Warning sign |
|---|---|---|
| Can we start with a paid, fixed-price discovery phase? | A short paid first step turns the idea into a written scope before you commit to the whole build | Insists on one large fixed contract before any scoping |
| Who owns the code and the designs when we finish? | Without a written assignment, you may not own what you paid for | Vague answer, or ownership only after a later payment |
| What do I receive at handover? | You need the source code, the accounts, the hosting setup and documentation, not only a live link | Hosting and accounts stay in their name |
| Who pays for hosting, domains and third-party services, and in whose name? | Running costs continue after the build | Costs not mentioned until the invoice |
| What happens when something breaks after launch? | Software needs maintenance | No support terms, or a long ‘warranty’ with exclusions |
| Can I speak with a past client and see a finished product? | Past work is the best evidence of how they operate | Only mock-ups and no live examples |
| How do you handle changes to scope? | Scope grows; you need a method to price it | ‘We will see’ |
Get the agreement in writing, including who owns what and what happens if you part ways midway. Ask a lawyer in your country to look at it if the sum is large.
Before you pay for anything, build the strongest case you can for what you are asking them to build. A written brief and some evidence of demand make quotes comparable, because every bidder is pricing the same thing.
What if you will never build it yourself?
Then path 4. Plenty of good ideas die in notes apps because their owners have no time, no skills, or the wrong interests. Posting the idea publicly means someone who wants a project can pick it up.
On Post your build ideas, posting is free and needs no account and no email. You type a name, a title of up to 90 characters and the idea itself in up to 4,000. Pricing thoughts and contact details are optional. Once published, the idea has a generated build prompt that a builder can copy into Claude Code, Cursor or Lovable, people can vote it up or down, and anyone who builds it can attach the result under “Built this?”.
The trade-offs are plain. Publishing is permanent: there is no edit and no delete, except removal of a post about a real person through the report page. You also give up control. A builder owes you nothing, and nobody is obliged to build it. What you gain is feedback from the votes and the chance that the idea exists.
Write it so a stranger can build it. See how the existing ones read: Fridge photo to three dinners names one input and one output, and Photograph a parking sign and know if you can park here states the situation in the title. You can browse the board for more. For other places that take ideas, see where to post app ideas.
What are the signs an app idea is not worth pursuing?
A quick no is a good result. These are signs to stop or change course:
- You cannot name a person who has the problem. “Everyone” is not a person.
- Nobody can describe the last time it happened. The problem may be real but too minor to act on.
- People like it but will not do anything. They will not give an example, try a manual version, or introduce you to someone.
- The workaround is free and good enough. If a spreadsheet already does the job, you need to beat a spreadsheet.
- The idea is a feature of an existing product. If the biggest app in the category could add it in a month, ask why they have not.
- It only works if you reach a huge number of users first. Network-effect ideas are the hardest category for a first project.
- You are not interested in the problem. Building and running a product takes many months. If you lose interest in week three, the idea stops with you.
None of these means the idea is bad forever. It means you need a narrower user, a smaller first version, or a different idea. Writing the reason down is useful either way.
What should a one-page idea brief contain?
One page is enough for a developer, an AI agent, a possible co-founder or a public post. If a section is hard to fill in, that is the part to research next. Copy this and fill it in.
Name: [working name] One sentence: For [specific person] who [has this problem], this [does one thing]. The problem: [Describe the last time it happened to someone you spoke with. What did they do? What did it cost them in time or money?] Who has it: [Role, situation, where you could reach them] What exists today: [Tools and workarounds people use now, and what each gets wrong] First version: [One workflow. What the user enters, what they get back. List what is NOT in version one.] Evidence so far: [Conversations held, what people did, not what they said they would do] Biggest unknown: [The one assumption that would sink the idea] My role: [I will build it / I will fund it / I will only provide the idea] How I will know it worked: [A behaviour you can observe, such as five people using it twice]
Once the brief is filled in, you can paste it into the free AI Coding Prompt Builder to get a scoped first-build prompt, or into the Idea Checker to see what is still missing.
Frequently asked questions
What is the first thing to do when you have an app idea?
Write it as one sentence naming a specific person, their problem and the one thing the app does. Then talk to five people who have that problem before you spend money or write code. The sentence tells you whether the idea is clear, and the conversations tell you whether it matters to anyone besides you.
How do I protect my app idea?
You mostly cannot protect the idea itself. The U.S. Copyright Office says copyright does not protect ideas, systems or methods of operation, only the way they are expressed. Patents need a concrete invention and professional help. In practice, move quickly, document who owns commissioned work in writing, and ask a lawyer for anything high-stakes. This is not legal advice.
Should I ask people to sign an NDA?
You can ask, but it is commonly reported that developers and investors decline to sign them for early ideas. Insisting may mean fewer useful conversations. For ordinary app ideas, sharing the problem and the plan matters more than secrecy. If you are sharing something genuinely sensitive, such as proprietary data, get advice from a lawyer first.
Can I build an app with no coding experience?
Often yes, for a first version. AI coding agents such as Claude Code, Cursor and Lovable can produce a working prototype from a clear description. You still have to describe the task precisely, test the result and fix mistakes. Treat it as a prototype for showing to users, and have an experienced person review anything that handles money or sensitive data.
Where do I post an app idea for free?
Post your build ideas takes ideas for free with no account or email, and each idea gets a generated build prompt a builder can use. Other communities and forums also take ideas, with their own rules. Whatever you use, write the idea so a stranger could build it, and remember that public posts are visible to everyone.
Is it worth hiring a developer for an app idea?
It can be, once you know the problem is real and can describe a small first version. Before that, a paid build mostly tests whether the thing can be made, not whether anyone wants it. Start with a fixed-price discovery phase, get ownership of the code in writing, and compare several quotes against the same written brief.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.