When a business needs a web application, not another corporate site

Sites and web applications solve different classes of problems

A corporate site is good where you need to present the company, services and cases and collect enquiries. But as soon as the business starts talking about user roles, customer cabinets, orders, documents, approvals, repeated actions, integrations and operation history, the task becomes something else entirely.

Signs you actually need a web application

• There are roles with different access rights: clients, managers, admins, logistics or accounting need different screens and different actions.
• The system must store and process working data: orders, contracts, statuses, files, documents, notifications.
• Daily work depends on the system, not on a one-time visit to a landing page.
• External systems have to be integrated: 1C, CRM, telephony, payment providers, warehouses.
• The business needs audit, history and access control rather than page views.

Why many companies call such a task a "site" for too long

Because from the outside you still see a browser and an interface. Technically and from a product perspective, a different class of solution already lives inside: roles, access control, backend logic, a data model, background processes, integrations, testing, production and support. Treating it as a site means underestimating budget, timelines and risk.

Where the most common mistakes happen at the start

• Trying to squeeze working scenarios into the model of a marketing site.
• Postponing role and data design "until later".
• Not fixing what is critical for the first release and what can safely wait.
• Discussing screens before defining the daily working action the system must take over.

Which question to ask first

Not "what design do we need" and not "what should we build it with". The first question is: which working action must the system take over after launch? If that is placing an order, managing a client, working with documents, approvals, analytics or servicing B2B clients, the answer determines the architecture, the roles and the first release.

What the business gets

When the task is classified correctly as a web application, the company has a chance to assemble a realistic first release: roles, cabinet, integrations, critical scenarios and a clear path to support and growth without expensive rework after launch.