Do I need to keep my idea secret so no one steals it?

Almost never worth worrying about. Ideas are common and execution is the hard part, so talking to potential users teaches you far more than secrecy protects you. The real risk is not theft, it is building something nobody wants because you never described it to anyone who could tell you.

Should I learn to code first, or hire someone?

Neither, yet. Both are decisions you can only make well once the idea is written down clearly. A clear one-page description lets you judge whether a simple tool, a hire, or waiting is right. Get the idea legible first; the how-to-build question is much easier to answer after that.

How do I know if my idea is any good?

You mostly cannot from your own head, which is why the early work is about describing it plainly and putting it in front of a few real people who have the problem. Their reaction, especially whether they would use or pay for it, tells you far more than any amount of thinking alone.

Is it too early to talk to a builder?

It is early to hire one, but not to write the idea down as if you were about to. A one-page description of who it helps, the problem, and the core action is exactly what a builder needs to scope and price. Doing that first makes any later conversation short and cheap.

I Have an App Idea, What Do I Do First?

An idea feels enormous while it lives in your head, and paralysing when you try to picture the whole thing at once. The first move is not to build, hire, or research the market. It is smaller and quieter: get the idea out of your head in a form someone else could read and understand.

Plain English

Scope: The clear boundary of what a build includes and, just as important, what it leaves out.
Core action: The single most important thing a user does with your idea, the reason it exists.
Brief: A short written description of your idea that a builder can read, scope and price.
Assumption: Something you are quietly taking as true that might not be, worth writing down to test.

Step by step

Write the idea in one plain sentenceForce yourself to describe the whole thing in a single sentence a stranger would understand: who it is for, what problem it solves, and what they do with it. If you cannot do it in one sentence yet, that is useful information, it means the idea is still doing several jobs at once and probably needs to be narrowed. Keep rewriting until one clean sentence holds it, reading it aloud to check it makes sense to someone who has never heard the idea. This sentence becomes the anchor for every later decision, and you will return to it whenever a choice feels hard, because it quietly reminds you what the thing is actually for.
Name the one person it is forIdeas that try to help everyone usually help no one. Picture one real person with the problem: their situation, what they do now instead, and why that is annoying enough to change. Give them enough detail that you could recognise them. Building for one specific person makes every choice easier, because you can ask what they would actually need rather than guessing at a faceless crowd.
Find the single core actionEvery idea has one thing that matters most: the booking gets made, the invoice gets sent, the two people get matched. Everything else is support around that one act. Name it plainly. This is the thing that, if it worked and nothing else did, would still be worth something. Knowing your core action is what lets you build the small, honest first version instead of the sprawling everything version.
List what you are assuming without proofWrite down the things you are quietly betting on: that people want this, that they will pay, that they will change how they currently do it, that they will trust something new with their problem. These are assumptions, not facts, and naming them stops you building an expensive answer to a question no one asked. The riskiest assumption is usually whether anyone actually wants the thing, and that is the one worth checking before you build. Once the list is written, rank it by how much damage each wrong assumption would do, and you have a plain to-do list of what to test first, cheaply, before committing any real time or money to construction.
Decide the smallest thing that would teach you somethingYou do not need the finished product to learn whether the idea holds. Ask what the smallest version would be that lets a real person do the core action and tell you if it helped. That might be a rough build, or it might be no build at all yet, just a manual version done by hand. Deciding this now stops you pouring months into something before you know it is worth it, and gives a builder a clear, priceable first target instead of a sprawling wish list.

No pressure

Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

I have an idea for an app, what do I do first?

Step by step

Questions, answered

Two doors. Same senior team.