What a web application costs and why estimates are broken into stages

Why there is no instant price

A web service is not an off-the-shelf product. Even if two clients ask for a booking platform, one might mean a calendar with a form, the other a system with user roles, CRM integration, online payment and Telegram notifications. The price difference between them is tenfold.

Trying to name a sum before a brief becomes either dishonest (the studio builds in a safety margin and quotes the maximum) or leads to conflict (the client hears the minimum and then gets hit with add-ons). Standard practice is to gather requirements first, then estimate.

EFIMOV DEV publishes starting-from ranges for services: landing page, corporate site, online store, web service. These are budget guides, but an accurate estimate only appears after the brief, when the scope is clear.

What the cost is made of

Web application development is billed by team hours. This is not a physical product with material costs - it is intellectual work, and its volume depends on the complexity of the task.

The estimate includes interface design, layout, programming logic on the frontend and backend, database setup, integration with external services, testing, revisions after early iterations. If a mobile version or app is needed, that is separate development because the code is written from scratch.

User roles affect price. A service for one role (say, a customer books an appointment) costs two to three times less than a system with admin, manager and client, each with their own interface and permissions.

Integrations add cost unpredictably. Connecting payment via a ready-made library takes a few hours. Linking a service to a CRM with a broken API and no documentation can mean days of trial and workarounds.

Why estimates are divided into stages

Stage-based estimates protect both sides. The client sees what they are paying for and can stop after any block if the budget runs out or the task changes. The studio does not work at a loss if the project is frozen halfway.

Typical breakdown: design and interface, layout, programming core functions, programming additional modules, testing and revisions, launch. Each stage is estimated separately and can be signed off independently of the next.

This does not mean you can take design from one studio and order development from another. Stages are logically linked: the programmer must understand how the interface is structured, the designer what is technically feasible. But if at the layout stage it becomes clear the budget will not cover full functionality, you can trim the next blocks and launch an MVP.

How not to overpay for what you do not need

Clients often ask for features no one will use. A personal dashboard with settings when the customer logs in once. Excel export when nobody looks at reports. A notification system across three channels when email is enough.

A decent studio will ask: what is this for? If there is no answer or it sounds like well, just in case, the feature should be postponed. You can add it later when it becomes clear it is actually needed.

Another trap is building for every platform at once. Web, iOS, Android - that triples the budget. If the business is just starting, begin with web. If six months in it turns out 70% of users access from mobile, then build the app. Do not construct what you have not validated.

What should be in the estimate

An estimate is not a single line with a total. It is a list of work blocks with a description and price for each. If you receive a file that just says web service development - 500,000 roubles, that is not an estimate. That is a number, and you do not know what it includes.

In a proper estimate each block is itemised: User registration and login: registration form, email confirmation, password recovery, social login - 40 hours. You see exactly what will be built and can say: Social login is not needed yet, remove it.

The estimate must include testing and revisions. If they are missing, they will surface as add-ons after handover and the final sum will grow 20-30%. Revisions after the first interface review are a normal part of the work and should be in the budget.

Why the final price can change

The estimate fixes the scope known at the start. But details emerge during the work that no one accounted for. For instance, it turns out the external service API has rate limits and you need a request queue. Or the client's database is structured differently than described and the integration requires rework.

If changes stem from the studio's mistake or something missed at the brief stage, that should be done at the contractor's expense. If the client changes requirements mid-project (let's add filters here), that is paid separately.

Good practice is to build a 10-15% contingency into the estimate. This is not markup, it is a safety buffer that allows the project to continue without stopping over minor adjustments.

What post-launch support costs

Launching a web service is not the end of development. Then comes operation: fixing bugs that appear under load, refining features based on user feedback, updating libraries and dependencies.

Support can be billed as needed (each fix estimated separately) or by retainer (fixed monthly sum for a set number of hours). A retainer is more convenient if changes are regular: no need to agree an estimate each time, and the studio keeps the project in context.

EFIMOV DEV offers technical support as a service - worth clarifying the terms after project launch if you plan to develop the service further.

How to check if an estimate is reasonable

Ask for the estimate broken down by blocks and show it to a developer acquaintance or someone technically literate. They will not assess exact cost but will spot if unnecessary items are included or critical stages are missing.

Compare estimates from two or three studios. If one is half the price of the others, that is not a bargain - it is either underestimation (add-ons will appear later) or low quality. If one is twice as expensive, ask what is included beyond the standard.

Pay attention to timelines. If a complex web service is promised in a month, that is cause for concern. Normal development speed is 30-40 programming hours per week per person, not counting design, interface work, or testing. A realistic timeline for a medium-complexity service is two to four months.

If this is already on your plate, here is how we do it end to end: Web service and SaaS development.

Frequently asked