Diagnosis before AI: what makes a solution actually work

Diagnosis before AI is the stage that defines which problem a solution will solve, for whom, with which flows and in what order, before any code is generated. With AI tools, building an app became fast and cheap. Deciding what to build is still the hard part, and it is where an AI solution gets it right or wrong.

In this article we show why the speed of AI has made this stage matter more, what a diagnosis needs to answer, where AI itself helps with it and what still depends on human judgment.

Building got fast. Deciding is still slow.

Vibe coding changed the math for anyone who creates software. Instead of writing every line, a person describes what they want in natural language, and tools such as Lovable, Bolt, Cursor and Replit generate the application. People without a technical background can reach a first working version in little time.

For testing an idea, this is excellent. The gap between noticing a problem and seeing a working screen has shrunk a lot, and experimenting became cheap.

The side effect is less visible. When building costs little, it is easy to skip the part that comes first: understanding the context, listening to the people who will use it, choosing what goes in first. The tool delivers exactly what was asked. If the request came from a wrong assumption, it delivers the wrong assumption, working.

Why a fast solution without diagnosis tends to fail

Many solutions that do not take off fail for a reason far from the code. The system runs. What is missing is a fit with the real problem, with the people using it and with the market the company operates in. Three patterns show up often.

It solves the wrong problem. The pain described in the first meeting is almost never the whole pain. In a hypothetical example, a manager asks for a KPI dashboard. Talking to the team, it turns out the numbers arrive late because three areas type in the same data. The finished dashboard shows a late number with a nicer look.

Nobody uses it. The solution was designed around the person who asked for it, and the people who do the work were never heard. In the first week, the team goes back to the spreadsheet, because the new flow ignores an exception that happens every day.

It cannot grow. Each generated screen makes sense on its own. Without an upfront decision about data, permissions and integrations, the whole becomes hard to change, and the second version costs more than the first.

In all three cases, the speed of AI only brought forward the moment the problem appears.

What diagnosis before AI needs to answer

A good diagnosis turns a hunch ("we need an app for this") into a clear direction. It answers a short set of questions, and every unanswered question becomes a risk down the road.

The last row is usually the most forgotten. Without a result defined upfront, any delivery looks like a success at launch and turns into doubt a few months later.

What a diagnosis delivers

At Devvo, diagnosis serves companies that have a pain or an opportunity and do not yet know where to start. It goes through six stages, and each one leaves something concrete in the client's hands.

1. Problem and context. What happens today, where it hurts and why, written in language that both leadership and operations recognize.
2. Users and needs. Who will use the solution, at what moment and with what constraints. This is where conversations with the people who do the work come in.
3. Requirements and flows. The rules the solution must follow and the path of each task, including the exceptions that show up every week.
4. Validated clickable prototype. Clickable screens that users test before development. It is the point where the assumption meets reality, at a low cost to fix.
5. Product roadmap. What comes first, what comes next and what stays out for now.
6. Investments, risks and priorities. How much each phase costs, what can go wrong and what needs to be decided before starting.

With this material, the company decides whether to build, with whom and in what order. It can also compare proposals against a described problem instead of a promise.

Where AI helps within the diagnosis

AI also speeds up the diagnosis itself. We use these tools in several parts of the work:

• Generating initial hypotheses from the notes of the first conversations.
• Creating quick versions of screens to test a flow with users earlier.
• Turning requirements into drafts that are then reviewed and adjusted.
• Suggesting alternative navigation flows to compare.

This support shortens stages and makes it possible to explore more alternatives in the same timeframe. The diagnosis reaches more prototype versions before closing, and each version tested is one less assumption going into development.

What is still human judgment

There is a part of the diagnosis that no tool does: critical analysis. It includes:

• Interpreting the nuances of the client's market and industry.
• Understanding the real pain of users, which often differs from the reported pain.
• Assessing whether the solution holds up as a business.
• Setting priorities when two areas want different things.
• Choosing the technology path.
• Planning the structure so the solution can grow.

These decisions require experience, a reading of context and someone accountable for them. They define cost, security, scale and the ability to evolve for years to come. A language model suggests paths with great confidence, including the wrong ones, and takes responsibility for none of them.

Signs the diagnosis was skipped

Some situations indicate that building started too early:

• The app is finished and nobody can say which number it was supposed to change.
• Every follow-up meeting adds a new screen to the scope.
• Users ask for changes to the main flow, not to details.
• The team keeps a parallel spreadsheet "just in case".
• The second version is already being discussed as a rewrite.

When two or more of these signs appear, it is worth stopping and doing the diagnosis now. It costs less than continuing to build on top of an assumption.

AI prototype, yes. Production without review, no.

Using vibe coding to validate an idea is part of a good diagnosis. The clickable prototype can even be built in one of these tools and tested by real users within a few days.

The care lies in the transition. A validated prototype shows that the flow makes sense to its users. It does not show whether the app can handle paying users, third party data and attempts at unauthorized access. That is a different job, with a different checklist, covered in the article on vibe coding and AI-built apps in production.

Product diagnosis and operational diagnosis

The two terms often appear together, and the difference lies in the starting point. Diagnosis before AI starts from a solution someone wants to build and checks whether it solves the right problem. An operational diagnosis starts from the whole operation and looks for where it gets stuck, without assuming the answer is software.

Often one leads to the other. The operational diagnosis points to the bottleneck, and the product diagnosis designs the solution for it. In other cases, the assessment shows that the answer is changing a routine, and no technology needs to be built.

Speed with direction

AI made execution faster, and that is good for everyone who builds software. What it does not answer is the question that comes first: what should be built, why and which result it needs to move.

The combination that works brings both together. Diagnosis provides the direction, AI provides the speed, and the solution starts out with a better chance of being used, paying for itself and growing without having to be rebuilt.