What to build: the shape of an idea that works
This is not a post about finding an idea. If you are reading this you almost certainly have one already, probably one you have been turning over for a while.
It is about something more useful and much less discussed: whether the idea you have is the right size. That single question decides more launches than talent does. The most common reason a first app never gets finished is not that the person could not build it. It is that what they set out to build quietly grew past what anyone could finish alone, and they ran out of will before they ran out of ideas.
So here is how to look at yours.
The four tests
One job. Say what your app does in one sentence, without the word "and". If you need the "and", you have two apps. Pick the one that would be missed most if it vanished tomorrow.
One kind of person. Not you and your clients and your suppliers. One. The moment you have two kinds of user you have two apps that have to agree with each other, and the agreeing is the expensive part. It can come later, and it will be much easier once the first half exists.
Something already done by hand. This is the strongest signal of the four. If you are currently doing the job in a notebook, a spreadsheet, a group chat or your head, then you already know the real rules, including the awkward exceptions nobody would think to tell you. You are not guessing at what people want. You are copying something that already works, which is a far easier problem.
Done regularly. Weekly is a good bar. A thing people do once a year is a thing they will not remember your app exists for. A thing they do every week is a habit you can slot into.
Mine passed all four almost by accident. I am an esthetician. I needed to write up what I did in a treatment room, for one kind of person, between clients, several times a day. I was already doing it on paper. I was not designing a product, I was replacing a notebook, which turns out to be the best possible starting position.
What too big usually looks like
A few shapes come up again and again, and all of them are worth spotting early.
It only works if lots of people join. Anything where the value comes from other users being there. A marketplace, a community, two sides matching each other. These are not beginner projects, not because the software is hard but because an empty one is useless and filling it is a completely different job from building it.
It needs data you do not have. If step one is getting access to someone else's system, or a licence, or a dataset you would have to buy, that is a project of its own sitting in front of the project.
It has a dashboard before it has a thing to measure. Reporting, charts, analytics. All of that is describing work the app does not do yet. It is also the most satisfying thing to imagine, which is why it turns up so early in people's plans.
You cannot picture one person using it on a specific day. If you cannot say "on Tuesday, Sarah opens this and does X", the idea is still an intention rather than a design.
Narrowing is not giving up
This is the part people resist, and I understand why. The version in your head is the ambitious one, and cutting it down feels like admitting you cannot do the real thing.
It is the opposite. A narrow first version is how you get to the ambitious one, because it is the only version that ships, and shipping is what teaches you which half of your plan was wrong. Everything you believe right now about what people want is a theory. Some of it is right. You find out which parts by putting something real in front of someone, not by building for longer.
The bigger version does not disappear. It waits, and it gets better while it waits, because by then you will know things about the problem you cannot know yet.
A practical way to decide
Write down everything you imagined the app doing. All of it, in a list, without editing.
Then mark the one line that, if the app did only that, would still be worth opening. Not the most impressive line. The one you would miss.
That is version one. Everything else on the page is version two and beyond, and it is not lost, it is just later. Keep the list, because it becomes your plan for the months after launch and you will be glad not to be starting that from scratch.
If the list has nothing on it that survives that test on its own, that is worth knowing now rather than six weeks in. It usually means the idea is a collection of features rather than a job, and it can often be fixed by asking who exactly you pictured using it and what they were trying to get done.
None of this requires any technical judgement, which is the point. It is judgement about the work you already understand. If you want the wider argument about why the code is not the hard part, it is here, and there is a free walkthrough of the first steps when you are ready to start.