The short answer first. A mid-sized web service — several user roles, personal accounts, an admin panel, a couple of integrations — costs RUB 5–6 million and takes 3–5 months. A corporate system or CRM built around a company’s processes starts at RUB 6.8 million and takes 5–7 months. A customer portal with personal accounts starts at RUB 1.7 million and takes 2–3 months.
These are benchmarks for Moscow and Saint Petersburg, not a price list. Two systems with the same name can differ in cost several times over, and it is not the contractor’s greed. Below is what the total is actually made of, and why the first number almost never matches the final estimate.
What the price is made of
Custom software is not sold like a product off the shelf. It is sold as people’s work. So the price is almost entirely the team’s hours multiplied by the rates of the specialists. Licences, servers and third-party services are a separate and usually small line.
A typical project involves:
- a business analyst — studies the processes, gathers requirements and writes the specification;
- a designer — draws the interfaces and checks that they are comfortable to work with;
- a backend developer — server logic, the database, integrations;
- a frontend or mobile developer — everything the user sees;
- a QA engineer — tests every version before you see it;
- a project manager — the plan, priorities, reports and the link with the client.
Not every role is busy full time for the whole project. The analyst and the designer work mostly at the start, the QA engineer closer to each release. But each role adds its share of hours, and removing one “to save money” usually costs more: requirements without an analyst get clarified in the code, and an untested version comes back full of bugs.
Stage by stage, the work looks like this:
| Stage | How long it takes | What you get |
|---|---|---|
| Estimate and plan | 1–3 days | timeline, cost, scope of work |
| Requirements and design | 3–5 days | approved requirements and mockups |
| Specification | 3–5 days | functions, architecture and integrations described |
| Development | 2-week iterations | a working version on a demo after each iteration |
| Testing | 7–10 days | a tested product ready for launch |
| Launch | 3–5 days | a running system and a 6-month warranty |
Most of the budget goes into development. But it is the early stages that decide how much development there will be.
What pushes the price up
The cost does not grow from words like “corporate” or “complex”. It grows from specific things, and it helps to know them in advance: then the estimate will not come as a surprise.
The number of roles and scenarios. A system for one type of user and a system where an employee, a manager, an accountant and an administrator each have their own rights and screens are different amounts of work. Every role adds screens, access checks and tests.
Integrations. Exchanging data with a CRM, an accounting system, a payment provider or a delivery service almost always takes longer than it seems. A lot depends on how well the other side’s API is documented and how it behaves when something fails. Connecting one system over an API starts at RUB 200,000; linking several systems with data synchronisation starts at RUB 1.3 million.
Load and security requirements. An internal tool for a hundred employees and a service that handles thousands of users at once are built differently. The same goes for personal data, audit logs and access control: these are not checkboxes in a contract but separate pieces of work.
Platforms. Web, iOS and Android are three different environments. Cross-platform development with Flutter ships both mobile versions from one codebase, but a mobile app still adds its own part to the budget.
Data migration. If the system replaces spreadsheets or an old program, the data has to be moved, cleaned and checked. This is often forgotten in the budget.
Deadlines. When the launch is needed “by spring”, the team works in parallel rather than in sequence. The hours do not shrink — sometimes they grow, because there is more to coordinate.
Changes along the way. Requirements change, and that is normal. But a new feature in the middle of a project costs more than the same feature planned at the start: part of what is already built has to be redone.
Why a starting price is not an estimate
Studio websites almost always say “from”. It is not a trick but an honest limitation: before talking about the task, a contractor knows only the type of product.
A starting price is the lower bound for a typical scope. “A corporate system from RUB 6.8 million” means a system with the company’s processes, access rights, reports and data exchange with other systems, in a reasonable volume. With more processes, five integrations instead of two or a separate analytics module, the total will be higher.
The estimate gets sharper as the task gets clearer:
- After the first call — a range. The type of product, the roles and the key integrations are known.
- After the estimate and plan — timeline and cost by stage. The spread narrows a lot.
- After the requirements and the specification — an estimate you can rely on. Every function is described, and every function has a number.
So treat the price from the first email as a budget guideline, not a promise. A serious contractor will tell you which assumptions are behind it.
What is usually not in the development price
Some costs live separately, and it is better to agree on them in advance:
- servers or cloud — the system runs on your servers or in the cloud of your choice, and you pay the provider directly;
- paid third-party services — text messages, maps, payment gateways, analytics;
- app store publishing, if there is a mobile version: developer accounts are registered to the client’s company;
- work after the warranty — new features and support after launch are paid separately, by plan or task by task.
Fixing bugs in the delivered work during the warranty period is included. Our warranty lasts 6 months.
How not to overpay
You can save, but not on testing or analysis. Other things work.
Start with a first version. There is no need to build a system for every case at once. An MVP with one key scenario ships in 2–3 months and works with real users right away. After that, features are added based on data, not guesses.
Do not build what already exists. Sign-in with a corporate account, notifications, payments and maps are better connected as ready-made services than written from scratch.
Compare with an off-the-shelf system. If the processes are standard, a boxed product may be cheaper. Custom development pays off where the processes are unique or where customising the box costs as much as a new system.
Work in short iterations. A demo every two weeks gives you the chance to stop in time, change priorities or drop a feature that is no longer needed. It is the best insurance against a budget spent in the wrong place.
How to get an accurate estimate
For a useful estimate, a contractor needs little: the task in 2–3 sentences, who will use the system, which programs it has to connect to and when it is needed. The rest comes out in a short call.
We prepare the time and cost estimate for free, in 1–3 days. If the discussion needs details that cannot be disclosed, we sign an NDA first. More about how the work is organised and what development includes is on the custom software development page.
The price of a custom system is not a number from a price list but the sum of decisions: which roles, which integrations, which first version. The earlier those decisions are made, the closer the first number gets to the final one.
