Should I build this app? Five questions to answer before you write a line of code

You have an idea for an app. Maybe you've carried it for months, maybe it landed last week and won't let you sleep. The question you ask friends, your cofounder, or the first developer you talk to is almost always the same: what would it cost to build. It's the wrong question, or at least the second one. The first is whether it's worth building at all.

I've built products for eight years, six of them on AI systems, and I've seen the pattern too many times. Someone pours months and savings into a tidy, well-made app that nobody wants. The code is clean. The problem is that it solves a problem nobody pays to solve. The five questions below are the filter I run an idea through before the first line of code.

1. Is there a real problem someone pays to solve?

This is where most ideas fail, and they fail quietly. The difference isn't between a real problem and an imaginary one. Almost any idea solves a real problem for someone. The difference is between a problem people feel sharply enough to pay for a solution, and one they politely acknowledge when you ask.

The test isn't "would you like this to exist?" Everyone says yes to that. The test is: what do you do instead today, what does the absence cost you, and would you pay what I'd charge for it? If people are already improvising with spreadsheets, paying someone to do it by hand, or have tried other products and abandoned them, you have a signal. If the reaction is "interesting," you don't.

The expensive mistake isn't building badly. It's building the wrong thing well.

2. Who, specifically, is the person who has it?

"Everyone" is not a customer. The broader the audience you describe, the more likely it is you haven't talked to enough real people. A good early product solves an acute problem for a narrow, clearly defined group, not a vague problem for all.

The concrete question: can you name ten people, with names and context, who have this problem now? If yes, you have someone to call before you build. If not, the first step isn't code, it's finding them and talking to them. Your app will have to be sold to someone in particular anyway. It's cheaper to learn who that someone is before you've spent the development budget, not after.

3. What is the simplest version that solves the problem?

Almost every founder confuses the product they imagine with the product they need to start. An MVP (minimum viable product) isn't a smaller, uglier version of your vision. It's the smallest thing that answers one question for you: do people use this, and would they pay for it?

The discipline here is brutal. One flow. One problem solved end to end. Everything you'd add "to make it complete" is really an untested assumption that delays the one piece of information that matters. With ai-aflat.ro, the AI assistant for Romanian legislation I built, the first version did one thing: answer questions about laws. It reached around 15,000 users and over 120,000 queries on a zero marketing budget, because it solved one problem clearly, not because it had many features.

4. What does it cost to keep running after you build it?

The cost everyone sees is the build. The cost that kills products is maintenance. An app isn't a one-off expense, it's a recurring one: servers, upkeep, security, updates, user support, changes when the platforms you depend on change. TCO (total cost of ownership) is the real figure, and we usually ignore it entirely at decision time.

The question worth asking before you start: if the product has moderate success but not enough to sustain itself, what does it cost you per month to keep it alive, and how long can you carry that from other sources? Many products don't die because they failed. They die because they succeeded a little, and the cost of keeping them running outgrew what the founder was willing to pay long term.

5. What don't you yet know, technically, about what you want to build?

You don't have to be an engineer to make the call. You do have to know your unknowns. Every idea has one or two technical assumptions everything hangs on: does that integration work the way you think? Can the AI model actually do what you assume? Is the data you need available and legal to use? Is the volume you're dreaming of feasible on the budget you have?

These unknowns are the cheapest to test at the start and the most expensive to discover at the end. A conversation with someone who has built something similar, or a small prototype of the risky part, costs days. The same discovery made after six months of development costs the whole project. If choosing the technology is what stalls you here, I've written separately on how to choose the right tech stack without being an engineer.

Build, use no-code, or buy something off the shelf?

Assuming you've cleared the first four questions, there's one more decision too many people skip: you don't necessarily have to build from scratch. Often the best move is not to build at all, at first.

The logic is simple. If an existing solution already solves the problem, you buy and save months. If the problem is standard but you can't find an exact fit, no-code gets you to validation fast and cheap. You build from scratch only when the core of what you do is different from everything that exists, and that's where your advantage lies. Before you pick the agency to build it, it's worth being sure whether you want advice or execution. The difference between a Tech Coach and an agency is exactly the one that tells you whether you're already at the build stage.

The decision framework: what to do with the five answers

Run the five questions one at a time and be honest. You're not looking for five yeses, you're looking for the weak link.

• If you fail on the problem (nobody pays), you stop and revalidate. It's not a code problem.
• If you fail on the customer (you can't name ten people), the first step is ten conversations, not a developer.
• If you fail on the simplest version (you want to build everything), you cut until one flow remains.
• If you fail on the cost to run (you can't sustain it on moderate success), you rethink the model before, not after.
• If you fail on the technical unknowns (you don't know if the hard part is feasible), you test that assumption before anything else.

The honest answer, after the five questions, is very often "not yet, not like this." That's not a failure. It's the exact moment you save the six months and the money you'd have spent building the wrong version. A clear "not yet" is worth more than a foggy "yes."

I run this exact exercise with founders every week. I don't write your code and I don't make the decision for you. I help you run the idea through this filter with someone who has built products at real stakes, and you see for yourself where it stands. Who's asking the questions matters. The rest of the story is on vladtudor.com.