App Prototype: What to Validate Before Developing an Application

You may appear to have a clear idea: an app that lets your customers submit requests while your team manages them without relying on calls, messages, and spreadsheets. But when you try to explain it, uncomfortable questions arise: what should each user see? Which steps are truly necessary? What happens if information is missing? And is a mobile app actually needed, or would another solution be enough?

An app prototype helps answer these questions before development begins. It does not yet prove that the system works with real data, nor does it replace technical testing, but it allows you to review how it would be used, which features justify the first version, and which decisions remain open. By the end of this article, you will be able to decide whether your idea is ready to be prototyped and what you should validate at that stage.

Hypothetical starting point: a company wants to organise service requests

Imagine, hypothetically, a small maintenance company. Its customers get in touch by phone, email, and messaging to request a visit. A team member gathers the details, records them in a spreadsheet, and passes the job on to the available technician.

The company proposes an app with a broad request: “Customers should be able to request a service and check its status.” The idea seems simple, but it brings together several separate decisions:

• The customer must identify the equipment or location the request relates to.
• The internal team needs to review the information before assigning a visit.
• The technician needs to know which work is pending and update its status.
• The company must decide what information the customer will see at each stage.

Building these features directly would require many decisions to be made during development. A prototype makes it possible to bring them onto a screen earlier and discuss them through specific examples.

Observable issue: the idea does not yet define real-world use

The issue is not a lack of attractive screens. What is missing is a shared description of the actions and rules that underpin the process.

For example, “requesting a visit” could mean that the customer selects a date, suggests several time slots, attaches images, or simply leaves a notice so that the company can contact them later. Each alternative changes the information required, the team’s workload, and the application's scope.

It is also useful to separate two issues that are often mixed together:

• The user experience: what a person sees, what they can do, and how they progress through the app.
• The technical operation: where data is stored, how other tools are connected, what permissions exist, or how errors are handled.

A prototype focuses mainly on the first. It can represent buttons, forms, screens, and transitions to check whether the user journey makes sense. Integrations, security, account management, and the availability of an external tool must be assessed separately before turning a simulation into an operational solution.

Goal analysis: defining what needs to change

In the hypothetical case, the goal should not be “to have an app”. It could be defined as follows: enable the customer to communicate a need with sufficient information, and enable the team to manage it with a visible status.

This definition helps because it makes it possible to assess each feature by its contribution to the outcome. If a screen does not help record, review, assign, or check a request, it may not belong in the first version.

Before creating the prototype, it is worth clarifying at least the following decisions:

1. Who will use it. A customer, a coordinator, and a technician do not need the same screens or permissions.
2. What the main action is. In this example, submitting a request and tracking its progress.
3. What information is required. Location, type of issue, description, images, or a contact method are possible fields; not all of them need to be mandatory.
4. Which statuses exist. “Received”, “under review”, “scheduled”, and “closed” could be hypothetical statuses, provided the company can explain what each one means and who can change it.
5. How it will be recognised that the user journey is well defined. For example, a person can complete a request without needing instructions, and the team understands what to do next.

The goal must be validated by the person who understands the day-to-day operation. A prototype makes assumptions visible, but it cannot decide by itself which commercial or operational rule should be applied.

Proposed scope: representing the minimum user journey

For this hypothetical case, the first prototype does not need to represent the entire business. It could be limited to the journey that makes it possible to test the main proposition:

Elements such as payments, invoicing, automatic notifications, complex reports, connections with existing software, or advanced user management would initially remain out of scope. Not because they lack value, but because adding them before validating the main flow may make review more difficult.

The scope of a prototype should also state what it does not simulate. For example, a calendar screen can help discuss availability and booking, but it does not confirm that it can later connect to the calendar the company already uses. That dependency requires technical review and access to the relevant tool.

Solution and validation: moving from screens to verifiable decisions

Once the scope has been defined, a navigable representation of the main screens is created. The person reviewing the prototype should not simply comment on colours or buttons. They should go through specific situations.

In the example, one useful validation scenario would be this:

A hypothetical customer needs to report a fault. They select the location, describe the issue, attach an image if they have one, and submit the request. They then see a confirmation and can check that the report has been received. The coordinator opens the details and finds the information needed to assign the work.

This journey makes it possible to identify practical questions:

• Does the customer know what information they need to provide before submitting?
• Are there fields being requested that are not used?
• Does the team understand when a request is ready to be assigned?
• Is the status shown to the customer clear and consistent with internal operations?
• What should happen if the request is incomplete or duplicated?

Validation is more valuable when it is carried out with people who would take on each role. Their observations do not require every preference to be included, but they help distinguish a usability issue from a secondary request.

After the review, each finding should become a decision: keep a feature, modify it, postpone it, or exclude it. In this way, the prototype stops being a visual presentation and becomes a foundation for defining requirements, acceptance criteria, and development priorities.

Transferable lessons for your project

The case is hypothetical, but the logic can be applied to many application ideas: a customer portal, an internal tool, a booking system, or an app for managing services.

An app prototype is particularly useful when you understand the problem but still need to clarify the user journey, user profiles, and the content of the first version. It can also reveal that a mobile application is not the most suitable solution: if use takes place mainly from an office computer, a web application may be a better fit. That choice depends on the users, the context of use, and real needs—not on the project’s initial name.

The important decision is not how many screens the prototype will have. It is which uncertainty you want to reduce before development: how the solution will be used, priorities, business rules, or dependencies on existing systems.

If you need to turn an idea that is still open into a reviewable scope, you can tell AVSISTEC about your application project. The starting point will be to clarify the problem, the users, and the decisions that should be validated before choosing a technical solution.