Цена интернет-магазина после запуска: считаем первый год, а не одну смету

В первой смете запуск интернет-магазина стоит 420 тысяч рублей, во второй — 610 тысяч. Разница в 190 тысяч выглядит достаточной для решения. Но в дешёвом предложении отдельно оплачиваются перенос каталога и две интеграции, а в дорогом они уже включены. Через год итог меняется местами.

Сравнивать только строку «разработка» можно, если за ней скрывается одинаковый результат и одинаковая ответственность после запуска. На практике это приходится доказывать. Давайте посчитаем полный бюджет первого года и одновременно отметим условия, при которых более дешёвый вариант снова становится выгоднее.

Фраза «интернет-магазин под ключ» не задаёт точную границу проекта. В одном предложении это настроенный каталог и оформление заказа на готовом решении. В другом — ещё перенос товаров, связь с учётной системой, настройка оплаты и доставки, тестовая среда, обучение и документация. Обе сметы могут быть составлены добросовестно, но отвечать на разные задачи.

До сравнения цен нужен короткий единый контур результата. Не перечень всех будущих пожеланий, а то, без чего магазин нельзя принять и начать эксплуатировать. Для каждого пункта укажите исходные данные, ожидаемый результат и сторону, которая предоставляет доступ или принимает решение.

Если по одной строке подрядчик отвечает «включено», попросите раскрыть результат. Например, «интеграция с 1С» может означать только установку поддерживаемого обмена, а может включать сопоставление нестандартных полей, проверку повторной передачи и исправление ошибок исходных данных. Слово одинаковое, объём работы разный.

Для первого сравнения достаточно восьми строк. Они не заменяют подробную смету, зато не дают крупным расходам спрятаться между разными формулировками. Период тоже должен быть одинаковым: здесь считаем двенадцать месяцев с момента начала проекта, а не календарный год после публикации сайта.

Ниже учебный пример в тысячах рублей. Это не рыночные цены и не коммерческое предложение. Смета A начинается дешевле, но перенос данных и интеграции оплачиваются отдельно. В смете B эти работы входят в запуск. В обоих вариантах предполагается один и тот же принятый результат.

Смета A даёт 1 138 тысяч рублей: 420 + 85 + 140 + 55 + 48 + 180 + 120 + 90. Смета B — 1 064 тысячи: 610 + 55 + 60 + 240 + 45 + 54. Дорогой запуск в этом сценарии уменьшает бюджет года на 74 тысячи рублей. Это не вывод о качестве подрядчиков. Он относится только к заданным границам и допущениям.

Если сотрудникам не выставляют счёт за участие в проекте, их время всё равно не становится бесплатным. Менеджер готовит правила цен, бухгалтер проверяет обмен, контент-специалист очищает каталог, руководитель принимает спорные решения. Пока они заняты проектом, другая работа ждёт.

Для учебного расчёта в смете A заложено 75 часов команды по внутренней стоимости 1 200 рублей: 90 тысяч рублей. В смете B — 45 часов, то есть 54 тысячи. Внутренняя стоимость часа не обязана совпадать с окладом, делённым на рабочее время. Организация сама определяет, какие связанные расходы и потерянную загрузку учитывать. Главное — применить один подход к обоим вариантам.

Большое число часов не всегда означает слабого подрядчика. Возможно, один вариант честно требует от заказчика подготовить структуру каталога и проверить данные, а другой включает эту работу в свою цену. Поэтому рядом с часами записывают действия: кто принимает решения, кто исправляет исходные данные и кто повторяет проверку после замечаний.

В таблице у сметы B сопровождение дороже. Но пока не раскрыт состав, эта разница ничего не говорит. Один пакет может включать только консультации и исправление подтверждённых дефектов. Другой — наблюдение за работой обмена, разбор инцидентов, регламент обновлений и определённый объём небольших изменений.

Гарантия после запуска тоже не равна сопровождению. Она обычно относится к несоответствию согласованному результату. Новая служба доставки, изменение правил скидок или дополнительное поле в обмене могут быть развитием проекта, а не дефектом. В смете нужно отделить три вещи: исправление принятой функции, эксплуатационную поддержку и новые изменения.

Проверять полезно не количество часов в пакете, а путь обычной задачи. Кто принимает обращение? Кто определяет сторону сбоя? Входит ли исправление? Что происходит с данными, пропущенными во время ошибки? Когда начинается отдельная оценка? Ответы позволяют понять, какой объём работы останется у команды магазина.

В начале проекта не обязательно знать точную стоимость каждого будущего изменения. Опаснее сделать вид, что неизвестных расходов нет. Для значимой неопределённости укажите три значения: что уже включено, при каком событии понадобится новая оценка и какой диапазон бюджета разумно зарезервировать до уточнения.

Например, перенос 18 тысяч товаров оценивается после анализа выгрузки. До него можно отдельно подтвердить базовый объём, требования к изображениям и признаки данных, которые потребуют ручной очистки. Тогда резерв связан с наблюдаемой причиной, а не добавлен произвольным процентом ко всей смете.

Так же работают границы интеграции. Подключение типового обмена и разбор нестандартных правил резервирования — разные задачи. Если вторую ещё нельзя оценить, её не следует молча считать бесплатной или включённой «по смыслу». Но и покупать максимальную разработку заранее не обязательно: можно зафиксировать исследование, критерий решения и отдельный предел расходов.

Изменим одно допущение. Допустим, обе дополнительные интеграции общей стоимостью 140 тысяч рублей магазину в первый год не нужны: соответствующие процессы можно оставить вне сайта без потери необходимого результата. Тогда итог сметы A снижается с 1 138 до 998 тысяч рублей. Если подрядчик B при сокращении объёма сохраняет фиксированную пакетную цену, вариант A оказывается на 66 тысяч дешевле. Если цена B тоже снижается, сравнение нужно пересчитать по обновлённым условиям обоих предложений.

Это важнее красивого вывода «дорогой вариант выгоднее». Правильный вывод другой: решение меняет не сама цена запуска, а состав обязательной задачи. Если функция не нужна, её исключают из обоих вариантов. Если нужна, нельзя удалять её только из дешёвой сметы, чтобы получить удобное сравнение.

Я бы заложила и дату пересмотра. Магазин может начать с меньшего контура, а вернуться к интеграции, когда ручная операция станет регулярной, появится второй склад или увеличится риск расхождения данных. Событие для пересмотра полезнее обещания когда-нибудь автоматизировать всё.

После этого выбор можно записать на одной странице: какой контур нужен в первый год, сколько он стоит по одинаковой модели, какие допущения меняют итог и при каких событиях решение пересматривается. Такая запись не гарантирует, что проект не изменится. Она помогает отличить осознанное изменение от расхода, который просто не попал в первую строку сметы.

Цена запуска отвечает на вопрос, сколько стоит начать. Бюджет первого года — сколько стоит получить работающий магазин, сопровождать его и прожить запланированные изменения. Для выбора подрядчика нужен второй ответ, а первый остаётся одной из его строк.

In the first estimate, the e-commerce store launch costs 420,000 rubles; in the second, 610,000 rubles. A difference of 190,000 rubles seems sufficient to decide. However, the cheaper proposal separately charges for catalog migration and two integrations, while the expensive one includes them. After a year, the totals reverse.

Comparing only the 'development' line item is valid only if it hides the same result and the same post-launch responsibility. In practice, this must be proven. Let us calculate the full first-year budget and simultaneously note the conditions under which the cheaper option becomes advantageous again.

The phrase 'turnkey e-commerce store' does not define a precise project boundary. In one proposal, this means a configured catalog and order placement on a ready-made solution. In another, it also includes product migration, connection to an accounting system, payment and delivery setup, a test environment, training, and documentation. Both estimates may be prepared in good faith but address different tasks.

Before comparing prices, you need a short, unified scope of deliverables. Not a list of all future wishes, but the essentials without which a store cannot be accepted and put into operation. For each item, specify the initial data, the expected result, and the party that provides access or makes the decision.

If a contractor answers "included" for a single line item, ask them to detail the result. For example, "integration with 1C" might mean only installing a supported data exchange, or it might include mapping non-standard fields, verifying re-transmission, and correcting source data errors. The term is the same, but the scope of work differs.

Eight lines are sufficient for the initial comparison. They do not replace a detailed estimate, but they prevent major costs from hiding behind different phrasings. The period must also be consistent: here we calculate twelve months from the project start, not the calendar year after the site goes live.

Below is a training example in thousands of rubles. These are not market prices and not a commercial proposal. Estimate A starts cheaper, but data migration and integrations are billed separately. In Estimate B, these works are included in the launch. Both options assume the same accepted result.

Estimate A totals 1,138 thousand rubles: 420 + 85 + 140 + 55 + 48 + 180 + 120 + 90. Estimate B totals 1,064 thousand: 610 + 55 + 60 + 240 + 45 + 54. A costly launch in this scenario reduces the annual budget by 74 thousand rubles. This is not a conclusion about contractor quality. It applies only to the specified boundaries and assumptions.

If employees are not billed for their participation in the project, their time does not become free. The manager prepares pricing rules, the accountant verifies the exchange, the content specialist cleans the catalog, and the manager makes disputed decisions. While they are occupied with the project, other work waits.

For the training calculation in Estimate A, 75 hours of team time are allocated at an internal rate of 1,200 rubles, totaling 90 thousand rubles. In Estimate B, this is 45 hours, or 54 thousand. The internal hourly rate does not have to match the salary divided by working hours. The organization independently determines which associated costs and lost capacity to account for. The main requirement is to apply a single approach to both options.

A large number of hours does not always indicate a weak contractor. One option may honestly require the client to prepare the catalog structure and verify data, while another includes this work in its price. Therefore, alongside the hours, the actions are recorded: who makes decisions, who corrects the source data, and who repeats the verification after comments.

In the estimate table, support for option B is more expensive. However, until the scope is detailed, this difference tells us nothing. One package may include only consultations and fixing confirmed defects. Another may cover monitoring the exchange process, analyzing incidents, an update schedule, and a specific volume of minor changes.

A warranty after launch is also not equivalent to support. It usually applies to deviations from the agreed result. A new delivery service, changes to discount rules, or an additional field in the exchange may be project development rather than a defect. The estimate must distinguish three things: fixing an accepted function, operational support, and new changes.

It is more useful to check the path of a typical task than the number of hours in a package. Who handles the request? Who determines the side of the failure? Does the fix fall within the scope? What happens to data skipped during an error? When does a separate estimate begin? Answers help determine how much work will remain for the store team.

At the start of a project, it is not necessary to know the exact cost of every future change. It is more dangerous to pretend that unknown expenses do not exist. For significant uncertainty, specify three values: what is already included, under what event a new estimate will be needed, and what budget range is reasonable to reserve until clarification.

For example, migrating 18,000 products is estimated after analyzing the export. Before that, you can separately confirm the base volume, image requirements, and data attributes that will require manual cleaning. In this case, the reserve is tied to an observable cause rather than added as an arbitrary percentage of the entire estimate.

The same logic applies to integration boundaries. Connecting a standard exchange and parsing non-standard reservation rules are different tasks. If the second cannot yet be estimated, it should not be silently treated as free or included "by implication." However, purchasing maximum development upfront is not necessary either: you can fix the scope of the investigation, the decision criteria, and a separate spending limit.

Let us change one assumption. Suppose both additional integrations, with a total cost of 140 thousand rubles, are not needed by the store in the first year: the corresponding processes can remain outside the website without losing the necessary result. In that case, the total of estimate A drops from 1,138 to 998 thousand rubles. If contractor B maintains a fixed package price despite the reduced scope, option A becomes 66 thousand rubles cheaper. If B's price also decreases, the comparison must be recalculated based on the updated terms of both proposals.

This is more important than a neat conclusion stating that the expensive option is more cost-effective. The correct conclusion is different: the decision changes not the launch price itself, but the composition of the mandatory task. If a function is not needed, it should be excluded from both options. If it is needed, it cannot be removed only from the cheaper estimate to create a convenient comparison.

I would also include a review date. The store can start with a smaller scope and return to the integration later when a manual operation becomes routine, a second warehouse is added, or the risk of data discrepancies increases. A scheduled review event is more useful than a promise to automate everything at some point.

After that, the choice can be recorded on a single page: which contour is needed in the first year, how much it costs under the same model, which assumptions change the final result, and under what events the decision is revisited. Such a record does not guarantee that the project will not change. It helps distinguish a conscious change from an expense that simply did not appear in the first line of the estimate.

The launch price answers the question of how much it costs to start. The first-year budget is how much it costs to get a working store, maintain it, and accommodate the planned changes. A second answer is needed to choose a contractor, while the first remains just one of its line items.