App idea validation: what a company should decide before investing

Most enterprise applications don't fail because of bad code. It fails because no one validated, before signing the contract, whether the product solved a problem that someone was willing to pay to solve.

I have seen this script repeated in companies of very different sizes. A director brings a convincing idea, the team creates a scope, the technology area estimates deadlines and costs, and the budget is approved. Six months later, there is a functional, beautiful app, on schedule, and almost no one uses it. The project was a success in execution and a failure in product.

This text is for those who decide. If you approve a budget, demand results or account for the bill at the end of the quarter, idea validation is not a technical formality that the product team resolves on its own. It's a capital allocation decision, and it deserves the same rigor you would apply to any other relevant investment.

Why validation is a financial decision, not a product detail

Building software is expensive, but the cost of building it is rarely the biggest risk. The biggest risk is the opportunity cost: each team allocated to an app that no one wants is a team that is not solving another real problem for the company.

When an organization decides to invest in an application without validating the idea, it is making a bet. Bets are part of any business. The problem is betting big without any evidence, when it would be possible to bet low first, buy cheap information and only then decide whether it is worth betting big.

Validation, seen from this angle, is risk management. You spend little to find out if the problem exists, if the public cares and if the model closes, before committing the full budget. It's the difference between testing the water temperature and diving in head first.

The thesis: the company must buy evidence before buying a product

My position is straightforward. Before approving the construction of an application, the company should require evidence of three things: that the problem is real and relevant, that there is an audience willing to change their behavior, and that there is a plausible path to return.

None of these three answers require building the entire app. All of them can be answered with a small investment and a short period of time. Anyone who reverses this order, builds first, discovers later, is outsourcing to the market a question that they could have answered in the office, for a fraction of the cost.

This does not mean blocking innovation with bureaucracy. It means that the enthusiasm of the idea sponsor needs to be confronted with evidence before becoming a budget line.

What the company needs to validate before approving the investment

The problem is real and worth money

The first question is not “is the app a good idea?”, but “what problem, whose problem, how often and at what cost?”. A problem that bothers you rarely justifies a product. A problem that is expensive, happens frequently and has no good solution is where the return lives.

In a company, this means talking to the people who experience the problem, customers, operators, internal areas, before any mockup. If pain doesn't appear consistently in these conversations, the app won't create it.

The common mistake here is validating the solution instead of the problem. Ask "would you use an app that does X?" and almost everyone says yes, out of politeness. Ask “how do you solve this today and how much does it cost you?” and the truth appears.

There is an audience and they are willing to change their behavior

Every application requires a change of habit from those who use it. Changing habits is difficult, even when the solution is better. Validating means understanding whether the pain is great enough to overcome inertia.

An honest test is to observe whether people already try to solve the problem on their own, with spreadsheets, message groups, improvised manual processes. This spontaneous effort is the most reliable sign of real demand. Where there is gambiarra, there is usually a market.

There is a return path that closes the account

This is where corporate decision-making differs from enthusiasm. An app can solve a real problem and still not make financial sense. Validation needs to estimate, even if crudely, how the investment returns: new revenue, cost reduction, customer retention, internal efficiency.

If no one at the table can explain how the app pays its own bill within a reasonable timeframe, that's not a detail to resolve later. That's a reason not to approve it yet.

How to validate with little money and a short deadline

Validating is cheap compared to building. Interviews with real customers, a capture page to gauge interest, a navigable prototype with no code behind it, a manual pilot where the team runs behind the scenes what the app would do, all of these tactics generate evidence at a marginal cost.

The goal is not to prove that the idea is good. It's trying to bring it down with as little expense as possible. An idea that survives honest attempts at invalidation is an idea worth investing in. Teams that validate to confirm what they already wanted to hear are not validating, they are collecting applause.

A small pilot, with a limited group of real users, often teaches more than months of internal discussion. It is also where the company discovers hidden costs: integration with legacy systems, support, training, maintenance, items that rarely appear in the initial estimate and that weigh on the actual budget.

The risks that validation does not eliminate, but makes visible

Validating reduces risk, not zeroes it. It's worth being honest about limits.

The first risk is convincingly validating the wrong problem. An influential sponsor can guide the conversation to the answer you want. That's why validation needs independence: whoever collects the evidence cannot be the one who most wants to hear "yes".

The second is false precision. Research with pretty numbers gives a feeling of certainty, but product decisions are based on consistent qualitative signals more than on initially inflated metrics. Be careful with slides full of percentages that don't stand up to a question.

The third is cultural. In organizations where questioning the boss's ideas is risky, validation becomes theater. The team pretends to test, everyone pretends to believe, and real learning only arrives when the product is already on the market and the money is spent. Validation only works when the company accepts hearing "no" early, including from those who proposed the idea.

There is also the issue of data and compliance. If the app will collect information from customers or citizens, LGPD enters the account from validation, not as a stamp at the end. Discovering late that the data model is legally unfeasible is expensive and avoidable.

Validating is protecting focus, not delaying innovation

The most common objection to validation is that it takes time. In practice, what really delays innovation is building the wrong thing and having to start over. Well-done validation is the fastest way to the right investment, because it eliminates early on bets that would cost dearly and deliver little.

The question a leader should ask before approving an app's budget is not "how much does it cost to build?" It's "what do we need to know to be confident that it's worth building, and what's the cheapest way to find out?" Anyone who learns to ask this question stops financing orphan products and starts financing bets with evidence.

If your company is about to invest in an app and the conversation started with the technical scope rather than the business problem, it might be worth pausing and validating first. I have other texts on the blog about validation and product construction roadmaps, and I am available to exchange ideas with anyone at this decision point.