Produto Digital
Estratégia Digital
Aplicativos
Validação
Gestão de Tecnologia

Is it worth making an app? The honest checklist before spending your first dollar

The right question is not “how do I make an app”, but rather “this problem really needs an app to be solved”.

Is it worth making an app? The honest checklist before spending your first dollar

Almost every week someone tells me they are going to make an app. A public manager who saw an app from another city. An entrepreneur with an idea. A director who wants to "digitize" the company. The energy is good, the intention is legitimate, and yet the first question I ask usually deflates the conversation: why an app?

It's not provocation. It's the question that saves the most money. Applications have become synonymous with modernity, and that's why many people decide to build one before knowing whether it solves the problem at hand. The result is predictable: months of development, a blown budget and an app that no one downloads, or that they download, use once and forget about.

This text is an honest checklist for those who are before the decision. The intention is not to discourage, it is to qualify. A good app starts with a good question, and most projects fail before the first line of code.

Step 1: what's the real problem?

Before talking about the app, describe the problem without mentioning the solution. "I want an app" is not a problem, it's a solution looking for justification.

The real problem sounds different: "my clients give up because scheduling is confusing", "residents can't open a ticket to the city hall", "my team wastes time recording information on paper". When you can state the problem without the word "application", then you can evaluate whether an app is the best answer, or whether a website, a well-designed spreadsheet, an organized WhatsApp or a process adjustment would solve it at a fraction of the cost.

Often the smartest answer is not technological. And that's a difficult conclusion to accept when you've already fallen in love with the idea of ​​the app.

Step 2: does the app need to be in the person's pocket?

Native application, installed on the cell phone, makes sense when use is frequent, when it requires device resources (camera, GPS, notification, offline use) or when the experience needs to be very fluid and recurring. Think of a transportation, banking, messaging app, daily use, hands-on.

If use is sporadic, someone opens it once a month to resolve something specific, asking someone to download, install and update an app is too much friction for too little benefit. In these cases, a responsive website usually delivers the same value without the installation barrier. A city hall that wants citizens to consult IPTU does not need an app; You need a page that works well on mobile.

The practical question: Will the person use this often enough to justify taking up space on their phone? If the answer hesitates, it's probably not an app.

Step 3: you have breath to maintain, not just to build

Here is the most common miscalculation. People budget for building the app and forget that the real cost is maintenance. An application is not a work that is completed and finished, it is an organism that needs continuous care.

Operating system updates and breaks things. Bugs appear. Users ask for improvements. Security issues arise. App stores change rules. All of this requires a team, or at least a committed supplier, after launch. An abandoned app ages quickly and, in a short time, stops working.

Before approving the construction budget, ask: who will take care of this a year from now? If the answer is "we'll see later", the project is already fragile. App without a maintenance plan is money with an expiration date.

Step 4: how will you measure whether it was worth it

A project without success criteria cannot fail or succeed, it just exists. And this is dangerous, because it consumes resources without accountability.

Before you begin, define what success in numbers means. How many people need to use it? How much time should the operation save? How much should attendance fall? How much should the conversion rise? These targets don't have to be perfect, but they do need to exist. They turn "we made an app" into "we solved a measurable problem."

In the public sector, this is even more relevant. Resources are scarce and accountability is a duty. A municipal app that costs a lot and no one uses is not just waste, it is a decision that needs to be justified to society.

Critical reflection: the app as vanity

It's worth naming the elephant in the room. Most applications are born out of vanity, not necessity. Company wants to look modern. Manager wants to have something to show. Founder means he has an app. These are human and understandable motivations, but they are terrible as an investment basis.

The symptom is clear: when the conversation starts with the technology ("let's make an app with AI") instead of the problem, there is usually vanity at the helm. The right technology is the consequence of a well-understood problem, never the starting point.

There is also the opportunity cost. Every dollar invested in a vanity app is a dollar that didn't go towards the problem that really mattered. In organizations with a tight budget, and almost all of them are, this account is decisive.

What remains

Making an app can be one of your organization's best decisions or one of its most expensive. The difference is not in the quality of the code, but in the quality of the question that came before it.

If, after going through these steps, the app still proves to be the best answer, clear problem, frequent use, breath to maintain and defined success metric, then yes, it's worth it, and it's worth doing well. If any of these things shake, perhaps the best app is the one you decided not to build.

If you are at this decision point and want to think about the problem before committing to a budget, it's worth talking. On the blog there are other texts about the product, software costs and digital strategy that help you make this decision with more confidence.

Also read