Web Application Development for Business: What to Prepare Before a Quote

Start with one job that has to get done

A request such as "we need a client portal" leaves many questions open. Does the client submit a request or confirm an order? Is the status changed by an employee or taken from the ERP? Can the client change something after sending it?

This guide helps you prepare those answers before the conversation turns to technology and price. For an overview of the kinds of systems a project can cover, see custom web application development.

Choose a workflow you can describe from the starting event to a verified finish. A good starting point is not "a dashboard", but "a manager needs to see which service requests are waiting to be scheduled and assign them to a technician".

Talk to the person who does that job today. Ask them to show the latest real example, with personal or confidential data removed. That is how you find documents, checks and exceptions nobody recalls in a general meeting.

Write down what still has to be done by hand and what the user considers finished. "The request was sent" and "the request was accepted into the scheduling system" can be two different states. The user needs to see that difference.

An example workflow for scoping

The following example is hypothetical. An equipment maintenance company wants to streamline how service visits are reported; it is not a presentation of a real project or its results.

This table does not choose a programming language. It surfaces decisions that would otherwise stay hidden behind a few sketched screens.

Decide who may see and change each record

Labels such as "client", "employee" and "administrator" are not a full specification of permissions. Two clients can have the same role and still must not see each other's requests. A technician may need access only to assigned visits.

For every important record, state who can view, create, change, approve and export it. Clarify access between branches or between different companies in the same system in particular.

OWASP's authorization guidance recommends checking permissions on every request. A hidden button, on its own, is therefore not an adequate access-control criterion.

In the hypothetical service portal, one check could read: client A cannot open client B's request even when they type its address directly. That example is more specific than "the system needs to be secure", and it is not a guarantee of complete security.

Clarify where the data comes from and what up to date means

If the application uses an existing ERP, CRM or another system, list the data and actions you need. For a status display, read access may be enough. Submitting an order also needs a supported write path, with a check that the transfer succeeded.

State which system confirms the final value. If a customer address can change in two places, agree what happens when the values differ. Also define how the user recognises a stale display.

Before estimating the integration, collect:

• the name and version of the existing system, if known;
• a contact who can approve access;
• available documentation and the option to test;
• the required actions, direction of transfer and expected frequency;
• an example of a failure and the person who resolves it.

If the system supplier has not yet confirmed access, mark it as an open assumption. Web application development does not remove an external system's limits just because the integration is listed in the project description.

Separate mobile friendliness from working offline

For every important task, state the device, browser and conditions of use. Checking a status on a phone is not the same requirement as entering findings in a warehouse with an unreliable connection.

MDN's guide to progressive web applications explains that advanced browser capabilities require checking support and providing a suitable fallback. Camera, notifications and offline work should therefore be verified on the users' actual devices.

For offline work, define the behaviour concretely. Can the user only view previously loaded data, or create new records? When is a record sent, and how is it shown as still waiting to sync? What if someone else changed the same record in the meantime?

If capabilities like these are central to the job, compare them with the needs described in the guide to mobile app development for businesses. Tie the decision to the task and the devices, not just to a wish that the application can be installed.

Write the criterion that makes a feature acceptable

An acceptance criterion describes a visible result under specific conditions. Include the expected flow and a few important situations where something is missing or fails.

For the service portal that could be:

1. The client submits a valid request and receives a number they can use to find it.
2. If a mandatory field is missing, the form shows what to correct and keeps the rest of the input.
3. If the submission is not confirmed, the application clearly shows the uncertain status and the permitted next step.
4. The client sees only requests connected to their organisation.
5. The user can complete and correct the form with a keyboard.

These are proposed requirements for the example, not a claim that an existing solution already works this way. Also agree who tests them, with which data and on which devices.

Separate the first version from later possibilities

The first version needs a clear end to the chosen job. If a client can report a fault but nobody can take over the request, the flow is not complete.

For every feature, mark whether it is in the initial scope, left for later or needs further investigation. For example, basic scheduling may be initial scope, automatic route optimisation a later possibility, and an integration with an unknown ERP a matter to check.

This does not lock future development. It lets the proposal show clearly what is being estimated now and which unknowns could affect the decision.

What to send for a web application estimate

Prepare a short description of the problem, one workflow, a permissions table, the systems involved and a few acceptance criteria. Add the expected number of users, devices, the reason for any deadline and a person who can answer process questions.

You do not need to know all the answers in advance. A marked unknown is more useful than an assumption that different vendors each interpret in their own way.

If you have a process you want to turn into a web application, send Novero a short description together with one example of the input and the expected result. That is a concrete starting point for a scope conversation.

Sources

• OWASP: Authorization Cheat Sheet — guidance on checking permissions on every request.
• MDN: What is a progressive web app — advanced browser capabilities, support checks and fallback behaviour.