“How much does a website cost?” is a question with no honest answer before a conversation about scope. But it is possible to explain in advance what the figure is made of. Take a typical project: a web application with a catalogue, a customer account, payments and a CRM integration. The range is 250–300 thousand roubles.
What it looks like in hours
| Work | Hours | Share |
|---|---|---|
| Brief, prototype, architecture | 24 | 12% |
| Design and responsive layout | 32 | 16% |
| Markup and frontend | 56 | 28% |
| Server logic and database | 40 | 20% |
| Integrations: payments and CRM | 24 | 12% |
| Tests and fixes after acceptance | 16 | 8% |
| Deployment, monitoring, documentation | 8 | 4% |
Two hundred hours. At a rate of 1 250 roubles that is 250 thousand—the figure above.
What surprises people in this table
Development is less than half. Markup plus server work is 48%. The rest is thinking, drawing, joining things up, checking and launching. Saving on those lines looks like saving right up until acceptance.
Design work costs more than it seems. 24 hours on the brief and the prototype is not “we had a chat”. It is a clickable prototype that makes the gap visible between what you meant and what we understood. An hour here saves five hours of rework in the markup.
Integrations are the most underestimated line. 24 hours for two integrations is optimistic, and it is only fair for documented APIs like YooKassa and Bitrix24. A home-grown CRM with no documentation turns 12 hours into 40, and that is not our markup, it is the reality of someone else’s code.
Tests are not something you can drop. 16 hours looks like a candidate for a cut. In practice they come back as fixes after launch, only by then in a hurry and on live users.
Why the same thing can cost twice as much
The number of integrations. Every external system brings its own limits, its own outages and its own documentation. One integration usually adds 15–40 hours.
Whether the content is ready. Copy, photos, descriptions, access credentials. Without them the timeline grows directly and the budget indirectly: the team comes back to the same task three times.
Load requirements. A hundred users and a hundred thousand are different architectures. Queues, caching and redundancy add work before the first line of business logic is written.
Regulatory requirements. 152-FZ (Russia’s personal-data law), data localisation, advertising labelling, audit logs. Building them in from the start is cheaper than reworking after launch.
Urgency. A compressed deadline means several engineers working in parallel and overtime. That is a 20–40% surcharge, and it sits in the estimate on a line of its own.
On fixed prices
A fixed price is possible and good where the scope is known: a landing page, a standard bot, an integration with a documented API. We give one and we hold to it.
Where the scope emerges as you go, a fixed price means one of two things: either the contractor priced the risk in on top and you overpaid, or they did not—and in the second month the haggling starts about what “was not in the spec”. Both are worse than hourly billing with a transparent report.
What should be in the estimate you were sent
- A breakdown by line. “Development — 250,000” is not an estimate.
- Hours per line and the rate. Then it is clear what exactly you are disputing.
- What is not included. A good estimate lists the exclusions explicitly.
- The terms for changing scope. Who records that the work has grown, and how.
- What you get at the end: code, rights, access, documentation.
If any of that is missing, the problem is not the price—it is how the project is going to run.