We have seen well-built software fail and roughly-built software succeed. The difference is almost never the quality of the code. It is whether these questions had answers before the work started.
1. Whose problem is this, specifically?
Not a market segment. A role, in a type of organisation, with a task they currently do badly. If the answer is 'businesses', nobody has done the thinking yet.
2. What do they do today instead?
Every problem worth solving already has a workaround — a spreadsheet, an agency, an intern, or simply tolerating it. That workaround is your real competitor, and it has the enormous advantage of already existing.
3. What has to be true for this to be worth building?
Write down the assumption the whole thing rests on. Then design the first release to test that assumption as directly and cheaply as possible.
4. What is the smallest version that changes someone's day?
Not the smallest version you could demo. The smallest version someone would be annoyed to lose. That is the boundary of release one.
5. How will we know it worked?
One measurable thing, agreed before launch. 'Positive feedback' is not it. 'Time to process a claim' is.
6. What are we deliberately not building?
An out-of-scope list is more useful than a requirements list, because it is the one that gets tested under pressure. Without it, every conversation quietly adds scope and none removes it.
7. Who decides?
Name the person. Projects with a single decision-maker who is available weekly move at roughly twice the speed of projects that decide by committee, and the resulting product is more coherent.
8. What must this integrate with?
List the systems, and find out early what they actually expose. Integration assumptions are the single most common cause of estimates being wrong by a factor rather than a percentage.
9. Who runs it after launch?
Someone has to monitor it, support the users, apply the updates and fix things at inconvenient times. If that person or arrangement does not exist yet, the project is not funded — only the build is.
If you cannot answer them all
That is normal, and it is not a reason to delay indefinitely. It is a reason to make answering them the first, short, deliberate phase of work rather than something discovered expensively during the build. Two weeks spent here routinely saves months later, and the output is useful to you regardless of who ends up doing the engineering.