Building with agents

The feasibility check: how to know if an app idea is worth building before you build it

I stood in a forest and asked my phone to build a tree identifier. It did not start writing code. It asked whether the idea could work at all.

10 August 2026 · written by the team behind freeapp.ai

I was walking in a forest with my phone in my hand, and I asked it, out loud, to build me an app that identifies a tree from a photo.

I expected what every AI coding tool gives you: immediate typing. A project skeleton, some screens, a camera permission, a satisfying wall of green diffs. Progress you can watch.

Instead it stopped and ran a feasibility check. Two questions, asked before a single file was created. Can the hard part of this actually work? And is this worth building at all?

I build the thing that did it, so treat my enthusiasm accordingly. But I did not design that specific moment, and being surprised by your own product in a forest is a decent sign that the behaviour is worth writing down.

Why the code was never the risk

Break the tree app into pieces and one of them is not like the others.

Screens, a camera, an account, a server, a database, a way to show a result: that is a known shape. Thousands of apps have it. Any competent tool, human or otherwise, can produce it, and if it comes out wrong you can see that it is wrong within a minute of opening the app.

Then there is the actual product: given a photograph of a leaf taken by a person who is not a botanist, in whatever light the forest happens to offer, can you name the species reliably enough that somebody trusts the answer?

Nobody on my machine had ever proven that. It is the only part of the build where the honest answer was "probably". Everything else was carpentry.

This is the failure that does not announce itself. You do not lose a week to bad code, because bad code shouts. You lose a week to good code wrapped around an assumption that was never going to hold, and you find out at the end, when the app runs beautifully and gives wrong answers.

What a feasibility check actually is

It is not a plan, and it is not a specification. Both of those assume the thing works and describe how you will arrange it. A feasibility check comes before that and asks whether there is anything here to arrange.

Four steps, in order.

1. Look for prior art first. Somebody has usually tried the hard part already. If leaf identification is a solved problem with a public model behind it, the correct outcome of the check is to say so and skip straight to building. Searching is cheaper than proving.

2. Split what you know from what you are guessing. Write two lists. Known: screens, storage, accounts, payments, the whole carpentry pile. Unknown: the one or two claims everything else depends on. If the unknown list is empty, you do not need a feasibility check and saying that out loud is a valid verdict.

3. Prove the unknown with throwaway code, under a cap. Not a prototype you will keep. A scrap that answers one question, with a time and money limit set before you start. Twenty photographs through a candidate model tells you more than a week of architecture, and you delete it afterwards without regret.

4. Return a verdict, and let it be no. Feasible, feasible with a named constraint, or not worth building. A check that can only ever say yes is not a check, it is a ritual, and everybody involved learns to skip it.

The second question, which is the harder one

"Can it work" is a technical question and it has a technical answer. "Should this exist" does not, and it is the one that quietly wastes most of the money.

Every person who has shipped software has shipped something that worked perfectly and mattered to nobody. The tooling of the last two years has made that failure cheaper to reach and therefore easier to repeat: when building is nearly free, the cost moves entirely into building the wrong thing, faster than ever, and with more polish.

So the check asks what happens if the answer is yes and it works. Who uses it on a Tuesday? What are they doing instead today, and is that alternative bad enough that they would change? If those questions have no answer, the honest verdict is not "build a smaller version". It is "do not build this".

Why the assistant should ask, not you

You already know you should do this. So does everyone. It is in every product book written in the last thirty years, and it still does not happen, for a reason that has nothing to do with knowledge: at the moment you have the idea, you want to build it, and the check is a speed bump between you and the fun part.

Which is exactly why the tool should be the one raising it. Not as a form to fill in, and not as a lecture. As a short, cheap step that happens automatically before the code starts, that you can override in a sentence, and that ends with a plain verdict you can argue with.

Standing in a forest, wanting my app, I would not have run it myself. That is the whole point.

What it costs

Minutes, in the cases that matter. Searching for prior art is one query. Splitting known from unknown is two lists. Proving the unknown is a script and a handful of test inputs, inside a cap you set in advance so a check can never become the project.

Against that: the week you did not spend building a beautiful interface for an idea that could not work, or an app nobody wanted. That trade has never once gone the other way for me.

The next time something asks you to build an app in under a minute, notice which question it asks first. If it goes straight to how, it has quietly decided the whether on your behalf.