# WAPP — llms-full.txt

> Single-file export of public MDX bodies from `content/blog` and `content/projects`. Front matter omitted; JSX components removed heuristically.

---

## Blog: 1С для лаборатории: что закрывает, а что придётся дописывать

- **Slug:** `1c-dlya-laboratorii`
- **Locale:** `ru`

1С уже работает в бухгалтерии и на складе. Руководство предприятия требует: расширьте на лабораторию, зачем покупать отдельную систему? Открываешь типовую конфигурацию 1С и понимаешь: ни учёта проб, ни протоколов испытаний, ни связи с оборудования там нет. Что делать — искать отраслевые решения на платформе 1С Предприятие 8, заказывать доработку или внедрение отдельной ЛИМС? Ниже разбираем каждый вариант: что 1С закрывает для лаборатории из коробки, где начинается территория кастомной разработки и в каких случаях две системы с обменом данными оказываются практичнее.

## Почему лаборатории вообще смотрят на 1С

1С уже обслуживает финансовый контур предприятия. Руководство компании рассуждает логично: лицензии оплачены, сервер настроен, пользователей обучили, техническая поддержка по ИТС работает. Зачем плодить программы, если платформа 1С (1C) Предприятие 8 уже ведёт учёт материалов, управление заказов и формирование отчётности?

А потом кто-то открывает типовую конфигурацию 1С и понимает: ни регистрации проб, ни управления методик испытаний, ни связи с лабораторным оборудованием там нет. 1С Бухгалтерия считает деньги. 1С ERP и «Комплексная автоматизация» ведут склад, производство, продажи. Но полный цикл пробы от приёмки до выдачи протокола ни одна из этих конфигураций 1С не описывает.

### Когда Excel перестаёт справляться

Автоматизация лаборатории становится вопросом не желания, а необходимости. Объём проб растёт, количество лабораторных исследований увеличивается каждый квартал, а журналы в Excel путаются в версиях файлов. Ручная обработку данных приводит к ошибкам: кто-то перезаписал формулу, кто-то удалил строку. Восстановить историю изменений невозможно, а аудитор по ГОСТ ISO/IEC 17025 спрашивает именно про прослеживаемость данных и защиту значений от несанкционированных правок.

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

### Почему первый выбор — 1С

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

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

Главная задача этого материала — разобрать, где проходит граница. Если вы только начинаете думать об автоматизации, имеет смысл [разобраться, с чего начать](/ru/blog/lab-automation-where-to-start), прежде чем заказать консультацию у франчайзи 1С.

## Что 1С закрывает из коробки

Теперь о том, что программы 1С для лабораторий закрывают без единой строчки дополнительного кода.

### Учёт реактивов и расходных материалов

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

### Закупки и поставки

Формирование заявки на закупку, согласование, отслеживание поставки — типовой процесса 1С. Для каждого вида расходных материалов можно задать минимальный остаток, и система 1С автоматически сформирует потребность. Контакты поставщиков, история заказов, цена предыдущих партий — информация хранится в одной базе 1С.

### Бухгалтерия и отчётность

1С:Бухгалтерия — самый зрелый программный продукт линейки 1С. Ведение бухгалтерского и налогового учёта, электронная отчётность, выдача счетов и закрывающих документов. Лаборатория, оказывающая услуги на коммерческих условиях, получает готовое решение 1С для выставления счёт-фактур, оформления договоров и формирования актов выполненных работы.

### Кадры и зарплата

1С:ЗУП берёт на себя кадровый учёт: приём, увольнение, графики рабочих мест, расчёт зарплаты с учётом вредности, обработку персональных данных в соответствии с политикой конфиденциальности организации. Количество пользователей масштабируется от нескольких человек до сотен. Данные защищены встроенный системой разграничения прав 1С.

### Единый контур предприятия

Главная сила 1С — информационная система, связывающая лабораторию с остальным бизнесом предприятия. Комплексная автоматизация 1С объединяет склад, бухгалтерию, кадры и производство. Результаты анализа затрат на реактивы сразу попадают в управленческие отчёты. Поддерживается обмен данными между различных конфигураций 1С в режиме реального времени.

Но если наложить этот список на реальные лабораторные процессы — регистрацию проб, ведение журналов испытаний, генерацию протоколов — станет очевидно: ничего из этого в типовых конфигурациях 1С нет. И [именно здесь](/ru/solutions/chem-lab) начинается территория доработок.

Платформы 1С Предприятие 8 проектировалась под учёт денег, товара и людей. Проба воды или образец продукции — объекты другой вселенной.

### Нет понятия «проба» и «методика»

В 1С нет справочника образцов, нет регистрации проб с привязкой к точке отбора, нет сущности «методика испытания». Управление испытаниями не заложено в архитектуру 1С. Лаборатория пытается вести пробы через документ «Поступление товара» — и упирается в тупик: результатов лабораторных исследований привязать негде, протоколы формировать не из чего.

### Расчёт неопределённости и статистические отчёты

ГОСТ ISO/IEC 17025 требует оценивать неопределённость каждого измерения. Ни один программный продукт линейки 1С не считает это из коробки. Формирование статистических отчётов по внутрилабораторному контролю качества и анализ показателей тоже приходится делать за пределами платформы 1С.

### Прослеживаемость и связь с оборудованием

Прослеживаемость правок — требования аккредитации. Стандартный журнал регистрации 1С фиксирует действия пользователей, но не в том формате, который ждёт эксперт. Передача данных с лабораторного оборудования — хроматографов, спектрометров, анализаторов — требует драйверов и парсеров. Платформа 1С такое не поддерживает без глубокой доработки. Ведение электронных журналов с привязкой к сигналам оборудования — задача, которую решает [специализированная ЛИМС](/ru/solutions/chem-lab/lims).

## Отраслевые решения на платформе 1С

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

### Что есть на рынке

Большинство решений 1С сосредоточено вокруг медицины. «1С:Медицина. Клиническая лаборатория» закрывает регистрацию проб, взаимодействие с анализаторов, формирование отчётности для клинических лабораторий и обслуживание пациентов. За пределами медицинских организаций выбор резко сужается. Испытательная, экологическая или строительная лаборатория — для этих направлением деятельности готовых продуктов 1С почти нет. Среди известных нишевых решений можно встретить продукты компании Алтэй и группа других разработчиков, но комплект функциональные возможностей у каждого свой.

### Риски, о которых молчат

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

### Когда отраслевое решение 1С оправдано

Этот вариант имеет смысл, когда лаборатория точно попадает в профиль продукта 1С, а разработчик стабилен. Для клинической лаборатории, где стандартный набор исследований покрывает основной объёма услуг, [отраслевые решения на базе 1С](/ru/solutions/chem-lab) могут быть разумным выбором. Но если лаборатория работает по десяткам методик и обязана вести электронную прослеживаемость для аккредитации, стандартный продукт партнёра 1С не дотянет до необходимого уровня.

Когда готовое решение 1С не подходит, возникает соблазн допилить типовую конфигурацию. На бумаге логично: бухгалтерия и склад работают, осталось добавить «немного лабораторного». На практике это проект с непредсказуемой ценой.

### Что приходится создавать с нуля

Нужны новые справочники 1С: пробы, методики, оборудование. Нужны регистры для хранения результатов, журналы контроля качества, документы регистрации заявки клиента. Использование индивидуальными настроек прав, форм и печать макетов для каждого объекта увеличивает трудоёмкость в разы.

### Обновления как бесконечный конфликт

Каждое типовое обновление 1С рискует сломать доработки. Разработчик вынужден вручную сравнивать изменения и тестировать взаимодействие нового кода со старым. Расходы на сопровождение доработанной конфигурации 1С за три года часто превышают первоначальные затраты вдвое.

### Зависимость от подрядчика

Франчайзи 1С, который писал код, знает архитектуру решения. Если он уходит, новый разработчик получает чужой код без документации. Разобраться — задача на месяцы. Ответственность размывается: вендор 1С поддерживает типовой функционал, партнёры отвечают за доработки. Когда что-то ломается на стыке, лаборатория ждёт, а сотрудники [обходят систему стороной](/ru/blog/why-lab-staff-bypass-lims) — возвращаются к Excel.

Доработка 1С — не приговор. Но стоит посчитать цену владения на пять лет. Часто эта сумма делает вариант «1С для финансов + отдельная лабораторная информационная система» более выгодным.

## Связка 1С с отдельной лабораторной системой

К этому выводу приходят многие команды после попыток уместить лабораторные процессы внутрь 1С.

1С остаётся там, где она сильна: учёт материалов, управление закупками, бухгалтерская отчётность, расчёт зарплат. А регистрация проб, полный цикл от приёмки до выдачи результатов, контроль качества — всё живёт в [ЛИМС](/ru/solutions/chem-lab/lims). Технология обмена данными: из 1С уходят справочники контрагентов и номенклатура, ЛИМС передаёт акты выполненных услуг и статистические отчёты. Настройка делается через REST API или файловую шину. Автоматическая синхронизация в режиме реального времени поддерживается обеими системами.

### Почему это работает лучше доработки 1С

Обновления 1С не касаются лабораторного кода — он в другой системе. Лаборатория получает интерфейса, заточенный под её сценарии: автоматическая регистрация результатов с анализаторов, ведение журналов, формирование протоколов. Поддержка 1С идёт через ИТС, поддержка лабораторной части — через команду разработчика ЛИМС. Зоны ответственности не размываются. Программное обеспечение каждой системы развивается независимо.

Пример — [кейс СпектроХим](/ru/project/spektrokhim), где 1С обеспечивает финансовый контур, а ЛИМС ведёт анализ проб и хранение истории испытаний. Для государственных и коммерческих лабораторий в России этот вариант сейчас наиболее реалистичен. Две системы с обменом данными надёжнее одной, в которой половина функций держится на костылях.

## Частые вопросы

### Можно ли пройти аккредитацию по ГОСТ ISO/IEC 17025, работая в 1С?

Сам по себе программный продукт 1С аккредитацию не даёт. Эксперты оценивают управление данными и прослеживаемость изменений. Если в конфигурации 1С реализованы электронная регистрация проб, хранение истории правок и формирование протоколов — система закроет требования. Но типовые решения 1С этого не умеют, поэтому без доработки или связки 1С с ЛИМС пройти аккредитацию не получится.

### Сколько стоит доработка 1С под лабораторию?

Цена зависит от количества типов исследований, числе компьютеров на рабочих местах и состава оборудования. Запросите анализ текущего процесса у подрядчика — получите оценку, привязанную к конкретному списку задач. Информацию о подходах к оценке можно найти на странице сайта профильных интеграторов 1С.

### Что делать, если франчайзи 1С не разбирается в лабораторных процессах?

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

### Как организовать обмен данными между 1С и ЛИМС?

Стандартный вариант — обмен через REST API или файлы XML/JSON. 1С отдаёт данные о поставках и счета, ЛИМС возвращает результаты испытаний. Настроим обмен за срок от нескольких дней до пары недель. Сервисы обмена и пример реализации можно посмотреть в [кейсе СпектроХим](/ru/project/spektrokhim). Возможность индивидуально настроить состав передаваемых данных обсуждается с менеджером проекта.

## Выводы и первый шаг

1С для лаборатории закрывает финансовый и складской контур: учёт реагентов, бухгалтерия, 1С:ЗУП, отчётность по закупкам. Но управление испытаниями, регистрация проб, ведение журналов, контроль качества продукции, взаимодействие с оборудованием — ничего из этого в типовых конфигурациях 1С нет.

Доработка типовой конфигурации 1С возможна, но расходы на сопровождение растут с каждым обновлением. Связка 1С с отдельной лабораторной системой часто практичнее: 1С остаётся источником финансовых данных, а ЛИМС ведёт полный цикл пробы. Использование двух систем с обменом масштабируется без ограничений платформы 1С. Управление политикой доступа и персональных данных в каждой системе настраивается индивидуально. Программа 1С разработана для учёта ресурсами предприятия, ЛИМС — для выполнения лабораторных задач технологического контроля. Помощь в выборе окажет подробнее изучение движения проб и получения данных с изображений и сигналов оборудования.

### Первый конкретный шаг

Прежде чем заказать консультацию, составьте список из десяти ключевых процессов лаборатории: от получения пробы до выдачи результатов. Отметьте, какие ведутся в Excel, на бумаге или «на словах». Это станет основой технического запроса. Контакты и описание услуг по проектированию лабораторных систем можно найти на страницах сайта [WAPP](/ru/solutions/chem-lab). Подробнее о том, [с чего начать](/ru/blog/lab-automation-where-to-start), читайте в отдельном материале.

---

## Blog: 1C for laboratories: what it covers — and what you still have to build

- **Slug:** `1c-dlya-laboratorii`
- **Locale:** `en`

1C already runs accounting and the warehouse. Leadership asks: extend it to the lab — why buy a separate system? You open a stock 1C configuration and see there is no sample tracking, no test protocols, no link to instruments. What next — look for industry solutions on the 1C:Enterprise 8 platform, commission a customization, or implement a separate LIMS? Below we walk through each option: what 1C covers for a laboratory out of the box, where custom development begins, and when two systems with data exchange are more practical.

## Why laboratories look at 1C at all

1C already serves the enterprise financial contour. Leadership reasons soundly: licences are paid, the server is set up, users are trained, ITS support works. Why proliferate software if the 1C:Enterprise 8 platform already handles materials accounting, order management, and reporting?

Then someone opens a stock configuration and sees there is no sample registration, no test-method management, no link to laboratory equipment. 1C Accounting counts money. 1C ERP and “Comprehensive Automation” run warehouse, production, and sales. But none of these 1C configurations describe the full sample cycle from intake to issuing a protocol.

### When Excel stops being enough

Lab automation becomes a necessity, not a wish. Sample volume grows, the number of laboratory studies rises every quarter, and Excel journals tangle in file versions. Manual data handling leads to errors: someone overwrote a formula, someone deleted a row. Change history cannot be restored, and an ISO/IEC 17025 auditor asks specifically about data traceability and protection of values against unauthorized edits.

Another scenario: accreditation is approaching. You need statistical reports on test results, confirmation of workstation competence, electronic capture of every analysis type. Paper journals and scattered spreadsheets do not deliver that.

### Why 1C is the first choice

For a company where 1C for the laboratory looks like a natural extension of the current business contour, the arguments are strong. No extra 1C licence delivery. No retraining staff on another system. Reusing the already configured interaction of 1C with accounting, warehouse, and sales saves time. Reagent accounting fits the 1C warehouse module. Total cost of ownership, at first glance, looks lower.

But registering laboratory test results, calculating measurement uncertainty, automatic data transfer from analyzers, quality control with control charts — none of that exists in stock 1C solutions. Even industry 1C products such as “1C:Medicine. Clinical Laboratory” target medical organizations and clinical diagnostics for patients, not a testing laboratory. A 1C software product for industrial testing will have to be built from scratch or found among niche solutions from 1C partners.

The main goal of this piece is to draw the boundary. If you are only starting to think about automation, it makes sense to [understand where to begin](/en/blog/lab-automation-where-to-start) before you order a consultation from a 1C franchisee.

## What 1C covers out of the box

Now — what 1C programs for laboratories cover without a single line of extra code.

### Reagents and consumables accounting

Any laboratory consumes reagents, reference standards, and equipment consumables. Warehouse accounting in 1C:Trade Management or in the 1C ERP block covers receipt registration, write-off on use, and stock control. Lot accounting lets you track each reagent’s expiry date. 1C itself highlights items whose certificate is about to expire.

### Procurement and supply

Purchase requests, approvals, delivery tracking — a standard 1C process. For each consumable type you can set a minimum stock level, and 1C will form the demand automatically. Supplier contacts, order history, prices of previous lots — all stored in one 1C database.

### Accounting and reporting

1C:Accounting is the most mature product in the 1C line. Bookkeeping and tax accounting, electronic reporting, invoices and closing documents. A laboratory that sells services commercially gets a ready 1C solution for invoicing, contracts, and acts of completed work.

### HR and payroll

1C:ZUP handles HR: hiring, termination, work schedules, payroll with hazardous-duty factors, and personal data processing under the organization’s confidentiality policy. User count scales from a few people to hundreds. Data is protected by 1C’s built-in access rights system.

### A single enterprise contour

1C’s main strength is an information system that links the laboratory to the rest of the business. 1C comprehensive automation unites warehouse, accounting, HR, and production. Cost analysis on reagents feeds management reports immediately. Data exchange between different 1C configurations is supported in near real time.

But if you overlay this list on real laboratory processes — sample registration, test journals, protocol generation — it becomes obvious: none of that exists in stock 1C configurations. And [this is where](/en/solutions/chem-lab) customization territory begins.

## What 1C lacks for laboratory work

The 1C:Enterprise 8 platform was designed around money, goods, and people. A water sample or a product specimen belongs to another universe.

### No concept of “sample” or “method”

1C has no sample directory, no sample registration tied to a sampling point, no “test method” entity. Test management is not built into 1C’s architecture. The laboratory tries to run samples through a “Goods receipt” document — and hits a wall: there is nowhere to attach laboratory results, and nothing to build protocols from.

### Uncertainty calculation and statistical reports

ISO/IEC 17025 requires assessing the uncertainty of every measurement. No product in the 1C line calculates that out of the box. Building statistical reports for internal quality control and indicator analysis also has to happen outside the 1C platform.

### Traceability and instrument connectivity

Edit traceability is an accreditation requirement. The standard 1C registration journal records user actions, but not in the format an assessor expects. Transferring data from laboratory equipment — chromatographs, spectrometers, analyzers — needs drivers and parsers. The 1C platform does not support that without deep customization. Keeping electronic journals tied to instrument signals is a job for a [specialized LIMS](/en/solutions/chem-lab/lims).

## Industry solutions on the 1C platform

1C partners build industry solutions for specific laboratory types. Before celebrating, it is worth understanding the boundaries.

### What is on the market

Most 1C solutions cluster around medicine. “1C:Medicine. Clinical Laboratory” covers sample registration, analyzer interaction, reporting for clinical laboratories, and patient service. Outside medical organizations the choice shrinks sharply. Testing, environmental, or construction laboratories — for these activity areas ready-made 1C products are almost absent. Among known niche solutions you may find products from Altey and other developers, but each has its own functional package.

### Risks vendors stay quiet about

The main vulnerability is dependency on the developer. When 1C updates the platform, the partner must adapt their 1C product. If the company has three people on staff, updates slip by months. Worse: the developer leaves the market, and the system becomes unmaintained legacy. News of such projects shutting down appears regularly, and the laboratory is left with code nobody can support.

### When an industry 1C solution is justified

This option makes sense when the laboratory fits the product profile exactly and the developer is stable. For a clinical laboratory where a standard test set covers the main service volume, [industry solutions on 1C](/en/solutions/chem-lab) can be a reasonable choice. But if the laboratory runs dozens of methods and must keep electronic traceability for accreditation, a standard partner 1C product will not reach the required level.

## Customizing a stock 1C configuration: hidden costs

When a ready 1C solution does not fit, the temptation is to “finish” the stock configuration. On paper it is logical: accounting and warehouse work — just add “a bit of laboratory.” In practice it is a project with an unpredictable price.

### What you have to build from scratch

You need new 1C directories: samples, methods, equipment. You need registers for results, quality-control journals, client-request registration documents. Using individual rights settings, forms, and print layouts for every object multiplies effort many times over.

### Updates as an endless conflict

Every stock 1C update risks breaking customizations. The developer must manually compare changes and test how new code interacts with the old. Support costs for a customized 1C configuration over three years often exceed the initial spend twofold.

### Contractor lock-in

The 1C franchisee who wrote the code knows the solution architecture. If they leave, a new developer inherits foreign code without documentation. Understanding it takes months. Responsibility blurs: the 1C vendor supports stock functionality; partners own the customizations. When something breaks at the seam, the laboratory waits, and staff [bypass the system](/en/blog/why-lab-staff-bypass-lims) — returning to Excel.

Customizing 1C is not a death sentence. But you should calculate five-year cost of ownership. Often that sum makes “1C for finance + a separate laboratory information system” the better deal.

## Pairing 1C with a separate laboratory system

Many teams reach this conclusion after trying to fit laboratory processes inside 1C.

### How it works in practice

1C stays where it is strong: materials accounting, procurement, accounting reports, payroll. Sample registration, the full cycle from intake to results, quality control — all live in a [LIMS](/en/solutions/chem-lab/lims). Data-exchange technology: 1C sends counterparty directories and nomenclature; the LIMS returns acts of completed services and statistical reports. Setup is done via REST API or a file bus. Automatic near-real-time sync is supported by both systems.

### Why this works better than customizing 1C

1C updates do not touch laboratory code — it lives in another system. The laboratory gets an interface built for its scenarios: automatic result registration from analyzers, journals, protocol generation. 1C support goes through ITS; laboratory support goes through the LIMS development team. Responsibility zones stay clear. Each system’s software evolves independently.

An example is the [Spektrokhim case](/en/project/spektrokhim), where 1C covers the financial contour and the LIMS runs sample analysis and test history. For public and commercial laboratories in Russia, this option is currently the most realistic. Two systems with data exchange are more reliable than one in which half the functions rest on crutches.

## Frequently asked questions

### Can you pass ISO/IEC 17025 accreditation while working in 1C?

On its own, a 1C product does not grant accreditation. Assessors evaluate data management and change traceability. If the 1C configuration implements electronic sample registration, edit history, and protocol generation — the system can meet the requirements. But stock 1C solutions cannot do that, so without customization or a 1C–LIMS pairing you will not pass accreditation.

### How much does customizing 1C for a laboratory cost?

Price depends on the number of test types, the number of workstation computers, and the equipment mix. Request an analysis of the current process from a contractor — you will get an estimate tied to a concrete task list. Information on estimation approaches is available on the sites of specialized 1C integrators.

### What if the 1C franchisee does not understand laboratory processes?

That is the main reason implementations stall. A 1C franchisee configures accounting but does not understand control charts and internal quality-control activities. The way out: look for 1C partners with laboratory-service automation experience, or bring in a domain consultant — a project manager who works alongside the developer.

### How do you organize data exchange between 1C and a LIMS?

The standard option is exchange via REST API or XML/JSON files. 1C sends supply and invoice data; the LIMS returns test results. Exchange can be set up in several days to a couple of weeks. Exchange services and an implementation example are in the [Spektrokhim case](/en/project/spektrokhim). Customizing the set of transferred fields is discussed with the project manager.

## Conclusions and a first step

1C for a laboratory covers the financial and warehouse contour: reagent accounting, bookkeeping, 1C:ZUP, procurement reporting. But test management, sample registration, journals, product quality control, instrument interaction — none of that exists in stock 1C configurations.

Customizing a stock 1C configuration is possible, but support costs grow with every update. Pairing 1C with a separate laboratory system is often more practical: 1C remains the source of financial data, and the LIMS runs the full sample cycle. Two systems with exchange scale without 1C platform limits. Access and personal-data policies are configured per system. 1C is built for enterprise resource accounting; a LIMS is built for laboratory tasks and process control. Studying sample flow and getting data from instrument images and signals helps with the choice.

### A concrete first step

Before you order a consultation, list ten key laboratory processes: from receiving a sample to issuing results. Mark which ones run in Excel, on paper, or “by word of mouth.” That becomes the basis of a technical request. Contacts and a description of laboratory-system design services are on the [WAPP](/en/solutions/chem-lab) site. More on [where to start](/en/blog/lab-automation-where-to-start) is in a separate article.

---

## Blog: Mobile App Development Cost in 2026: What Studios Don't Put in the Quote

- **Slug:** `app-development-cost-hidden`
- **Locale:** `en`

The dream of launching an app usually starts with a spark of genius and a quick Google search: "How much does it cost to build an app?" If you were looking for a simple number, I have some news that might be uncomfortable but necessary. In 2026, the traditional "price tag" model is dead.

Building an app today isn't just about hiring someone to write code; it's about architecting a digital ecosystem that survives in a world of hyper-personalized AI, fluctuating cloud costs, and rigorous data privacy laws. If you walk into a development studio today, they will give you a quote. But that quote is often just the tip of the iceberg. To truly succeed, you need to understand the submerged costs that can sink a project before it ever hits the App Store.

## The Reality of App Budgeting in 2026

Budgeting for an app in 2026 feels different than it did even three years ago. We've moved past the "gold rush" era where any functional interface could find an audience. Now, users expect magic, and magic has a specific overhead.

### Why "Ballpark Estimates" are Vanishing

In the past, a developer could look at your feature list and give you a rough estimate because most apps followed a predictable blueprint. You needed a login, a database, a shopping cart, and a payment gateway. Today, even simple social networking apps might require real-time video processing, computer vision for AI-driven content moderation, and cross-platform synchronization that works across a widening range of devices.

Because the baseline for "standard" features has shifted so drastically toward high-end tech, ballpark estimates have become dangerous. The variance that used to sit inside a rounding error now sits inside a funding round. Developers are realizing that if they give you a fixed number too early, they are either guessing or setting themselves up for a loss they will try to recover through change orders later.

### The Shift from Coding to Orchestration

We are no longer in an era where developers write every line of code from scratch. Modern development is about orchestration. Your app is a symphony of third-party APIs, cloud services, and pre-built frameworks.

The cost has shifted from the labor of typing syntax to the expertise of integrating complex systems. You aren't just paying for hours spent coding; you are paying for the strategic thinking required to ensure that your AI assistant doesn't hallucinate and your payment processor doesn't fail during a regional outage. This shift means that while coding gets faster thanks to AI-assisted tools, engineering becomes more expensive, because the stakes of a bad architecture are higher than ever.

## Breaking Down the Core Development Costs

To understand where your money goes, we have to look at the pillars of construction and how app complexity dictates the final price. Think of it like building a house: the price changes based on whether you're building a prefab cabin or a high-tech smart home.

![What moves the budget inside a tier: user roles, integrations, and realtime as three axes of complexity](./images/budget-complexity-axes.webp)

### 1. Complexity Levels: MVP vs. Enterprise

An MVP (Minimum Viable Product) in 2026 is no longer "bare bones." It must be loveable. It needs to solve one problem well with a polished UI. It is designed to test a hypothesis with real users without over-investing in bells and whistles: two user roles, one core scenario, and enough quality that people don't uninstall on day one.

Enterprise apps, on the other hand, are built for scale, security, and legacy integration. They often require compliance certification, multi-factor authentication, and the ability to handle heavy concurrent load. The budget gap between the two is not incremental — it is an order of magnitude, because the work is fundamentally different. An MVP validates an idea. An enterprise app becomes the backbone of a company's operations, and it has to behave like one on the worst day of the year, not the best.

What actually moves the number inside each tier: the count of user roles, the number of external systems you integrate with, and whether anything happens in real time. Three roles cost far more than two, not because of extra screens, but because every permission boundary has to be designed, built, and tested.

### 2. The Platform Choice: Native vs. Cross-Platform

The "native vs. cross-platform" debate has largely been settled by the maturity of frameworks like React Native and Flutter. For most business applications, cross-platform development is the sensible default. It allows you to write one codebase for both iOS and Android, which meaningfully reduces initial development cost — though not by half, since platform-specific work, testing, and store submission still happen twice.

However, if your app requires high-performance graphics, heavy background processing, or deep integration with specific hardware, native development (Swift for iOS, Kotlin for Android) is still the right call. Just be prepared to pay for two codebases and two release cycles.

Our own split follows that logic. [Glinka Digital](/en/project/glinka-digital), a platform for online music lessons, runs on React Native because the interface is standard and the difficulty lives on the backend. When the hard work is media and infrastructure rather than UI chrome, cross-platform on the front is what frees budget for the parts that actually differentiate the product.

### 3. UI/UX Design: Why "Pretty" Isn't Enough Anymore

In 2026, design is about frictionless flow. A beautiful e-commerce app that takes three taps to reach checkout will lose to an average-looking app that takes one. UX designers now spend as much time on data, psychology, and accessibility as they do on colors and fonts.

Good design involves user journey mapping, wireframing, and interactive prototyping. If the design line in your quote looks suspiciously thin, the studio is likely skipping research — which means you'll pay for it later, when you redesign because users can't figure out how to use what you built.

### 4. The Backend Infrastructure and Data Management

The backend is the engine under the hood. In 2026, this isn't just a database. It involves serverless architectures, real-time data streaming, and edge computing to keep latency low. The cost here is driven by the volume and shape of the data you expect to process. If you're building a video platform, your backend will dwarf your frontend. If it's a scheduling tool, the backend and admin panel stay relatively light.

## What Studios Don't Put in the Initial Quote (Hidden Costs)

This is where most founders get blindsided. A studio quotes the construction of the app, but rarely the operating costs or the "last mile" expenses.

![Budget iceberg: quote price above water; APIs, cloud, AI tokens, compliance, and support below](./images/budget-iceberg.webp)

### 1. API Licensing and Third-Party Integrations

Almost every modern app relies on other software. Need a map? You'll pay Google Maps. Push notifications? Firebase or OneSignal. Text messages? Twilio. Payments? Your processor takes a cut. These aren't one-time fees; they are ongoing operational expenses that scale with your usage.

In your first year, if you haven't budgeted for these API costs, they quietly eat into your margins. Premium AI APIs are priced per request, which sounds trivial until you multiply by your daily active users.

### 2. Cloud Infrastructure and Scaling Fees

Studios often build in a sandbox environment. When you go live, you pay for hosting. The trap here is auto-scaling: if your app goes viral, your cloud provider spins up more capacity automatically and sends you the bill at the end of the month. You need someone to set guardrails and alerts on these costs — something rarely included in a basic development quote.

### 3. The "AI Premium": Training and Token Costs

If your app features a smart assistant or personalized recommendations, you are entering the world of large language models. Whether you use a commercial API or host an open model yourself, there is a per-token cost for everything the model reads and writes. If you need to fine-tune on your own data, the engineering hours and compute required are a separate line entirely.

### 4. App Store Deployment and Compliance Audits

Getting into the App Store isn't as simple as clicking upload. You need to meet Apple's and Google's ever-changing guidelines, and store fees apply to any in-app revenue. More importantly, if you handle user data under GDPR, CCPA, or HIPAA, you may need a formal security audit. Fintech and healthcare apps frequently require third-party penetration testing, and that is almost never in the initial dev quote.

## Regional Pricing: Where is Your Talent Located?

Geography remains a major lever in your budget. The ranges below reflect commonly reported market rates from directories like Clutch and GoodFirms — treat them as orientation, not as quotes, since they shift with demand and seniority.

### North America and Western Europe

You are paying for proximity, cultural alignment, and often better legal protection. If you are a well-funded startup that values same-timezone communication above all else, this is the premium option — and the burn rate reflects it.

### Eastern Europe and Latin America

Strong engineering education, established outsourcing markets, and workable timezone overlap with either the US or Western Europe. Rates sit meaningfully below North America without a corresponding drop in engineering quality.

### South Asia

The most budget-friendly tier, but it carries a management overhead. To succeed, you need very clear documentation and usually a dedicated project manager on your side. The risk is rarely code quality — there are excellent engineers in the region — it's requirements getting lost in translation.

## Strategic Ways to Lower Your Development Cost

Lowering cost doesn't mean cutting corners; it means being smarter about how you build.

### Start with a Product Discovery Phase

Spend two weeks mapping the product before spending months building it. In discovery you validate assumptions, map the technical architecture, and identify deal-breakers. Changing a feature on a whiteboard is dramatically cheaper than rewriting the module that depends on it.

### Prioritize a Tight MVP

The biggest budget killer is "what if" syndrome. What if we added a social feed? What if users want a dark theme? Every "what if" adds hours. Stick to the core problem. If it's a delivery app, the only questions that matter are: can they find food, can they pay, can the driver find them. Everything else is version two.

### Use Open-Source Libraries Wisely

Don't reinvent the wheel. If there's a well-maintained library for a chat interface or a charting tool, use it. Your developers should be building the unique value of your business, not the standard components the community perfected a decade ago.

### Continuous Testing to Avoid Technical Debt

If you wait until the end of the project to test, you'll find bugs baked into the foundation. A defect caught during the sprint it was written in is a small fix. The same defect found after launch may require unpicking everything built on top of it. Continuous QA is not a cost center; it's insurance against a rewrite.

## Comparing Development Models

How you hire is just as important as who you hire.

![Agency, freelancers, and hybrid hiring models compared by control, client load, and cost](./images/hiring-models.webp)

### Hiring an Agency vs. Freelancers

An agency provides a full team: project manager, designer, frontend, backend, QA. They have internal processes and accountability. You pay a premium for that structure, but it removes management load from you.

Freelancers are cheaper, but you become the project manager. If your lead developer disappears for a week, your project stops. Use freelancers when you have the technical knowledge to manage them, or when the task is small and well-defined.

### Building an In-House Team: The True Cost

Many founders think in salaries alone. But an in-house team costs far more than that: benefits, equipment, software licenses, workspace, and the substantial time cost of recruiting and onboarding. This usually becomes viable only once you have consistent revenue or funding to support a permanent payroll.

### The Hybrid Approach

This is the modern winner for most companies. You keep a product owner or CTO in-house to own the vision and the keys to the code, and outsource the heavy lifting to a trusted team. You get the control of in-house with the cost profile of outsourcing.

## How This Plays Out on Real Projects

Abstract cost tiers only get you so far. Here is how the trade-offs looked on three of our own projects.

### Real-time video for music lessons — [Glinka Digital](/en/project/glinka-digital)

**The challenge:** teaching music over video, where compressed audio destroys exactly the detail a teacher needs to hear.

**The approach:** React Native for the interface, since the screens are conventional, with the engineering effort concentrated on the media pipeline and the backend.

**The lesson:** when the hard part is real-time media, the budget belongs on the backend, not the UI. Cross-platform on the front is what freed the budget to spend there.

### Fleet management MVP in 90 days — [SWAPPZ](/en/project/swappz)

**The challenge:** an electric vehicle rental operator in the UAE needed a working platform with five distinct user roles inside a hard 90-day deadline.

**The approach:** scope frozen early, architecture decided upfront, sprints used to sequence delivery rather than to renegotiate requirements.

**The lesson:** a hard deadline is itself a budget constraint. Narrow scope is what makes complex role models shippable in a quarter.

### A payments company website — [LIFE PAY](/en/project/life-pay)

**The challenge:** a corporate site that generated leads every day and could not go dark during a redesign.

**The approach:** several template generations coexisting in one codebase, with routes switched over page by page. Legacy URLs kept working and the lead funnel was never rebuilt from scratch.

**The lesson:** incremental migration costs more in engineering time than a rewrite, and less in lost revenue and lost search rankings. That trade is usually worth making.

## Common Budget Killers (And How to Avoid Them)

### Scope Creep: The Silent Budget Destroyer

Scope creep happens when you add "just one little thing" every week. Individually these seem small. Collectively they push a project months past its deadline. The fix is a Phase 2 list: every new idea goes on it, and nothing comes off it until the MVP is live.

### Underestimating QA

Testing is not a final check. It is a rigorous process of trying to break the app. If you don't budget for professional QA, your users become your testers — and in 2026 a crash on first launch usually means a permanent uninstall.

### Ignoring Marketing and User Acquisition

This isn't a development cost, but it kills budgets because it's forgotten. If you spend everything on building and nothing on telling people, you have an expensive paperweight. Set aside a meaningful reserve for launch marketing and app store optimization before you commit the last of your budget to features.

## Choosing the Right Partner for Your Vision

Picking a developer is like picking a co-founder. You're going to be in the trenches together for months.

### Red Flags in a Developer's Quote

**The yes-man.** If they agree to every feature without asking why, or how it makes money, they're billing hours, not building a product.

**A firm price for vague specs.** If they give you a confident number after a ten-minute call, they will either cut corners or come back with change orders that double it.

**No mention of post-launch support.** An app is a living thing. If the quote ends the day it hits the store, walk away.

### Questions You Must Ask Before Signing the Contract

- How do you handle technical debt during the build?
- Can I see a breakdown of the third-party API costs I should expect?
- Who owns the intellectual property and the source code at every stage? (It should be you.)
- What is your process for security testing and data privacy?

## Final Thoughts: Thinking Beyond the Launch

By 2026, "build it and they will come" has been thoroughly debunked. The cost of an app isn't a hurdle to clear; it's an investment in a business engine.

As you move forward, remember that launch day is day zero. The real work — and a large share of the real cost — comes from reacting to user feedback, keeping up with OS updates, scaling infrastructure, and staying ahead of competitors. Plan for the hidden costs now, prioritize ruthlessly, and choose a partner who challenges your assumptions.

The quote you get from a studio is the start of a conversation, not the end of it. If you want that conversation to start with a realistic scope rather than an optimistic number, [talk to our team](/en/services/mobile-development) — we map constraints to a delivery model before anyone writes code. For how delivery models fit constraints, see also [SDLC methodologies compared](/en/blog/sdlc-methodologies-compared).

---

## Blog: Автоматизация бизнес-процессов: с чего начать и что автоматизировать в первую очередь

- **Slug:** `avtomatizaciya-biznes-processov`
- **Locale:** `ru`

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

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

## Когда автоматизация бизнес-процессов окупается, а когда преждевременна

Автоматизация бизнес-процессов — не волшебная таблетка. Иногда она экономит сотни часов работы в месяц, а иногда создаёт проблемы там, где их не было. По опыту, примерно каждый третий запрос на автоматизацию заканчивается разговором «вам пока рано». Рассмотрим, почему.

### Когда автоматизировать рано

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

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

Третья: задачу полностью закрывает готовый облачный сервис без кастомизации. Например, для рассылки клиентам достаточно стандартного инструмента, для управления проектами хватает Kaiten. Создавать собственную платформу там, где готовое программное обеспечение решает задачу за пару часов настройки, — ошибка, которую часто допускают компании среднего и крупного бизнеса.

### Когда автоматизация окупается

А теперь обратная сторона. Есть три основных признака, по которым ясно: пора.

Повторяющиеся операции съедают ощутимую долю рабочего времени. Менеджер отдела продаж два часа в день переносит информацию между таблицами — это 40 часов в месяц. Полная ставка сотрудника, который не продаёт, а копирует ячейки. Здесь автоматизация процессов компании даёт измеримый результат уже в первый месяц, а эффективность отдела растёт без найма.

Ошибки в процессе стоят денег. Если сотрудник перепутал сумму в счёте, забыл отправить документ клиенту или потерял заявку, бизнес теряет выручку. Человеческим фактором нельзя управлять бесконечно: обучение, контроль, чек-листы помогают до определённого предела. Автоматические проверки и маршруты согласования снимают этот риск.

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

### Зачем нужен аудит до старта

Определить, в какой ситуации находится организация, со стороны проще, чем изнутри. Именно поэтому любой проект начинается с анализа: какие рабочие процессы действительно готовы к автоматизации, а где лучше сначала навести порядок. Такой аудит помогает не тратить бюджет на то, что ещё не созрело, и выстроить стратегию цифровой трансформации бизнеса. Подробнее о том, как это выглядит на реальном проекте, можно посмотреть в [кейсе «Спектрохим»](/ru/project/spektrokhim).

Честная позиция — отговорить клиента, если видно, что рано — экономит обеим сторонам время, ресурсы и нервы. Думаю, это единственный подход, при котором внедрение автоматизации потом действительно даёт результат.

## Признаки того, что бизнесу пора менять подход

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

### Информацию переносят из системы в систему руками

Менеджер получает заявку с сайта на почту, копирует контакты клиента в Excel, потом вносит в CRM, потом дублирует в 1С для выставления счёта. Одни и те же сведения вбивают три-четыре раза. Каждый ввод — это время и риск ошибок. Опечатка в номере телефона, потерянная буква в адресе, неправильная сумма. Несколько часов в неделю сотрудники заняты задачей, которую интеграция между системами решает без участия людей.

### Данные в разных системах расходятся

В CRM сделки закрыты, в 1С оплаты нет, в таблице отдела логистики — другая версия статуса. Руководитель запрашивает отчёт и видит три разных числа от трёх сотрудников. Без единой базы данных невозможно принимать решения быстро. По опыту, именно расхождение информации — история, которая часто становится главной причиной хаотичного управления компанией при росте.

### Отчёты для руководства собирают полдня или дольше

Если, чтобы получить полную картину по продажам за месяц, нужно собирать сведения из нескольких мест, сводить в Excel и считать показатели — это сигнал. Отчётность не должна быть проектом. В нормально настроенной программе отчёт формируется за минуты. Когда на это уходит полдня, бизнес платит дважды: за время сотрудника и за запоздалые решения на основе устаревших цифр.

### При росте объёмов первая реакция — нанять ещё сотрудника

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

### Ключевые процессы живут в голове одного сотрудника

Это, думаю, самый опасный признак. Один специалист знает, как формировать отгрузку, как считать бонусы, как выгружать сведения для налоговой. Он уходит в отпуск — и выполнение задач встаёт. Увольняется — и компания теряет не сотрудника, а процесс. Здесь проблема даже глубже: сначала процесс нужно описать и зафиксировать, а уже потом автоматизировать. Но сам факт, что знание хранится в чьей-то голове, а не в информационных системах, показывает: бизнес зависит от человеческого фактора там, где не должен.

Любой из этих сигналов по отдельности — неприятность. Два-три одновременно — системная проблема, которая с развитием компании будет только нарастать.

## Анализ бизнес-процессов: что именно автоматизируют

Разобравшись с сигналами, логично задать вопрос: а что можно автоматизировать? Анализ бизнес-процессов компании обычно выявляет пять направлений, где ручной труд съедает больше всего времени.

### Учёт и работа с данными

Сбор, хранение, синхронизация данных между системами. Картина «до»: менеджер отдела продаж вносит заказ в Google Sheets, бухгалтерия дублирует те же сведения в 1С, склад ведёт свой Excel. Три источника, три версии правды. После автоматизации данные вводятся один раз и сами распределяются по нужным базам. Это сокращение рутинных задач в чистом виде. Подробнее о том, как это реализовано в лабораторной отрасли, можно прочитать [в разборе интеграции 1С для лабораторий](/ru/blog/1c-dlya-laboratorii).

### Документооборот

Генерация документов — счета, договора, акты, коммерческие предложения. «До»: сотрудник открывает шаблон, подставляет реквизиты, проверяет суммы, отправляет на согласование по почте. На каждый документ уходит от десяти минут до часа. «После»: система электронного документооборота сама подтягивает данные клиента из CRM, формирует документ по шаблону и отправляет его на подпись. Менеджер тратит полминуты вместо получаса. Результат — быстрее выполнение, меньше человеческого фактора.

### Обработка заявок и обращений

Входящий запрос с сайта, письмо на почту, сообщения в чат, звонок — всё это нужно зафиксировать, распределить по ответственным, отследить статус. Без автоматизации заявки теряются, а коммуникации с клиентами становятся хаотичными. С помощью автоматических уведомлений и маршрутизации каждое обращение попадает в CRM, а ответственный получает задачу. Взаимодействие с клиентами становится прозрачным, а качество клиентского сервиса растёт. Как это выглядит на практике в edtech-компании, показывает [кейс в сфере образовательных технологий](/ru/solutions/edtech).

### Отчётность и аналитика

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

### Интеграции между системами

Самая недооценённая часть автоматизации бизнес-процессов. В компании уже есть 1С, CRM, сайт, мессенджеры — но каждый сервис живёт отдельно. Сотрудники выполняют роль «переводчиков» между программами. Интеграции связывают эти инструменты в единую систему: заказ с сайта автоматически попадает в CRM, оттуда — в 1С, а клиент получает уведомления в Telegram. Как комплексное решение с интеграциями реализовано в логистике, разобрано [на примере логистической платформы](/ru/solutions/logistics).

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

## Технологии автоматизации бизнес-процессов: три варианта решения

Когда компания определилась, какой процесс автоматизировать первым, встаёт вопрос: как именно это сделать? Технологии автоматизации бизнес-процессов сводятся к трём вариантам. Каждый со своими сильными и слабыми сторонами, и выбор зависит не от моды, а от конкретной ситуации в бизнесе.

### Готовое коробочное решение (SaaS)

Облачные интернет-сервисы вроде amoCRM или «МойСклад» закрывают типовые задачи: управление продажами, учёт товаров, обработку заявок с сайта. Запуск быстрый, стоимость предсказуемая, обучение команды проще. Но есть потолок. Если процессы компании отличаются от «среднего по рынку», система начинает сопротивляться. Настраивать её под себя можно лишь в рамках того, что заложил разработчик. И ещё: сведения хранятся на чужих серверах, а это вопрос безопасности данных, конфиденциальности и зависимости.

Подходит, когда задача стандартная, штат небольшого размера, а бюджета на разработку нет.

### Доработка существующей системы

У большинства компаний уже стоит 1С или CRM. Логичный шаг — нарастить функции того, за что уже заплачены деньги. Например, лаборатория ведёт учёт реактивов в 1С, но результаты анализов фиксирует в Excel. Можно доработать 1С так, чтобы она закрывала и эту задачу.

Главная проблема этого варианта — «костыли». Каждая доработка добавляет сложности, и в какой-то момент система становится хрупкой: обновление ломает кастомный модуль, а новые сотрудники не понимают, почему кнопка «Сформировать отчёт» требует трёх предварительных действий. Чем больше специфики, тем выше риски упереться в архитектурный предел платформы.

### Собственная разработка

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

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

### Какой вариант выбрать

На практике чистый выбор одного варианта — редкость. Чаще всего используют связку: учёт и документооборот остаются в 1С, а специфическую бизнес-логику (например, управление проектами с отраслевыми особенностями или сложные сценарии взаимодействия с клиентами) выносят в отдельный контур. Такой подход позволяет экономить на стандартных задачах и вкладываться в разработку только там, где это действительно нужно.

Думаю, честный критерий такой: если готовый сервис закрывает 80% потребностей, берите его. Если закрывает меньше половины, а оставшееся приходится обходить ручной работой, стоит смотреть в сторону доработки или собственного решения.

## Почему связка «учётная система + отдельный контур» эффективнее

Эта связка — программа для учёта плюс отдельный контур для специфики — на практике демонстрирует лучшие результаты, чем попытка уместить всё в одну программу. Разберём, почему.

### Учётная система делает своё дело

Бухгалтерия, зарплата, складской учёт, электронный документооборот — всё это стандартные процессы. Они одинаковы для [химической лаборатории](/ru/solutions/chem-lab) и логистической компании: учёт типовой, а специфика живёт отдельно.

Тот же принцип работает в [коворкинге](/ru/solutions/coworking): биллинг и доступы выносят в свой контур, а бухгалтерию оставляют в учётной системе. 1С и другие подобные платформы закрывают стандартные задачи хорошо, потому что разработчик обновляет систему под изменения законодательства, формы отчётности, налоговые ставки. Компании не нужно тратить ресурсы на поддержку того, что и так работает.

Проблемы начинаются, когда в эту же систему пытаются добавить отраслевую специфику. Технически это возможно — через доработки, внешние обработки, нестандартные конфигурации. Но каждое обновление рискует сломать эти надстройки. Результат: сотрудники начинают обходить неудобные места. Подробнее о том, [почему сотрудники лабораторий обходят LIMS](/ru/blog/why-lab-staff-bypass-lims), разобрано в отдельном материале.

### Отдельный контур для специфики

Когда уникальные процессы компании вынесены в собственный модуль или приложение, картина меняется. Учётная система продолжает обновляться, соответствует требованиям регуляторов. А отдельный контур развивается под конкретные цели бизнеса — без ограничений коробочного продукта.

Связь между контурами идёт через контролируемую интеграцию. Каждый контур отвечает за своё. Опыт [проекта «Спектрохим»](/ru/project/spektrokhim) это подтверждает: бухгалтерия осталась в 1С, а полный цикл лабораторных операций ушёл в отдельную систему. Сотрудники перестали переносить сведения между таблицами, количество ошибок упало, а скорость выдачи протоколов выросла.

### Почему это эффективнее единой системы

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

Есть ещё один фактор: управляемость изменений. Когда нужно добавить новый отчёт или перестроить логику согласования, изменения касаются только одного контура. Нет риска, что доработка учёта проб сломает начисление зарплаты. Для бизнеса это означает повышение скорости внедрения улучшений и спокойствие после каждого релиза.

## Внедрение автоматизации бизнес-процессов: этапы от аудита до масштабирования

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

### Анализ бизнес-процессов: зафиксировать, как всё устроено сейчас

Первый шаг — описать текущие процессы не в голове, а на бумаге или в схеме. Кто выполняет задачи, как получает сведения, куда передаёт результат. Анализ помогает найти узкие места — точки, где процесс тормозит, появляются ошибки, где сотрудник делает работу, которую проще автоматизировать. Без этого решение строится на догадках. Подробнее о том, как такой анализ выглядит в реальном проекте, можно посмотреть [на примере «Спектрохим»](/ru/project/spektrokhim).

### Приоритизация: выбрать один процесс, а не десять

После анализа обычно видно несколько проблемных мест. Соблазн — автоматизировать всё сразу. Это ошибка. Лучше выбрать один-два процесса с максимальным соотношением «боль / стоимость решения».

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

### Проектирование: описать, как процесс должен работать

На этом этапе описывается целевой процесс — не «хотим, чтобы было быстрее», а конкретная последовательность действий. Как система получает сведения, какие правила обработки применяет, кому и в каком виде отправляет результат.

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

### Пилот на одном участке

Это самый недооценённый этап. Запуск в ограниченном периметре — один отдел, одно направление, одна операция — позволяет собрать обратную связь от реальных пользователей до того, как решение масштабируется на всю компанию.

Пилот демонстрирует, работает ли система в реальном режиме. Здесь всплывают проблемы: интерфейс неудобен, логика согласования не учитывает исключения. Исправить это на пилоте — быстро и дёшево. Исправлять после полного запуска — дорого.

Не пропускайте пилот. Это не «лишний» этап, а страховка бюджета.

### Обучение сотрудников — с первого дня, а не после релиза

Главная ошибка: систему спроектировали, запустили и только потом показали сотрудникам. Результат предсказуем — люди саботируют новые инструменты и продолжают вести учёт руками. Корпоративная культура и политика управления персоналом сопротивляются изменениям, если их навязывают без объяснений.

Обучение должно начинаться с вовлечения конечных пользователей на этапе анализа. Когда сотрудник участвует в проектировании, он воспринимает систему как свою. Некоторые компании даже организуют внутренние онлайн-курсы по работе с новыми инструментами — это ускоряет адаптацию и поможет внедрять автоматизацию без сопротивления команды.

### Масштабирование: подключить остальные процессы

Когда пилот дал результат, обучение проведено и коллектив стабильно использует новую систему — можно подключать другие направления и подразделения. Масштабировать проще, если архитектура позволяет добавлять новые модули без переделки ядра. Именно поэтому выбор технологии на этапе проектирования так важен: комплексное решение, собранное для одного отдела, может не выдержать нагрузки всего предприятия.

## Почему проекты автоматизации проваливаются

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

### Систему спроектировали без тех, кто в ней будет работать

Руководитель решил, интегратор сделал, сотрудники получили готовый продукт. А дальше — тихий саботаж. Люди обходят систему, ведут параллельный учёт в Excel. Не потому что вредные — потому что им неудобно. Их реальные рабочие процессы никто не спрашивал. Конечные пользователи должны участвовать в проектировании с первого дня. Иначе компания получает дорогой инструмент, который никто не использует.

### Автоматизировали хаос

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

### Нет поддержки первого лица

Внедрение автоматизации — это всегда изменения. Изменения задевают интересы. Руководитель отдела продаж не хочет прозрачной воронки, потому что станет видно реальное количество потерянных клиентов. Бухгалтерия сопротивляется электронному документообороту. Если CEO не вовлечён лично, проект затухает на уровне среднего менеджмента. Без воли первого лица ни одна система управления бизнесом не приживётся.

### Попытка сделать всё сразу

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

### Нет измеримых критериев успеха

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

Если узнали свою ситуацию хотя бы в одном из этих сценариев — это не приговор. Но это сигнал перестроить подход до того, как затраты вырастут ещё больше.

## Частые вопросы об автоматизации бизнес-процессов

Ниже собраны вопросы, которые чаще задают собственники и руководители перед стартом проекта. Ответы короткие, без воды.

### С какого процесса начать автоматизацию, если бюджет ограничен?

Выбирайте самый частый и рутинный процесс, где цена ошибки минимальна. Например, ручной перенос заявок с сайта в CRM или формирование типовых документов. Такой пилот безопасен: если что-то пойдёт не так, последствия легко исправить. А результат виден быстро, и его проще показать руководству, чтобы получить бюджет на следующие этапы автоматизации.

### Можно ли автоматизировать процессы без программистов?

Частично — да. No-code и low-code платформы, готовые интеграции между сервисами, настройки внутри CRM закрывают простые сценарии: автоматические уведомления, маршрутизацию задач, сбор сведений в единую базу. Но как только появляется сложная логика или нужна связка нескольких систем с разной архитектурой, без разработчиков не обойтись. Думаю, честная граница проходит так: если процесс описывается блок-схемой на одном листе, no-code справится. Если нет — нужен специалист.

### Сколько времени занимает внедрение?

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

### Как оценить, что автоматизация сработала?

Зафиксируйте показатели до запуска и сравните их с тем, что получилось после. Три метрики, которые подходят практически в любой ситуации: время выполнения операции (было 40 минут — стало 5), количество ошибок на этапе ввода (было 12 в неделю — стало 0), число сотрудников, занятых на процессе (было три — стал один). Без замеров «до» невозможно оценить, дала ли система результат. Также полезно отслеживать финансы: сравнивать затраты на процесс до и после внедрения.

### Что делать, если сотрудники сопротивляются новой системе?

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

## Выводы: первый шаг к системной автоматизации

Всё, что разобрано в этой статье, сводится к трём вещам.

### Процесс сначала, софт потом

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

### Один процесс до конца лучше десяти на полпути

Компании пытаются автоматизировать всё сразу. Результат предсказуем: ни одно направление не доведено до рабочего состояния, коллектив устал от изменений, бюджет потрачен. Успешный опыт демонстрирует: лучше взять один процесс, довести его до состояния, где автоматизированные операции функционируют без ручной поддержки, собрать обратную связь от пользователей, замерить результат — и только потом масштабировать. Так проще получить доверие команды и открыть новые возможности для оптимизации всей организации.

### Архитектура экономит деньги

Третья мысль — про долгосрочную экономию. Учёт ведётся в стандартной системе: 1С, CRM, сервисы электронного документооборота. А специфика бизнеса выносится в отдельный контур. Такая связка позволяет не переплачивать за кастомизацию и не мучить коробочное решение. Это не абстрактная рекомендация — это то, что в конкретных проектах сокращает стоимость владения системой в несколько раз за первые два-три года. Эффективность такого подхода подтверждается на предприятиях из разных отраслей — от производства и управления запасами до работы с поставщиками и обработки больших объёмов данных клиентов.

### Что сделать прямо сейчас

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

Если хотите разобраться глубже — [команда WAPP](/ru/services) проводит аудит процессов компании: помогает внедрить автоматизацию, определить возможности для оптимизации и выбрать необходимые инструменты. Доступ к услуге аудита — без обязательств и продаж «на старте». Просто разбор вашей ситуации с точки зрения тех, кто такие проекты делает регулярно. Больше материалов по теме — в нашем блоге, где мы публикуем новости, кейсы и практические руководства по автоматизации.

---

## Blog: Business process automation: where to start and what to automate first

- **Slug:** `avtomatizaciya-biznes-processov`
- **Locale:** `en`

You spent another half-day moving data from one spreadsheet to another, answered 40 identical emails, and forgot to call three clients back. The problem is not discipline. The problem is that you are doing by hand work a machine finishes in seconds.

The question is no longer whether business process automation is needed — it is where to start so you do not burn the budget. This piece is a full breakdown: from signs it is time to act, through implementation stages, to the mistakes even experienced teams trip over.

## When business process automation pays off — and when it is premature

Business process automation is not a magic pill. Sometimes it saves hundreds of hours a month; sometimes it creates problems where there were none. In our experience, roughly every third automation request ends with a conversation that says it is still too early. Here is why.

### When automation is premature

First case: the process is still unsettled. The company has launched a new sales stream, the manager changes how requests are handled every month, leadership is still experimenting with the funnel. If you automate a process that reshapes itself every three or four weeks, you will rebuild the system faster than you can finish shipping it. Money goes into a solution that is outdated before launch.

Second: the volume of operations is too small. Say an employee spends 15 minutes a day manually moving data from email into the CRM. Yes, it is routine. But automating it will cost more than a year of that work. Cutting 15 minutes will not recover project spend or ongoing support.

Third: a ready-made cloud service fully covers the need with no customization. Client email campaigns may need only a standard tool; project management may be fine in Kaiten. Building your own platform where off-the-shelf software solves the job in a couple of hours of setup is a mistake mid-market and enterprise companies make often.

### When automation pays off

Now the other side. Three main signals make it clear: it is time.

Repetitive operations eat a meaningful share of working time. A sales manager spends two hours a day moving data between spreadsheets — that is 40 hours a month. A full headcount that does not sell, but copies cells. Here, company process automation delivers measurable results in the first month, and department efficiency grows without hiring.

Process errors cost money. If an employee mixes up an invoice amount, forgets to send a document to a client, or loses a request, the business loses revenue. You cannot manage the human factor forever: training, controls, and checklists only go so far. Automated checks and approval routes remove that risk.

Scaling requires linear hiring. The company grows, order volume rises, and the only way to keep up is to hire more people for the same routine tasks. Every new hire must be found, onboarded, and supervised. Business process automation lets you grow without a proportional headcount increase.

### Why an audit before you start matters

It is easier to see where the organization stands from the outside than from within. That is why every project starts with analysis: which workflows are actually ready for automation, and where you should put order in place first. That audit keeps budget off what is not ready yet and helps shape a digital transformation strategy. For how this looks on a real project, see the [Spektrokhim case](/en/project/spektrokhim).

An honest stance — talking the client out of it when it is clearly too early — saves both sides time, resources, and nerves. In my view, that is the only approach where automation implementation later actually delivers results.

## Signs it is time for the business to change approach

Here is what an expert team most often sees when it arrives for a business process audit. Problems are rarely stated directly. People say “we cannot keep up” or “we need a CRM.” But when you break workflows down step by step, the same signals surface. If you recognize at least two from the list below, manual work is already holding the business back.

### Information is moved from system to system by hand

A manager gets a website lead by email, copies the client contacts into Excel, then enters them into the CRM, then duplicates them in 1C to issue an invoice. The same data is typed three or four times. Every entry costs time and risks errors: a typo in a phone number, a missing letter in an address, the wrong amount. Several hours a week go into a task that system-to-system integration solves without people involved.

### Data diverges across systems

In the CRM deals are closed; in 1C there is no payment; in the logistics spreadsheet the status is different again. Leadership asks for a report and sees three different numbers from three people. Without a single source of truth, fast decisions are impossible. In our experience, data mismatch is often the main driver of chaotic management as the company grows.

### Leadership reports take half a day or longer

If building a full picture of monthly sales means gathering data from several places, merging it in Excel, and calculating metrics by hand — that is a signal. Reporting should not be a project. In a well-configured system, a report takes minutes. When it takes half a day, the business pays twice: for employee time and for late decisions based on stale figures.

### Growth’s first response is to hire another person

More requests — hire another manager. More documents — another accountant. More clients — another operator for inbound. That works up to a point, then operating costs eat the margin. If every growth stage requires expanding staff for routine work, the company’s business processes need automation. Not because people are failing, but because repetitive operations are more efficiently done by a system.

### Critical processes live in one employee’s head

This is, I think, the most dangerous signal. One specialist knows how to form a shipment, how to calculate bonuses, how to export data for tax. They go on leave — and execution stops. They leave the company — and the business loses not a person, but a process. The issue goes deeper: the process must be described and fixed first, then automated. But the fact that knowledge lives in someone’s head rather than in information systems shows the business depends on the human factor where it should not.

Any one of these signals alone is unpleasant. Two or three at once is a systemic problem that will only grow as the company develops.

## Business process analysis: what exactly gets automated

Once the signals are clear, the natural question is: what can you automate? Company business process analysis usually surfaces five areas where manual work eats the most time.

### Accounting and data work

Collecting, storing, and syncing data across systems. The “before” picture: a sales manager enters an order in Google Sheets, accounting duplicates the same data in 1C, the warehouse keeps its own Excel. Three sources, three versions of the truth. After automation, data is entered once and distributed to the right databases. That is routine reduction in its pure form. For how this works in the lab industry, see [our breakdown of 1C integration for laboratories](/en/blog/1c-dlya-laboratorii).

### Document flow

Generating documents — invoices, contracts, acts, commercial proposals. “Before”: an employee opens a template, fills in details, checks amounts, sends it for approval by email. Each document takes from ten minutes to an hour. “After”: an electronic document management system pulls client data from the CRM, builds the document from a template, and sends it for signature. The manager spends half a minute instead of half an hour. Result: faster deals, less human factor.

### Handling requests and inquiries

An inbound website request, an email, a chat message, a call — all of it must be logged, assigned to owners, and tracked. Without automation, requests get lost and client communication becomes chaotic. With automatic notifications and routing, every inquiry lands in the CRM and the owner gets a task. Client interaction becomes transparent, and service quality rises. For how this looks in practice at an edtech company, see the [educational technology case](/en/solutions/edtech).

### Reporting and analytics

Leadership wants to see weekly sales, average check size, team performance. “Before”: someone spends half a day gathering reports, merging sources, building charts in Excel. “After”: a dashboard updates automatically and shows key metrics in real time. That lets you use analytics for decisions based on current numbers. Analytics stops being a large-business luxury and becomes a working management tool.

### Integrations between systems

The most undervalued part of business process automation. The company already has 1C, a CRM, a website, messengers — but each service lives alone. Employees act as “translators” between programs. Integrations stitch these tools into one system: an order from the site lands in the CRM automatically, then in 1C, and the client gets Telegram notifications. For a full solution with integrations in logistics, see the [logistics platform example](/en/solutions/logistics).

All five areas are connected. But start with the area where time and resource loss is highest — and move to the next only when the first one runs stably.

## Business process automation technologies: three solution options

Once the company knows which process to automate first, the question becomes: how exactly? Business process automation technologies come down to three options. Each has strengths and weaknesses, and the choice depends not on trends but on the concrete situation in the business.

### Ready-made boxed solution (SaaS)

Cloud services such as amoCRM or MoySklad cover typical tasks: sales management, inventory, website lead handling. Launch is fast, cost is predictable, team training is simpler. But there is a ceiling. If company processes differ from “market average,” the system starts to resist. You can only configure it within what the vendor built in. And another point: data lives on someone else’s servers — a question of security, confidentiality, and dependency.

Fits when the task is standard, the team is small, and there is no budget for development.

### Extending an existing system

Most companies already run 1C or a CRM. The logical step is to grow the product you have already paid for. For example, a lab tracks reagents in 1C but records analysis results in Excel. You can extend 1C to cover that as well.

The main problem with this path is “crutches.” Every customization adds complexity, and at some point the system becomes fragile: an update breaks a custom module, and new hires do not understand why the “Generate report” button needs three prior steps. The more industry specificity you have, the higher the risk of hitting the platform’s architectural limit.

### Custom development

The third option is to build a business process automation system from scratch: a web app, an internal platform. Fully aligned with your processes, no compromises. But more expensive at the start and slower to first result. Without a solid brief and team involvement, the project turns into an endless build.

When is it justified? When the process is unique to the industry, when ready-made tools fall short, when you need deep integration of several systems into one environment. For a large enterprise with non-standard workflows, this is often the only option that gives full control over product evolution.

### Which option to choose

In practice, a pure single-option choice is rare. More often you use a mix: accounting and document flow stay in 1C, while specific business logic (for example, project management with industry quirks or complex client interaction scenarios) moves into a separate contour. That approach saves money on standard tasks and invests in development only where it is truly needed.

My honest criterion: if a ready-made service covers 80% of needs, take it. If it covers less than half and the rest is patched with manual work, look toward customization or a custom build.

## Why “accounting system + separate contour” works better

This pairing — an accounting program plus a separate contour for specifics — consistently outperforms trying to fit everything into one product. Here is why.

### The accounting system does its job

Bookkeeping, payroll, warehouse accounting, electronic document flow — these are standard processes. They are the same for a [chemical laboratory](/en/solutions/chem-lab) and a logistics company: accounting is typical, and specificity lives elsewhere.

The same principle works in [coworking](/en/solutions/coworking): billing and access move into their own contour, while bookkeeping stays in the accounting system. 1C and similar platforms handle standard tasks well because the vendor updates the system for legislation changes, reporting forms, and tax rates. The company does not spend resources maintaining what already works.

Problems start when you try to add industry specifics into that same system. Technically it is possible — through customizations, external processors, non-standard configurations. But every update risks breaking those add-ons. Result: employees start bypassing the awkward parts. For more on [why lab staff bypass LIMS](/en/blog/why-lab-staff-bypass-lims), see a separate article.

### A separate contour for specifics

When unique company processes live in their own module or app, the picture changes. The accounting system keeps updating and stays compliant. The separate contour evolves for concrete business goals — without the limits of a boxed product.

The link between contours runs through controlled integration. Each contour owns its domain. The [Spektrokhim project](/en/project/spektrokhim) confirms this: bookkeeping stayed in 1C, and the full lab operations cycle moved into a separate system. Staff stopped moving data between spreadsheets, error rates dropped, and protocol turnaround sped up.

### Why this beats a single system

The main reason is simple: two specialized systems, each doing its job well, are more reliable than one universal system that does everything mediocrely. The standard contour is cheaper to maintain. The specific contour is easier to evolve — no foreign architecture constraints, and the interface is built for real users.

There is another factor: change control. When you need a new report or a reworked approval logic, changes touch only one contour. There is no risk that customizing sample accounting breaks payroll. For the business, that means faster improvement rollout and calm after every release.

## Implementing business process automation: stages from audit to scale

From technology choice to action. Business process automation implementations fail not because of bad software, but because of missing sequence. Below are six stages, each with its own job.

### Business process analysis: capture how things work today

First step — describe current processes not in someone’s head, but on paper or in a diagram. Who does the work, how they get information, where they pass the result. Analysis finds bottlenecks — points where the process stalls, errors appear, or an employee does work that is easier to automate. Without this, the solution is built on guesses. For how this analysis looks on a real project, see the [Spektrokhim example](/en/project/spektrokhim).

### Prioritization: pick one process, not ten

After analysis you usually see several problem areas. The temptation is to automate everything at once. That is a mistake. Better to choose one or two processes with the best “pain / solution cost” ratio.

A simple scoring rule: frequency × effort per cycle × cost of error. There are usually enough daily routines that take hours of staff time. For example, manual entry from orders into the accounting system: done dozens of times a day, minutes per operation, and an error means returns and lost clients. That is the first candidate.

### Design: describe how the process should work

At this stage you describe the target process — not “we want it faster,” but a concrete sequence of actions. How the system receives data, which processing rules it applies, whom it notifies and in what form.

This is also where you choose technology and automation tools: extending an existing CRM, integrations with 1C, building a separate service. From that description comes the technical brief. Documentation locks in core requirements and timelines. Without it, development turns into an endless “and let’s also add this.”

### Pilot on one segment

This is the most undervalued stage. Launching in a limited perimeter — one department, one stream, one operation — lets you gather feedback from real users before the solution scales company-wide.

A pilot shows whether the system works in real conditions. Problems surface here: the interface is awkward, approval logic misses exceptions. Fixing that on a pilot is fast and cheap. Fixing it after a full launch is expensive.

Do not skip the pilot. It is not an “extra” stage — it is budget insurance.

### Train employees from day one, not after release

The main mistake: design the system, launch it, and only then show it to staff. The result is predictable — people sabotage new tools and keep accounting by hand. Corporate culture and people management resist change when it is imposed without explanation.

Training should start by involving end users at the analysis stage. When an employee helps design the system, they treat it as their own. Some companies even run internal online courses on new tools — that speeds adaptation and helps roll out automation without team resistance.

### Scale: connect the remaining processes

When the pilot delivered results, training is done, and the team stably uses the new system — you can connect other streams and units. Scaling is easier if the architecture lets you add modules without rewriting the core. That is why technology choice at design time matters so much: a solution built for one department may not hold the load of the whole enterprise.

## Why automation projects fail

Most business process automation failures are not about software. Problems start earlier — at the level of decisions people make. Here are five scenarios that repeat from project to project.

### The system was designed without the people who will use it

Leadership decided, the integrator built, employees received a finished product. Then — quiet sabotage. People bypass the system and keep parallel Excel ledgers. Not because they are difficult — because it is inconvenient. Nobody asked about their real workflows. End users must take part in design from day one. Otherwise the company gets an expensive tool nobody uses.

### Chaos was automated

If the process is not tuned, automation only speeds up the mess. A manager handles requests “however it goes,” document approval rules change every time — and all of that is moved into CRM or ERP “as is.” Result: the system works, but works poorly, because crooked logic was built in. Before automating company processes, describe them and cut unnecessary steps.

### No sponsorship from the first person

Automation implementation always means change. Change touches interests. A sales head may not want a transparent funnel because lost clients become visible. Accounting may resist electronic document flow. If the CEO is not personally involved, the project dies at middle management. Without first-person will, no business management system takes root.

### Trying to do everything at once

The company decides to automate accounting, request handling, project management, marketing and ads, reporting, and HR in parallel. Budget scatters; no stream reaches a working state. Six months later — team fatigue, overspend, and zero result. Practice shows: better to finish one process and get a measurable effect than to launch five parallel streams.

### No measurable success criteria

“We want to optimize work” is not a goal. It is a wish. If you did not lock specific metrics before start — request handling time, input error count, task completion speed — you cannot evaluate the result later. Without clear metrics, the project becomes endless customization. And the money is already spent.

If you recognize your situation in even one of these scenarios — it is not a verdict. But it is a signal to reshape the approach before costs grow further.

## Frequently asked questions about business process automation

Below are the questions owners and leaders ask most often before a project starts. Answers are short and direct.

### Which process should I automate first if the budget is limited?

Pick the most frequent, routine process where the cost of error is low. For example, manually moving website leads into the CRM or generating standard documents. That kind of pilot is safe: if something goes wrong, the consequences are easy to fix. Results show up quickly and are easier to present to leadership to unlock budget for the next automation stages.

### Can you automate processes without developers?

Partly — yes. No-code and low-code platforms, ready-made service integrations, and CRM settings cover simple scenarios: automatic notifications, task routing, collecting data into one base. But as soon as complex logic appears, or you need to link several systems with different architectures, you need developers. An honest boundary: if the process fits on a one-page flowchart, no-code can handle it. If not — you need a specialist.

### How long does implementation take?

It depends on scale. A pilot on one process — two to six weeks. Full automation across several streams — three to nine months. Timelines grow when processes are not described before start, or when the work logic itself changes in parallel. A more precise answer is only possible after analysis.

### How do you know automation worked?

Lock metrics before launch and compare them with what you get after. Three metrics that fit almost any situation: operation time (was 40 minutes — now 5), input error count (was 12 a week — now 0), number of people on the process (was three — now one). Without “before” measurements, you cannot tell whether the system delivered. Tracking finances also helps: compare process cost before and after implementation.

### What if employees resist the new system?

Involve them from the design stage instead of presenting a fait accompli. People sabotage what was imposed without explanation. Show personal upside: the manager sheds routine and spends time on work that earns a bonus. Collect feedback after the pilot, provide training and support in the first weeks. Resistance is a normal reaction. Problems start when it is ignored.

## Takeaways: the first step toward systematic automation

Everything covered in this article comes down to three points.

### Process first, software second

The main mistake is starting with platform choice. CRM, ERP, custom build — these are tools. They are useless until you have an honest description of how work actually happens today. Not “how it should work” and not “what the policy says,” but how employees act every day. Where they move data by hand, where requests get lost. Without that analysis, automation implementation is a lottery. Using AI at this stage can help build an accurate process map through software modeling and tighten planning.

### One process finished beats ten halfway done

Companies try to automate everything at once. The result is predictable: no stream reaches a working state, the team is tired of change, the budget is spent. Successful experience shows: better to take one process, bring it to a state where automated operations run without manual support, collect user feedback, measure the result — and only then scale. That makes it easier to earn team trust and open further optimization across the organization.

### Architecture saves money

The third idea is about long-term savings. Accounting stays in a standard system: 1C, CRM, electronic document services. Business specifics move into a separate contour. That pairing avoids overpaying for customization and forcing a boxed product. This is not an abstract recommendation — in concrete projects it cuts total cost of ownership several times over the first two or three years. The approach holds across industries — from production and inventory management to supplier work and processing large volumes of client data.

### What to do right now

Take a sheet of paper or open a note on your phone. List five repeating tasks you or your employees do every day. Mark the one that takes the most time and requires no decisions — only mechanical actions. That is your first automation candidate. Finding that process is already half the work.

If you want to go deeper — the [WAPP team](/en/services) runs company process audits: helping implement automation, identify optimization opportunities, and choose the right tools. Audit access comes without obligations or hard sell at the start. Just a breakdown of your situation from people who run these projects regularly. More on the topic is in our blog, where we publish news, cases, and practical guides on automation.

---

## Blog: Зачем платить за проектирование и как ТЗ страхует бюджет

- **Slug:** `budget-ten-percent-stakes`
- **Locale:** `ru`

Проект сгорает, выделенный бюджет закончился, а приложение до сих пор не работает так, как планировалось. Вместо готового продукта на руках — бесконечный список правок и недовольные разработчики. Это классический финал разработки, которая началась без технического задания (ТЗ).

## Рисковать деньгами Виталия на «понятных» словах

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

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

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

## Экономить ресурсы через детальное планирование

Запуск IT-проекта без плана напоминает строительство дома без чертежей. Строители могут возвести стены не в том месте, закупить лишние материалы и потратить время на переделки — всё это оплачивает заказчик. ТЗ в разработке фиксирует требования, бюджет и сроки, превращая хаос в предсказуемый процесс.

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

## Получать прозрачность и юридическую защиту

ТЗ — это не просто технический текст, а рабочий инструмент, который дает понимание каждой потраченной копейке. Документ исключает двоякие трактовки и делает отношения между заказчиком и студией прозрачными.

Наличие зафиксированного плана дает бизнесу ряд преимуществ:
* Стоимость работ фиксируется на берегу: если студия выйдет за рамки из-за своих просчетов, переплаты ложатся на её счет.
* ТЗ является интеллектуальной собственностью: с готовым планом можно уйти к любому другому подрядчику, не теряя наработанную логику.
* Сроки становятся реальными: проработка пользовательских сценариев позволяет точно оценить время на каждую задачу и предусмотреть пени за задержки.
* Документ определяет границы гарантии: если в приложении найден баг, ТЗ подскажет, является ли случай гарантийным.

## Интегрировать опыт в структуру документа

Качественное ТЗ описывает проект в деталях — от целей бизнеса до архитектуры связей. Мы в WAPP опираемся на компетенции, полученные в сложных проектах, чтобы не допускать критических ошибок на этапе реализации.

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

## Использовать проверенную структуру для контроля результата

Документ должен оставаться понятным даже человеку, который не занимается программированием каждый день. Мы используем четкую структуру, чтобы ЛПР мог контролировать ход разработки на любом этапе.

Стандартное ТЗ от WAPP включает в себя несколько ключевых блоков:
* Описание целей бизнеса: какую конкретную проблему решает продукт и как он поможет компании заработать.
* Глоссарий терминов: расшифровка таких понятий как CMS или мокап, чтобы все участники процесса говорили на одном языке.
* Технические требования: правила безопасности, лимиты нагрузки, список поддерживаемых браузеров и версий ОС.
* Логика работы: детальное описание поведения каждого блока на странице и сценариев взаимодействия пользователя с системой.
* Схема архитектуры: визуализация того, как данные передаются между модулями и сторонними сервисами, что критично для проектов вроде Xstreet или Fiftyfour.

Техническое задание описывает логику работы продукта, а визуальное воплощение фиксируется в UX-мокапах и дизайн-макетах.

## Защищать инвестиции через ТЗ

Любой проект, который стартует с качественного планирования, имеет шансы на успех и соблюдение бюджета. Это способ защитить бизнес от бесконечных доплат и получить именно тот инструмент, который нужен для роста компании. ТЗ дает контроль над результатом и уверенность в том, что продукт будет работать так, как зафиксировано в договоре.

---

## Blog: Hundreds of thousands at stake: how 10% of your budget can change your costs

- **Slug:** `budget-ten-percent-stakes`
- **Locale:** `en`

## Introduction

In product and digital work it is easy to focus on the big line items — engineering, ads, infra. Yet 10% of the budget spent on architecture, process, and clear analytics often offsets hundreds of thousands in “invisible” losses: rework, downtime, redundant integrations, and expensive maintenance.

Here we outline where small, targeted investments have the most leverage and how to avoid paying for stack you do not need.

## Where money leaks

- Misaligned specs and reality — costly post-launch iterations.
- Heavy client rendering where server-side flows and forms would suffice.
- Fragmented data — manual rollups and reporting mistakes.

## What to do in practice

Map your product’s critical path, estimate the hourly cost of team friction, and compare it to the price of a focused fix (stack review, simpler frontend, reporting automation). Deeper case notes and numbers will ship in the full article soon.

---

## Blog: Как запустить систему бронирования для коворкинга: опыт Fiftyfour

- **Slug:** `coworking-booking-system-fiftyfour`
- **Locale:** `ru`

Представьте, что вы просчитали бизнес-модель, создали сайт и брендбук для нового коворкинга, но клиенты всё еще не могут забронировать место онлайн. В 2019 году команда консалтингового агентства «Дком» столкнулась именно с этим при запуске Fiftyfour в Алматы. Готовых решений, которые можно было бы просто «купить и включить», на рынке не существовало, а уникальный дизайн требовал строгого соответствия брендбуку.

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

## Конкретизировать задачи и выбрать стек без сюрпризов

На старте стояли две цели: создать удобное веб-приложение для резидентов и панель управления для администраторов. Главный запрос — эффект «одного окна», чтобы пользователь мог оформить бронь без лишних переходов и долгих загрузок.

Для реализации выбрали проверенный стек WAPP: Vue.js и Laravel. Эти технологии идеально подходят для создания быстрых браузерных приложений. Пятилетний опыт работы с ними позволил нам гарантировать сроки и избежать технических «подводных камней» в процессе разработки.

## Собрать MVP за три месяца силами одного разработчика

Мы начали с минимально жизнеспособного продукта (MVP), чтобы проект как можно быстрее начал приносить пользу. В первой версии сфокусировались на личном кабинете резидента и самой логике бронирования, временно отложив внедрение онлайн-оплаты.

Система работает интуитивно:
1. Пользователь регистрируется и выбирает тип локации: рабочее место, переговорная или зал для мероприятий.
2. Указывает дату и время.
3. Добавляет услуги — от снеков до аренды флипчарта.
4. Вся процедура проходит на одной странице, что создает тот самый бесшовный опыт, за которым пришел клиент.

## Превратить личный кабинет в полноценную экосистему

За следующие полгода WAPP расширила функционал приложения, превратив его в мощный инструмент для бизнеса. Мы интегрировали платежный модуль Сбера, сохранив при этом возможность оплаты на месте. 

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

В кабинете администратора теперь можно:
* Управлять бронями и оформлять заказы, поступившие через соцсети или по телефону.
* Выгружать отчеты по продажам и анализировать загруженность помещений.
* Запускать маркетинговые акции и настраивать скидки для привлечения резидентов.

## Автоматизировать уведомления через Telegram-бота

Чтобы администраторы не пропускали заказы, мы создали бота-помощника. Он мгновенно отправляет уведомления о новых бронях в Telegram или на почту. Это позволяет команде реагировать оперативно, даже если они не находятся в этот момент перед монитором. Автоматизация уведомлений снижает риск упустить клиента до нуля.

## Выбрать между «коробкой» и кастомной разработкой

Сегодня рынок предлагает множество готовых систем для коворкингов. Однако опыт Fiftyfour показывает, что типовые решения подходят не всем. Если вы хотите, чтобы интерфейс был продолжением вашего бренда, а бизнес-процессы учитывали уникальные услуги — кастомная разработка становится необходимостью.

Мы рекомендуем использовать готовое ПО, если ваши процессы типичны и вы готовы подстроиться под логику системы. Если же софт должен подстраиваться под вас — пора задуматься о собственной разработке.

Перед тем как предлагать решение, WAPP всегда проводит глубокий бизнес-анализ. Мы помогаем определить, какой путь будет выгоднее для вашего продукта в долгосрочной перспективе.

Больше о контуре для коворкингов — бронь, биллинг и доступ — на странице [решений WAPP для коворкингов](/ru/solutions/coworking).

Подробное описание всех технических этапов и скриншоты интерфейсов доступны в [полном описании кейса Fiftyfour](/ru/project/fiftyfour).

---

## Blog: How to launch a coworking booking system: lessons from Fiftyfour

- **Slug:** `coworking-booking-system-fiftyfour`
- **Locale:** `en`

Imagine you have a business model, a website, and a brand book for a new coworking space — but members still cannot book a desk online. In 2019, the consulting agency Dcom hit exactly that problem when launching Fiftyfour in Almaty. There was no ready product they could simply buy and turn on, and the unique design had to follow the brand book strictly.

This article walks through nine months of turning manual operations into an automated system that saves administrators’ time and owners’ money.

## Lock the goals and pick a stack without surprises

At the start there were two goals: a convenient web app for residents and an admin panel for the front desk. The core ask was a “one-window” flow — book without extra hops and long loading screens.

We used a proven WAPP stack: Vue.js and Laravel. Both fit fast browser apps well. Years of shipping on them let us commit to timelines and avoid common technical traps mid-build.

## Ship an MVP in three months with one developer

We started with a minimum viable product so the project could create value as soon as possible. The first version focused on the resident portal and booking logic; online payments came later.

The flow is straightforward:
1. The user registers and picks a location type: desk, meeting room, or event hall.
2. They set date and time.
3. They add extras — from snacks to flipchart rental.
4. Everything happens on one page — the seamless experience the client asked for.

## Grow the portal into a full operations stack

Over the next six months WAPP expanded the product into a real business tool. We integrated a bank payment module while keeping pay-on-site as an option.

Bureaucracy got special attention: the system now generates contracts automatically. If a team rents an office for several months, the app builds the documents — managers stop filling Word templates by hand.

In the admin console you can now:
* Manage bookings and create orders that arrived via social channels or phone.
* Export sales reports and analyze space occupancy.
* Run promotions and configure discounts to attract residents.

## Automate alerts with a Telegram bot

So administrators do not miss orders, we built a helper bot. It sends instant notifications about new bookings to Telegram or email. The team can react even when nobody is sitting at the desk. Automated alerts cut the risk of losing a lead to near zero.

## Choose between a boxed product and custom build

Today the market offers many ready-made coworking systems. Fiftyfour shows that a box does not fit everyone. If the UI must continue your brand, and processes include unique services, custom development becomes the practical path.

We recommend boxed software when processes are standard and you can adapt to the product’s logic. If the software must adapt to you — it is time to consider a custom build.

Before recommending a path, WAPP runs a business analysis. We help decide which option costs less to own over the long term.

More on booking, billing, and access for coworking spaces — on the [WAPP coworking solutions](/en/solutions/coworking) page.

Full technical stages and UI screenshots are in the [Fiftyfour project case](/en/project/fiftyfour).

---

## Blog: 7 Signs You’ve Outgrown Your Coworking Management Software

- **Slug:** `coworking-management-software-7-signs`
- **Locale:** `en`

Most coworking spaces start with off-the-shelf software — and that is exactly the right call. The issue arises when your coworking space management software no longer aligns with your business operations.

Operational friction often builds quietly. Employees develop workarounds, managers add spreadsheets to fill gaps, and the software that once felt like a solution starts generating its own overhead. What looks like a subscription cost on a balance sheet is rarely the full picture. The real total includes additional modules, manual reconciliation hours, error correction, and the operational restrictions that quietly limit what your team can do.

But not every limitation signals a need for custom development. Some friction dissolves with better configuration. Some requires migrating to a more capable platform. And some — the kind that consistently blocks growth — may call for something built specifically around your operation.

This article identifies seven concrete signs that your current system has become a ceiling rather than a foundation. It also explains how to evaluate configuration, migration, and custom development as honest responses to each one. The most telling sign tends to show up in your team's daily routines — specifically, in what they are doing around the software rather than inside it.

## Sign 1: Your team still relies on spreadsheets and manual workarounds

When spreadsheets become load-bearing infrastructure, your coworking management software is no longer doing its job.

This pattern is easy to miss at first. A team member exports a member list to cross-check against a payment ledger. Another maintains a separate tab to track desk availability. Each workaround feels like a reasonable fix — until the fixes multiply. What begins as a shortcut becomes the primary system, and the official platform becomes just one input among several.

In practice, this creates a category of work that never appears in a job description but consumes hours every week. Common examples include:

* Manually copying booking confirmations into a billing spreadsheet
* Reconciling member balances across two or more disconnected tools
* Updating access permissions by hand after a payment is processed
* Maintaining a duplicate member database outside the core platform
* Exporting reports to reformat data the system cannot produce natively

Scaling amplifies every one of these tasks. As membership grows, the number of manual handoffs and potential errors grows with it. Administrative errors become more likely precisely because accuracy now depends on human consistency across parallel records, not on a single reliable source of truth.

The critical distinction here is between a temporary workaround and a structural platform limitation. A workaround fills a gap while a better process is developed. A structural limitation means the platform itself cannot support the operation without human intervention — and that gap never closes on its own.

If your team has normalized these manual steps, the next question worth asking is where else the disconnects are hiding — particularly in how bookings, billing, and access control talk to each other.

## Sign 2: Bookings, billing, memberships, and access are disconnected

Disconnected systems do not just create inconvenience — they create operational debt that compounds with every new member you add.

Picture a common scenario: a member pays for a hot desk package, but the payment processor and your coworking software do not share status information. The booking platform has no way to verify that payment cleared, so a staff member checks manually before confirming the reservation. The access control system, sitting in its own silo, has not received any signal at all. Someone still has to issue a key fob or update a PIN. When three systems cannot talk to each other, your team becomes the integration layer.

This distinction between closed and open API architectures matters enormously here. Limited or closed APIs can prevent systems from exchanging the data and actions required by the operator. A sufficiently capable API can allow payment status, booking confirmation, membership tier, and access permissions to be synchronized automatically. A cancelled membership, for example, should immediately revoke door access — not after a staff member notices the discrepancy on Monday morning.

The downstream cost is real. Employees spend measurable time each week reconciling inconsistencies that connected systems would resolve in milliseconds. And as your member count grows, so does the surface area for errors. That friction does not stay internal, either — members experience it as a space that feels disorganized.

If your locations are each compounding this problem independently, the challenge scales in a way that is difficult to reverse without rethinking the architecture entirely.

## Sign 3: Each location is managed as a separate business

When your coworking space software treats each location as its own silo, scaling from one site to several quickly becomes an operational burden rather than a business achievement.

Fragmented management forces your team to repeat tasks across different systems.

Member records are the most immediate casualty. Without a unified database, a member who joins your downtown location and later wants to drop into your midtown space has to re-register, re-verify, and sometimes re-pay a deposit. That friction weakens the cross-location experience that a multi-site network is supposed to provide.

Financial reporting suffers in parallel. When each location runs its own books and exports its own utilization data, consolidating performance across the network becomes a manual reconciliation exercise — the same spreadsheet dependency covered earlier, just at a larger scale. Operators lose the ability to compare desk utilization, revenue per square foot, or peak booking windows across sites in real time.

Local administrators still need location-specific permissions. The right coworking space software balances that autonomy with centralized visibility, allowing a site manager to control their floor plan without obscuring network-wide data from ownership. Without that balance, you either over-restrict local staff or grant access levels that compromise data integrity.

Solving these structural gaps often exposes a related challenge: even when locations are unified in one system, the pricing and membership rules governing each site may be too complex for the platform to handle.

## Sign 4: Your pricing and membership rules no longer fit the platform

When standard membership tiers cannot reflect how your business actually prices its services, your coworking membership management software has become a constraint rather than a tool.

A clear indicator is when administrators frequently create manual exceptions for pricing the system cannot model. Corporate accounts negotiated at custom rates, shared credit pools distributed across a team, or tiered overages that kick in after a set number of included hours — these requirements can become increasingly common as a coworking business adds corporate clients, locations, and more flexible membership models.

Location-specific pricing compounds the problem further. A desk in your downtown flagship may carry a different rate than the same desk category at a suburban site. If the platform treats all locations under a single pricing structure, operators are forced into workarounds that introduce billing errors and erode member trust.

Special booking limits and cancellation conditions follow the same pattern. Corporate contracts often carry negotiated grace periods or penalty-free cancellation windows that differ from standard terms. Capabilities vary significantly by product and subscription tier, so the gap may be addressable within your existing vendor. But if manual calculations are a daily occurrence, that is a signal worth investigating.

That kind of workflow friction often points to a deeper problem: the platform's integration layer itself.

## Sign 5: API and integration limits block critical workflows

An API can exist in name while still failing to expose the data or trigger the actions your coworking operation actually needs. That gap is where growth stalls.

A limited API is not the same as a functional one. In practice, operators discover this when they try to connect their coworking booking system to tools they already depend on — payment gateways, accounting platforms, CRM systems, access control hardware, or automated notifications. The connection may technically exist, but the required data fields are missing or the action cannot be triggered programmatically.

The limitations typically surface in four ways:

* Required data cannot be retrieved — member usage history, invoice details, or credit balances are locked inside the platform with no export path.
* Required actions cannot be triggered — check-ins, booking confirmations, or membership changes must be handled manually inside the dashboard rather than through automated rules.
* Employees rely on CSV imports and exports to move data between systems, turning a five-minute sync into a recurring manual task with real error risk.
* The platform supports only selected vendors, forcing you to replace tools that work well for your business simply because they fall outside an approved partner list.

Closed or limited APIs do not just slow down individual tasks — they constrain how your entire operation scales. Every manual workaround adds operational overhead that compounds as member count grows. When you find your team bridging systems with spreadsheets rather than automated data flows, the integration layer has become a ceiling.

That overhead tends to show up most clearly in reporting.

## Sign 6: Reports do not answer management questions

When your coworking management software generates charts but cannot answer the questions management actually asks, you have a reporting problem — not a data problem.

Most platforms surface totals. What operators need is context. The gap between exporting a spreadsheet and receiving actionable operational intelligence is where coworking businesses quietly lose control.

In practice, the questions management asks are specific:

* Utilization by location and resource type — which desks, offices, and meeting rooms are actually performing, and where capacity is being wasted
* Revenue by location, plan, and service — not a single blended number, but a breakdown that reveals which membership tiers and add-ons drive margin
* Outstanding payments — aged by member, plan, and location, not buried inside an export file
* Booking cancellations and no-shows — patterns that signal friction in your member experience
* Usage of included credits — whether members are consuming what they pay for, or leaving value on the table
* Performance of different membership plans — renewal rates, upgrade paths, and revenue contribution over time

A common pattern is that operators build secondary spreadsheets to answer these questions manually. That workaround has a real cost — and that cost compounds as your operation grows.

## Sign 7: Licensing, add-ons, and workarounds keep getting more expensive

The true cost of coworking management software is rarely what appears on the invoice. What looks like a manageable monthly subscription often expands into a layered expense structure that quietly erodes margin.

The real price of your platform is the sum of every cost it generates — not just the line item on your credit card statement.

Start with the base subscription, then add any per-member or per-location charges, paid modules, integrations, support services, and migration costs. None of these expenses is automatically unreasonable, but together they can make the total cost substantially different from the advertised entry price.

Employee time is the cost that rarely appears on any software audit. When staff spend hours reconciling booking data, manually issuing invoices, or cross-referencing spreadsheets to answer a member query, that labor has a dollar value. Multiply even a few hours per week by an annual salary, and the number becomes difficult to ignore.

Errors and delayed processes carry their own price: a missed renewal, an incorrect charge, or a misconfigured access credential can damage member trust in ways that take longer to repair than any software migration.

And perhaps the most underestimated cost is what the platform prevents you from doing. If a required workflow — tiered pricing, multi-location membership, or a new revenue stream — cannot be implemented without a custom workaround, the platform is not just costing money. It is <a href="https://www.linkedin.com/pulse/10-signs-youve-outgrown-your-software-off-the-shelf-lbb5f" rel="nofollow">limiting growth</a>.

That distinction matters when weighing whether to stay, switch, or build.

## Off-the-shelf vs custom coworking software: how to decide

Choosing between your current platform, a competing SaaS product, and custom development is ultimately a question of where the friction actually originates.

The right tool is the one that matches your operational complexity — not the most sophisticated option available.

Keep your current SaaS when configuration, not capability, is the limiting factor. Many platforms have features that operators never fully activate. Before assuming the software has failed, audit what you have. A pricing rule buried in settings may already solve the problem a spreadsheet is currently handling.

Migrate to another ready-made platform when the required workflow exists in the market but not in your current tool. A different SaaS product may already support multi-location dashboards, dynamic pricing, or the access control integrations your space needs. Migration carries disruption costs, but tends to work better than building something that competing platforms already offer.

Consider custom development when your business operates under genuinely proprietary rules — complex membership tiers, franchise-level integrations, branded customer experiences, or multi-location requirements that no standard product supports. However, custom is rarely the fastest path forward.

The disadvantages are real. Custom systems require a significant initial investment, ongoing maintenance, infrastructure ownership, security responsibility, and continued product development as your needs evolve. There is <a href="https://www.linkedin.com/pulse/5-signs-your-business-has-outgrown-its-current-xbucc" rel="nofollow">no universal cost claim that applies</a>; total cost of ownership must be evaluated against your specific revenue, complexity, and growth trajectory before any decision is made.

## WAPP coworking case study and decision checklist

Every coworking operator eventually reaches a decision point: configure what you have, replace it with an alternative platform, or build something purpose-fit. The right choice depends on whether your current system supports your operation or hinders it.

The WAPP Fiftyfour project shows a purpose-built solution in practice. It includes resident and administrator portals, workspace and meeting-room booking with an interactive map, online payments, and connected membership and resource management — all within a single system. Bringing these workflows into one system can reduce the number of gaps where manual work tends to accumulate.

Read how WAPP approached these workflows in the [Fiftyfour coworking platform case study](/en/project/fiftyfour).

If your current platform requires constant workarounds, describe how your booking, billing, membership, and access processes work today. WAPP can prepare a preliminary feature map and help determine whether configuration, migration, or custom development is the more reasonable option.

Before committing to any path, work through these questions honestly:

* Pricing and booking rules: does the platform handle your actual membership tiers, day passes, and room rates — or do you bend your pricing to fit the software?
* Spreadsheet dependency: are critical processes still running outside the system?
* Connected workflows: are payments, memberships, bookings, and access control linked, or siloed?
* Multi-location management: can every site be administered from one interface?
* Integration feasibility: are the third-party connections you need technically supported?
* Reporting quality: does the data you pull actually inform decisions?
* True total cost: add subscriptions, add-on modules, manual labor, and workaround time together.
* Maintenance ownership: if you build custom, who supports it after launch?

If these questions reveal significant gaps, it is time to change the system rather than add another workaround.

More on booking, billing, memberships, and access control is available on the [WAPP coworking solutions](/en/solutions/coworking) page.

---

## Blog: Зачем лабораториям кастомные решения и как мы их создаем

- **Slug:** `custom-software-for-labs-spektrokhim`
- **Locale:** `ru`

## Введение

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

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

## Как в «СпектроХиме» работали раньше

Компания «СпектроХим» находится в Санкт-Петербурге. Она производит прекурсоры (вещества, необходимые для некоторых химических реакций) и стандартные образцы с заранее известными характеристиками. Также компания проводит межлабораторные сличительные испытания, в ходе которых множество лабораторий оценивают одни и те же образцы.

До 2022 года сотрудники «СпектроХима» пользовались известной немецкой платформой для анализа данных и отчетности. Она была старой, сложной и дорогой. В новых экономических условиях работать с этим продуктом стало трудно. Через знакомого дизайнера специалисты «СпектроХима» обратились к нам, чтобы заказать более современный и удобный аналог.

Раньше сотрудники выполняли задачи вручную. Например, «СпектроХим» отправляла в десятки лабораторий образцы вещества для анализа. Каждую лабораторию регистрировали в исследовании, посылали ей данные по электронной почте. Потом собирали полученную информацию и составляли отчеты. Без автоматизации на это уходили недели.

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

## Как мы взялись за нестандартный заказ

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

Мы сразу уловили суть задачи с технической стороны. Дизайнер, который свел нас со «СпектроХимом», нарисовал интерфейс для кастомного решения. Он же общался с клиентом, чтобы составить ТЗ. Мы в качестве основы взяли шаблонизатор админпанелей и стали «докручивать» его под запросы заказчика.

Говорить с учеными на одном языке было непросто. Лаборантка «СпектроХима» помогала нам «переводить» профессиональные термины на понятный язык, поэтому мы справились.

## Что у нас получилось

Мы первыми в стране создали сложную платформу для сличения данных. Ее можно сравнить с продвинутой версией Excel, разработанной специально под нужды лаборатории. Она быстро и точно обрабатывает данные, показывает пользователям понятные и подробные отчеты. На российском рынке есть решения, на первый взгляд похожие на наше. Но их функционал намного скромнее.

Вот что мы предусмотрели в нашем кастомном продукте:

- На сайте размещена форма, через которую лаборатории подают заявки для участия в раундах исследований.
- После того как представители лаборатории пройдут интервью с администратором, система автоматически создает личный кабинет для лаборатории.
- Администратор вносит и редактирует данные по испытаниям и их объектам.
- Лаборатории вводят результаты испытаний, администратор проверяет и подтверждает их.
- Система сводит всю информацию в единый отчет, который можно экспортировать в Excel.
- После закрытия раунда исследований никто больше не может изменять данные по нему — это государственное требование.

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

## Польза от нашей кастомной платформы

По отзывам «СпектроХима», наш продукт позволяет компании:

Мы автоматизировали процесс подачи и обработки заявок, поэтому время их обработки сократилось. Лаборанты теперь вводят и подтверждают данные через единую систему, поэтому совершают меньше ошибок. Администраторы получили удобные инструменты для управления раундами и данными. Лаборатории отметили, что теперь удобнее пользоваться личными кабинетами, и оценили быстроту доступа к результатам.

## Что мы можем предложить другим клиентам

У нас наработана база, которую мы можем использовать для кастомных продуктов из разных сфер. К ней остается добавить модули, соответствующие логике бизнеса. Технологии мы выбираем по трем критериям: нередкие, несложные и недорогие для клиента.

В некоторых сферах есть проблема обмена данных. Надо придерживаться стандартов и протоколов, многие из которых устарели. Разные учреждения могут использовать разные платформы, плохо совместимые между собой. Кастомные решения — один из лучших способов решить эту проблему.

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

## Зачем компаниям нужны кастомные решения

Кастомные решения — это актив бизнеса. Сначала компания в него вкладывается, потом начинает на нем зарабатывать. Например, такими способами можно:

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

Организации иногда не знают, как подступиться к заказу кастомных решений и написать к ним ТЗ. Выход очень прост — обращайтесь к нам! Мы пообщаемся с вами и выясним, что вам нужно. Бесплатно подберем пять отраслевых решений для вашего бизнеса, сравним их с кастомной разработкой, дадим рекомендации. Узнаем, какие ваши бизнес-потребности не закрыты, что можно упростить, ускорить и улучшить. Составим подробное и понятное ТЗ. С самого начала четко обозначим сроки. К какой бы сфере ни принадлежал ваш бизнес, мы обязательно найдем способ повысить эффективность вашей работы.

---

## Blog: Why labs need custom software — and how we build it

- **Slug:** `custom-software-for-labs-spektrokhim`
- **Locale:** `en`

## Introduction

Labs can run on off-the-shelf products most companies buy. A custom system can still be the better business move: more orders in less time, fewer manual handoffs, and a real shot at leading a narrow niche.

We built a custom operations platform for Spektrokhim even though we initially knew little about their domain. Here is how we found a shared language with the client — and what we offer teams that have outgrown boxed tools.

## How Spektrokhim worked before

Spektrokhim is based in Saint Petersburg. They manufacture precursors (substances used in certain chemical reactions) and certified reference materials with known properties. They also run interlaboratory comparisons / proficiency tests: many labs evaluate the same samples under controlled rounds.

Until 2022, Spektrokhim relied on a well-known German platform for analytics and reporting. It was old, complex, and expensive. Under new economic conditions keeping it became hard. Through a designer contact, Spektrokhim asked us for a more modern, usable replacement.

Much of the work was still manual. Spektrokhim shipped samples to dozens of labs. Each lab was registered for a study; data moved by email. Then the team collated everything and wrote reports. Without automation that took weeks.

Our job was to streamline those processes and deliver a product teams could rely on — without depending on an external vendor’s roadmap or pricing.

## Taking on an unconventional brief

Not every vendor likes deep domain complexity. For us it is the interesting work: we unpack what looks opaque and ship what others hesitate to touch.

We grasped the technical shape of the problem quickly. The designer who introduced us had already sketched the UI and gathered requirements with the client. We started from an admin templating stack and extended it to match Spektrokhim’s needs.

Speaking the same language as scientists was not trivial. A Spektrokhim lab specialist helped translate jargon into plain terms — that made delivery possible.

## What we shipped

We built a data-reconciliation platform tailored to proficiency-testing rounds: think of an advanced spreadsheet rewritten for lab workflows — fast processing and clear, detailed reports. Similar-looking products exist on the local market; their scope is usually narrower.

Here is what the custom product covers:

- A public form where labs apply to join new study rounds.
- After an interview with an administrator, the system provisions a dedicated lab portal automatically.
- Administrators create and edit study data and test objects.
- Labs enter test results; administrators review and approve them.
- The system rolls everything into a single report exportable to Excel.
- Once a round closes, nobody can change its data — a regulatory requirement for the program.

We aimed to save time for everyone involved. Over time, lab staff can add new methods without calling us. A lead scientist can manage access levels for colleagues. Participants get only the notifications they need. New-round alerts go out automatically to everyone enrolled.

## What Spektrokhim gains from the platform

According to Spektrokhim, the product helps the company:

Automating applications and processing cut turnaround time. Staff enter and confirm data in one system, which reduces mistakes. Administrators gained practical tools to manage rounds and master data. Labs report that portals are easier to use and results are quicker to access.

## What we can offer other clients

We keep a reusable foundation we can adapt for custom products in other industries — then add modules that match the business logic. We pick technologies that are common, maintainable, and cost-effective for the client.

Many sectors struggle with data exchange: legacy standards, incompatible platforms across institutions. Custom software is often the cleanest fix.

Some industries have no real boxed options, yet they still need bespoke engineering. We work with narrow niches — laboratories, logistics, coworking, and education among them.

More on lab systems — on the [chemical labs solutions](/en/solutions/chem-lab) page and [LIMS](/en/solutions/chem-lab/lims). The Spektrokhim case is also in the [project portfolio](/en/project/spektrokhim).

## Why companies invest in custom solutions

Custom software is a business asset: you invest first, then earn returns. For example, you can:

- monetise data you already collect;
- hire for clearer roles, spend less time recruiting specialists, and reduce payroll pressure;
- take on more orders;
- run more studies with less time and fewer resources;
- avoid expensive third-party subscriptions typical of boxed suites.

Teams often do not know how to start a custom project or write a solid specification. The shortcut is to talk to us. We clarify what you need, shortlist industry-relevant options, compare them with bespoke development, and give frank recommendations. We surface unmet needs, simplification wins, and delivery risks — then produce a clear specification and timeline. Whatever sector you are in, we can usually find a path to higher operational efficiency.

---

## Blog: Электронные путевые листы и ЭТрН с 1 сентября 2026: кому обязательно, а кому нет

- **Slug:** `electronic-waybills-and-etn-from-september-2026`
- **Locale:** `ru`

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

Ниже — разбор: кому действительно нужно перейти на электронный формат, кому нет, и что предпринять уже сейчас.

## Что на самом деле меняется 1 сентября 2026 года

С 1 сентября 2026 года в отрасли начинают работать два разных нововведения. Именно два, а не одно. Дата вступления в силу совпадает, но суть изменений различна.

### Два изменения, а не одно

Первое: для перевозки маркируемой алкогольной и спиртосодержащей продукции вводится требование сопровождать груз электронными перевозочными документами. Основание — постановление Правительства РФ от 28.11.2025 № 1944, пункт 4 которого вступает в силу с 1 сентября 2026 года.

Второе: Федеральный закон от 07.06.2025 № 140-ФЗ переводит оборот перевозочных и экспедиторских документов в электронный вид с направлением сведений в государственную информационную систему электронных перевозочных документов (ГИС ЭПД).

### Почему все путают

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

Транспортная накладная — другая история. Она оформляется на конкретную перевозку для заказчика, подтверждает договор и фиксирует, что именно, откуда и куда везут. Это документ, по которому работают грузоотправители, перевозчики и грузополучатели.

### Что это значит на практике

Если компания возит маркируемый слабый алкоголь — с 1 сентября 2026 года груз должны сопровождать электронные перевозочные документы. Если компания занимается обычными коммерческими перевозками — нужно разобраться с переходом на электронную транспортную накладную. А вот электронный путевой лист сам по себе для большинства перевозчиков остаётся правом, а не обязанностью: переходить на него имеет смысл добровольно — ради удобства, скорости оформления и снижения числа ошибок.

## Путевой лист и транспортная накладная — в чём разница

### Путевой лист: про машину и водителя

Путевой лист — внутренний документ. Диспетчер вносит данные о водителе, номер водительского удостоверения, показания одометра. Медработник проводит предрейсовый осмотр и ставит отметку о допуске. Механик проверяет техническое состояние автомобиля.

Кому нужен путевой лист? Любому юридическому лицу или ИП, чьи сотрудники садятся за руль служебного транспорта. Не имеет значения, перевозите вы грузы, пассажиров или отправляете курьера на легковом автомобиле. Путевой лист оформляется на каждый рейс или смену, а главная задача — подтвердить, что водитель прошёл медосмотр, машина исправна, расход топлива и пробег учтены.

### Транспортная накладная: про груз и договор

Накладная связывает трёх участников: грузоотправителя, перевозчика и грузополучателя. Она подтверждает факт перевозки и фиксирует условия: что везут, откуда, куда, на каких условиях оплаты. Накладная имеет юридическую силу для контрагентов и контролирующих органов, включая ФНС.

Электронная транспортная накладная формируется в системе грузоотправителя, подписывается сторонами и направляется в ГИС ЭПД.

### Главное отличие

Путевой лист — про выезд автомобиля. Накладная — про заказ на доставку. Первый нужен самому перевозчику для учёта работы сотрудников и транспортного средства. Вторая нужна всем сторонам сделки и государству. Если руководитель компании думает, что подключил электронный документооборот для путевых листов и на этом всё, — он ошибается. Работать с накладными через ГИС ЭПД придётся отдельно.

## Кому обязателен электронный путевой лист с 1 сентября 2026

### Кого касается требование

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

Почему именно эти напитки? Потому что маркировка привязана к системе контроля, где каждый этап движения продукции фиксируется цифровыми документами. Бумажный документ в эту цепочку не встраивается.

### Все остальные перевозчики: право, а не обязанность

Для компаний и ИП, не связанных с перевозкой маркируемой алкогольной продукции, бумажный путевой лист остаётся законным форматом. Перевозка стройматериалов, продуктов, мебели, оборудования под требования постановления № 1944 не подпадает.

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

А вот ООО с парком грузовых машин, которое развозит пиво по сетевым магазинам, — другая история. Этой компании нужно подключить оператора, оформить электронные подписи и перестроить внутренние процессы.

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

## ЭТрН: почему она касается почти всех перевозчиков

### Что такое ЭТрН

Электронная транспортная накладная — документ на конкретную перевозку. Федеральный закон от 07.06.2025 № 140-ФЗ переводит перевозочные и экспедиторские документы в электронный вид: они формируются в электронной форме и направляются в государственную информационную систему электронных перевозочных документов.

### Кого это касается на практике

Простой ориентир: если есть договор перевозки — вопрос электронной накладной вас касается. ИП на газели, который возит мебель по заказам интернет-магазина и получает оплату за доставку, работает по договору перевозки. Грузоотправитель формирует накладную, водитель подписывает свою часть, грузополучатель закрывает документ при приёмке.

А вот фермер, который на собственном грузовике везёт свой урожай без договора перевозки, в эту схему не попадает. Нет договора — нет коммерческой перевозки.

### Почему это нельзя игнорировать

Накладная — перевозочный документ, который проверяют контролирующие органы, инспектор ГИБДД на дороге, налоговая при проверке расходов.

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

## Штрафы и последствия: что грозит за несоблюдение требований

### Главный риск — не штрафы

Вот что произойдёт, если тянуть с переходом:

- **Крупные заказчики откажут в договоре.** Ритейл, производства, логистические операторы переходят на электронный документооборот. Грузоотправитель, который передаёт данные в ГИС ЭПД, не сможет работать с перевозчиком без подключения к системе.
- **Налоговая проверка выявит проблемы с подтверждением расходов.** Накладная подтверждает факт перевозки. Без корректно оформленных документов бухгалтерия не сможет обосновать затраты. Результат — доначисления, вопросы от ФНС и проблемы с отчётностью.
- **Споры с контрагентами станут неразрешимыми.** Если груз повреждён или потерян, а электронных документов нет, доказать что-либо будет сложно.

### Реальный сценарий

ИП с тремя газелями возит грузы для сети магазинов. Сеть переходит на электронный документооборот и требует от каждого перевозчика оформлять накладную в электронном виде. Перевозчик не подключился, не получил подпись, не выбрал оператора. Сеть находит другого. Никаких судов — просто потеря заказа. Крупные грузоотправители уже сейчас включают требования по электронным документам в условия тендеров и заявки на перевозку.

## Как подготовиться к переходу: пошаговый план

### Общий порядок действий

- **Проверить, попадает ли деятельность под требования.** Перевозка маркируемого алкоголя — отдельный случай с конкретным основанием. Обычные коммерческие перевозки — свой набор требований.
- **Выбрать оператора ЭДО**, подключённого к ГИС ЭПД. Не каждый оператор поддерживает путевые листы — уточняйте до подписания договора.
- **Оформить электронные подписи** для ответственных лиц: руководителя, диспетчера, медработника, водителей. Требования к типу подписи для каждой роли уточняйте у оператора — они различаются в зависимости от документа и участника.
- **Настроить интеграцию с учётной системой.** Показания одометра, расход топлива, результат предрейсового медосмотра — всё должно попадать в электронный документ. Программы учёта типа 1С требуют подключения модуля обмена.
- **Обучить сотрудников.** Водитель подписывает документ при выезде с телефона. Механик фиксирует осмотр в системе. Медработник вносит отметки в электронном виде. Обучение проводить заранее, не в последний день.
- **Провести тестовые рейсы.** Оформите несколько документов в электронном формате параллельно с бумажными. Так вы найдёте ошибки до того, как они станут проблемой.

### Для ИП с одной газелью

Если ИП возит грузы по договору — вопрос электронной накладной его касается. Что нужно: получить электронную подпись, подключить сервис оператора с мобильным приложением, начать оформлять накладные с телефона. Затраты на старте невелики. Бумажный путевой лист при этом можно оставить на бумаге, если груз не относится к маркируемой алкогольной продукции.

## Автоматизация документооборота: на что обратить внимание

### На что смотреть при выборе

Первое — проверить, поддерживает ли сервис оба формата: путевой лист и накладную. Если компания занимается перевозками и при этом возит алкоголь, нужны оба.

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

### Мобильное приложение — необходимость

Водитель подписывает документ перед выездом. Механик фиксирует осмотр. Медработник вносит сведения. Всё это происходит не в офисе, а на базе, в пять утра. Если мобильное приложение не работает без интернета или не даёт подписать документ — процесс останавливается. Перед покупкой стоит протестировать приложение в реальных условиях рабочего дня.

### Риски при выборе

Главная ошибка — подключить оператора, который не работает с ГИС ЭПД. Для ИП и малого бизнеса готовые облачные решения закрывают потребности. Компания с парком на 50+ автомобилей сталкивается с другими вопросами: собственные правила выпуска на линию, сложные схемы перевозок, интеграция с внутренними системами. Типовой сервис может не подойти — требуется доработка.

Студия WAPP разрабатывает решения для логистики, включая интеграцию электронного документооборота с внутренними системами учёта. Подробнее — на странице [решений для логистики](/ru/solutions/logistics).

## Частые вопросы перевозчиков

### Можно ли продолжать использовать бумажные путевые листы?

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

### Я ИП, перевожу стройматериалы. Мне нужен электронный путевой лист?

Стройматериалы не относятся к маркируемой алкогольной продукции, поэтому требование постановления № 1944 на вас не распространяется. А вот с электронной накладной нужно разбираться отдельно: если вы перевозите грузы по договору, вопрос перехода вас касается. Путевой лист и накладная — документы с разными правилами.

### Чем подписывать электронные документы?

Тип подписи зависит от документа и роли участника: для части документов требуется усиленная квалифицированная подпись (УКЭП), для отдельных ролей допускается усиленная неквалифицированная (УНЭП). Уточните конкретные требования у оператора ЭДО до начала работы. УКЭП оформляется в аккредитованном удостоверяющем центре, для руководителей организаций и ИП — через ФНС.

### Мои контрагенты не перешли на электронный документооборот. Что делать?

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

### Сколько стоит переход?

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

## Выводы: что сделать до 1 сентября 2026

### Для перевозчиков маркируемого алкоголя

С 1 сентября 2026 года груз должны сопровождать электронные перевозочные документы — основание установлено постановлением Правительства РФ от 28.11.2025 № 1944. Откладывать переход не стоит: настройка процессов, обучение сотрудников и тестовые рейсы требуют времени.

### Для остальных перевозчиков

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

### Что сделать прямо сейчас

Первый шаг — выбрать оператора ЭДО, подключённого к ГИС ЭПД. Второй — получить электронные подписи на ответственных сотрудников. Третий — протестировать обмен документами с контрагентами. На практике именно этот этап вскрывает проблемы: у кого-то нет подключения, у кого-то 1С не настроена на приём перевозочных документов, у кого-то приложение водителя не работает на маршруте без интернета. Лучше узнать об этом заранее.

Если нужна интеграция документооборота с собственными системами или разработка решения для управления перевозками — [обсудите задачу с командой WAPP](/ru/solutions/logistics).

## Документы, на которые стоит опираться

- **Федеральный закон от 07.06.2025 № 140-ФЗ** «О внесении изменений в Федеральный закон „О транспортно-экспедиционной деятельности“ и отдельные законодательные акты Российской Федерации» — [официальная публикация](http://publication.pravo.gov.ru/Document/View/0001202506070016), [текст на сайте Президента России](http://www.kremlin.ru/acts/bank/51991), [обзор на Гаранте](https://www.garant.ru/hotlaw/federal/1821355/)
- **Постановление Правительства РФ от 28.11.2025 № 1944** «О содержании и порядке использования электронных документов, удостоверяющих легальность производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции» — [текст на КонсультантПлюс](https://www.consultant.ru/document/cons_doc_LAW_520202/), [обзор на Гаранте](https://www.garant.ru/hotlaw/federal/1919417/). Пункт 4 вступает в силу с 1 сентября 2026 года.
- **Федеральный закон от 08.11.2007 № 259-ФЗ** «Устав автомобильного транспорта и городского наземного электрического транспорта», статья 18.1 — базовая норма об электронных перевозочных документах и ГИС ЭПД.

---

## Blog: ЭТрН и ГИС ЭПД: как перейти на электронные транспортные накладные

- **Slug:** `etrn-gis-epd`
- **Locale:** `ru`

Путаница с электронными подписями, контрагенты на разных платформах, связка с учётной системой — переход на ЭТрН вызывает больше вопросов, чем ответов. С 1 сентября 2026 года в отрасли меняется порядок работы с рядом перевозочных документов, но формулировать это как «обязательно для всех без исключений» некорректно: есть нюансы по категориям перевозок и типам груза. Бумажная транспортная накладная по согласию сторон остаётся допустимой, пока иное не следует из применимых требований. Подробнее о разграничении ЭПЛ и ЭТрН — в [отдельном материале](/ru/blog/electronic-waybills-and-etn-from-september-2026). Здесь — практика: от выбора оператора до интеграции с учётной системой.

## О чём эта статья и кому она нужна

Команда WAPP занимается разработкой цифровых решений для логистики и грузоперевозок, и вопросы электронного документооборота — часть ежедневной работы. Эта статья написана на основе практического опыта интеграции ЭТрН с учётными системами компаний, которые перевозят грузы по России. Подробнее о направлении — на [странице логистических решений WAPP](/ru/solutions/logistics).

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

Один важный момент. Электронная транспортная накладная (ЭТрН) и электронный путевой лист — разные документы, с разными участниками перевозки и разной нормативной базой. Если нужно разобраться, чем они отличаются и кого что касается, есть [отдельный разбор](/ru/blog/electronic-waybills-and-etn-from-september-2026). Здесь эту тему затрагивать не будем.

### Кому пригодится этот материал

Статья рассчитана на тех, кто работает с перевозочными документами или принимает решения об их переводе в электронный формат. Руководители транспортных компаний найдут здесь информацию о расходах, сроках и рисках. Логисты и диспетчеры — пошаговый алгоритм: от заявки оператору до подписания накладной водителем через мобильное приложение. ИП-перевозчики поймут, с чего начать, если бизнес небольшой, а контрагенты уже просят обмен в электронном виде.

### Что с нормативной базой

Нормативная база для электронных транспортных накладных опирается в том числе на ФЗ № 140-ФЗ от 07.06.2025 и связанные нормы о ГИС ЭПД. Они определяют правовой статус ЭТрН, порядок передачи данных и роль грузоотправителя, перевозчика и грузополучателя. Дата 1 сентября 2026 года важна как ориентир для планирования, но обязательность зависит от категории перевозки и типа груза — это разбирается в [статье о различиях ЭПЛ и ЭТрН](/ru/blog/electronic-waybills-and-etn-from-september-2026).

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

## Как устроена ГИС ЭПД и кто в ней участвует

Чтобы разобраться с переходом на электронные транспортные накладные, сначала нужно понять, куда попадают данные и кто за что отвечает. Компании часто путают ГИС ЭПД с сервисом оператора ЭДО, думают, что придётся ставить новую программу или заходить на государственный сайт. На практике всё устроено проще.

### Что такое ГИС ЭПД и зачем она нужна

ГИС ЭПД — государственная информационная система электронных перевозочных документов. Её оператор — Минтранс России. По сути, это центральная база, куда стекаются сведения об электронных транспортных накладных. Важно: напрямую в ГИС ЭПД никто не работает. Грузоотправитель не заходит туда, чтобы оформить ЭТрН. Перевозчик не открывает её, чтобы подписать документ. Грузополучатель не ищет там накладную для приёмки.

ГИС ЭПД принимает данные автоматически от оператора ИС ЭПД и хранит их. Контроль со стороны государства и доступ для инспекторов при необходимости решает система сама, без ручного участия бизнеса.

### Кто участники и как между ними идёт обмен документами

Участники перевозки в электронном документообороте — те же, что и в бумажном: грузоотправитель, перевозчик, грузополучатель. Каждый подписывает свой титул электронной транспортной накладной. Водитель тоже участвует — подтверждает получение груза при погрузке и передачу при выгрузке, например через мобильное приложение оператора.

Схема потоков такая. Грузоотправитель формирует ЭТрН в сервисе оператора ЭДО — онлайн или через интеграцию с 1С / другой учётной системой — и подписывает первый титул. Перевозчик получает документ у того же или другого оператора и подписывает свой титул. Водитель подтверждает приём груза, часто с телефона. После доставки грузополучатель принимает груз и подписывает заключительный титул. На каждом этапе оператор передаёт информацию в ГИС ЭПД. Участники работают в интерфейсе оператора, а система Минтранса получает готовые подтверждённые данные автоматически.

### Почему это не «ещё одна программа»

Частое заблуждение: ГИС ЭПД воспринимают как новое приложение, которое нужно настроить. Это не так. Компании достаточно заключить договор с оператором ЭДО, оформить электронные подписи — и можно отправить первую электронную накладную. Передача в государственную систему происходит на стороне оператора. Подробнее о решениях для логистики и интеграции ЭДО с внутренними системами — на [странице логистических решений](/ru/solutions/logistics).

## Путь электронной транспортной накладной от формирования до закрытия

Каждый этап — юридически значимое действие с электронной подписью конкретного участника перевозки.

### Грузоотправитель формирует и подписывает ЭТрН

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

### Водитель принимает груз

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

### Грузополучатель закрывает накладную

Получатель принимает груз при выгрузке, проверяет комплектность и подписывает заключительный титул. ЭТрН считается закрытой. Каждый участник может получить доступ к подписанному документу через сервис оператора. После закрытия оператор ИС ЭПД автоматически передаёт сведения в ГИС ЭПД — вручную отправлять данные не нужно.

### Что делать при расхождениях

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

Подробнее о том, как настроить обработку таких ситуаций в учётной системе — в [кейсе маркетплейса перевозок](/ru/project/railmarket).

## Как выбрать оператора ЭДО для работы с ЭТрН

Оператор ЭДО — звено, через которое стороны подписывают ЭТрН и передают данные в ГИС ЭПД. Ошибка на этапе выбора приводит к тому, что документооборот буксует: водитель не может подписать накладную с телефона, контрагент на другой платформе не получает документ, учётная система требует ручного ввода.

### На что смотреть при выборе

**Роуминг с другими операторами.** Участники часто работают через разных операторов. Без роуминга обмен между ними невозможен. Уточняйте, с какими операторами настроен роуминг и сколько занимает передача.

**Мобильное приложение для водителей.** Водитель подписывает титул на погрузке или в кабине. Ключевой вопрос: как приложение ведёт себя офлайн? На трассе интернет пропадает регулярно.

**Интеграция по API с учётной системой.** Оформление ЭТрН вручную через веб-интерфейс — двойная работа. API позволяет передать данные из заявки на перевозку без копирования. Пример связки на практике — в [кейсе системы управления флотом](/ru/project/swappz).

**Техническая поддержка и SLA.** Грузоперевозки не останавливаются в выходные. Спрашивайте про время реакции и каналы для экстренных случаев.

### Вопросы оператору до подписания договора

- Поддерживаете ли вы роуминг, и с какими операторами (Контур, СБИС, Такском, другими)?
- Как водитель подписывает ЭТрН: мобильное приложение, онлайн-кабинет? Есть ли работа без интернета?
- Какой формат подписи используется для водителей? Нужна ли каждому отдельная КЭП?
- Есть ли API для интеграции с учётной системой и какая документация доступна?
- Как считается стоимость при большом объёме документов?

Конкретные тарифы здесь намеренно не приводятся: они меняются. Логику ценообразования — за документ, за пользователя, за пакет — нужно понимать до старта.

## Электронные подписи: кому какие нужны и где получать

### КЭП для руководителя и уполномоченных лиц

Грузоотправитель, перевозчик и грузополучатель подписывают ЭТрН квалифицированной электронной подписью (КЭП / УКЭП). Руководитель юрлица или ИП получает подпись в удостоверяющем центре ФНС. Уполномоченные сотрудники — в коммерческих УЦ, аккредитованных Минцифры. Список центров есть на сайте министерства.

### Как водитель подписывает ЭТрН

Водитель подтверждает приёмку и передачу груза. Выдавать каждому собственную КЭП часто дорого и неудобно — закон допускает простую или усиленную неквалифицированную подпись для сотрудников-водителей в рамках правил оператора. На практике подписание идёт через мобильное приложение. Обязательное условие: на водителя оформляют машиночитаемую доверенность (МЧД), подписанную КЭП руководителя.

### Обучение водителей

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

## Что делать, если контрагенты не готовы к электронному обмену

Электронная транспортная накладная устроена так, что каждый титул подписывает отдельный участник. Если хотя бы одно звено не подключено, цепочка ломается.

### Начинать переговоры до подключения

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

### Помочь контрагенту подключиться

Иногда проще помочь партнёру: онлайн-консультация, контакты оператора, совместный звонок с техподдержкой. Крупные заказчики уже включают требования по ЭТрН в договоры и помогают перевозчикам пройти подключение.

### Роуминг между операторами

Грузоотправитель на одном операторе, перевозчик на другом — обмен возможен через роуминг, но его нужно проверять заранее. Не все пары операторов настроили передачу.

### Смешанный режим: бумага и электроника

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

## Интеграция ЭТрН с учётной системой компании

Частая боль после подключения: «Накладные работают, но данные вбивают дважды». Диспетчер создаёт заявку в 1С или TMS, потом заполняет ту же информацию у оператора. Интеграция решает именно это.

### Три способа связать ЭТрН с учётом

Первый — готовые модули для 1С от крупных операторов. Второй — API оператора для собственной ERP. Третий — кастомная разработка, когда стандартные решения не покрывают процессы. При разработке [маркетплейса Railmarket](/ru/project/railmarket) документооборот встроили в платформу; похожий подход — в [системе управления флотом Swappz](/ru/project/swappz).

### Что должна уметь интеграция

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

Подробнее о том, как [выстроить логистические процессы](/ru/solutions/logistics) с учётом электронного документооборота, — на странице решений для логистики.

## Типичные ошибки при переходе на ЭТрН

### Не проверить готовность контрагентов до старта

Если ключевой контрагент не подключен, цепочка рвётся. За месяц до пилота разошлите партнёрам запрос о готовности и зафиксируйте ответы.

### Выбрать оператора без роуминга

Перед договором задайте прямой вопрос: с какими площадками настроен роуминг и в каких случаях передача невозможна.

### Не обучить водителей

Если человек впервые видит приложение в день запуска, на линии начинается хаос. Достаточно коротких обучений с практикой на тестовых документах.

### Не настроить интеграцию с учётной системой

ЭТрН через сайт оператора без обратной связи в 1С даёт двойной ввод. Интеграцию нужно настроить до массового запуска, а не после.

### Откладывать подготовку «на потом»

Контакты операторов, подписи и обучение занимают время. Спокойный режим подготовки выгоднее аврала в последние недели перед ключевой датой планирования.

### Не продумать, что делать при сбое

Мобильное приложение зависло, интернет на складе пропал. Нужен fallback: бумажные бланки на крайний случай, регламент для диспетчера, порядок дооформления позже. Пример устойчивых процессов — в [кейсе управления флотом](/ru/project/swappz).

### Проигнорировать актуальные обязательные поля

Перенос старых шаблонов бумажных накладных «как есть» даёт отказы при проверке. Каждый раздел ЭТрН нужно заполнять по актуальной спецификации оператора и формата.

## Частые вопросы про ЭТрН и ГИС ЭПД

### Можно ли использовать бумажные накладные параллельно с ЭТрН?

Да. Грузоотправитель и перевозчик вправе оформлять транспортную накладную в бумажном виде, если все стороны перевозки согласны с таким форматом. Электронная транспортная накладная не отменяет бумажную автоматически. Обязательность электронного формата зависит от категории перевозки и типа груза — это не единое правило «для всех с 1 сентября 2026». Подробнее о разграничении документов и сроках — в [статье о различиях ЭПЛ и ЭТрН](/ru/blog/electronic-waybills-and-etn-from-september-2026).

### Что делать, если ГИС ЭПД недоступна в момент отправки груза?

Груз не должен стоять на складе из-за технического сбоя. На практике передача в ГИС ЭПД идёт через оператора, и большинство сервисов позволяют сформировать ЭТрН в системе оператора даже при временной недоступности государственной платформы. Документ подписывают, а отправить сведения в ГИС можно позже. Разумное решение — держать бумажные бланки на крайний случай и прописать регламент при сбоях.

### Как исправить ошибку в уже подписанной ЭТрН?

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

### Нужна ли отдельная электронная подпись для каждого водителя?

Водитель подписывает свой титул лично. Для подписания через мобильное приложение нужна собственная электронная подпись в рамках правил оператора и оформленная МЧД. Без подписи водителя документ не подтверждает факт перевозки.

### Примет ли налоговая ЭТрН как подтверждение расходов на перевозку?

Да, при условии корректного оформления и подписания участниками. Электронные перевозочные документы имеют ту же юридическую силу, что и бумажные. Для учёта достаточно хранить файл ЭТрН и обеспечить возможность предъявления при проверке. Вопросы по конкретным случаям лучше решать с бухгалтером, знакомым с ЭДО, или уточнить на [сайте логистических решений WAPP](/ru/solutions/logistics).

## С чего начать переход уже на этой неделе

### Шаг первый: выяснить готовность контрагентов

Короткий запрос грузоотправителям, перевозчикам и грузополучателям: используют ли они ЭТрН, через какого оператора, готовы ли принимать электронные накладные.

### Шаг второй: выбрать оператора и запросить демо-доступ

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

### Шаг третий: оформить электронные подписи

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

### Шаг четвёртый: провести тестовый рейс

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

### Шаг пятый: запустить интеграцию с 1С или другой учётной системой

Параллельно с тестовыми перевозками — передача данных из ЭТрН в учёт, чтобы убрать двойной ввод. Если нужна помощь с интеграцией, подробнее — на [сайте WAPP](/ru/solutions/logistics).

### Сколько времени займёт переход

Компании из нескольких человек часто проходят шаги за две-три недели. Крупные перевозчики с десятками водителей — за полтора-два месяца. Главный фактор — готовность контрагентов и скорость получения подписей.

Имеет смысл начинать подготовку заранее и в спокойном режиме: сначала контрагенты и оператор, потом подписи, тестовый рейс и интеграция — а не разбирать цепочку в аврале, когда партнёры уже требуют электронный обмен.

---

## Blog: e-TN and GIS EPD: how to switch to electronic consignment notes

- **Slug:** `etrn-gis-epd`
- **Locale:** `en`

Confusion around electronic signatures, counterparties on different platforms, and links to the accounting system — moving to electronic consignment notes (e-TN / ЭТрН) raises more questions than answers. From 1 September 2026 the industry’s rules for a range of freight documents change, but calling that “mandatory for everyone with no exceptions” is incorrect: categories of carriage and cargo types matter. A paper consignment note remains acceptable when all parties agree, unless applicable requirements say otherwise. For how electronic waybills (EPL) differ from e-TN, see the [separate article](/en/blog/electronic-waybills-and-etn-from-september-2026). Here — practice: from choosing an operator to integrating with your ERP.

## What this article is for

WAPP builds digital logistics products, and electronic document exchange is part of daily work. This piece draws on integrating e-TN with company accounting systems for freight across Russia. More on the practice area — on the [WAPP logistics solutions page](/en/solutions/logistics).

No ten-page statute reprint. Focus: how to connect to GIS EPD, pick an operator, get signatures for staff, issue the first electronic consignment note, and avoid common stalls — through to the consignee confirming receipt and the document entering the information system.

Important: the electronic consignment note (e-TN) and the electronic waybill are different documents, with different parties and different legal bases. Differences and who is affected are covered in the [separate breakdown](/en/blog/electronic-waybills-and-etn-from-september-2026).

### Who will find this useful

Transport company leaders — costs, timelines, risks. Dispatchers — a step-by-step path from operator application to driver signing in a mobile app. Sole-proprietor carriers — where to start when the business is small but partners already ask for electronic exchange.

### On the regulatory baseline

The e-TN framework rests in part on Federal Law No. 140-FZ of 07.06.2025 and related GIS EPD rules. They define legal status, data transfer, and the roles of shipper, carrier, and consignee. 1 September 2026 is a planning milestone; mandatory scope depends on carriage category and cargo type — covered in the [EPL vs e-TN article](/en/blog/electronic-waybills-and-etn-from-september-2026).

Many companies have not connected yet because the starting point is unclear, not because they do not need it. Paper notes are familiar; the switch looks heavy. In practice e-TN can be connected in a couple of weeks if the sequence is clear.

## How GIS EPD works and who takes part

Companies often confuse GIS EPD with an EDI operator portal and expect a new government app. In practice it is simpler.

### What GIS EPD is

GIS EPD is the state information system for electronic freight documents, operated by Russia’s Ministry of Transport. It is a central store for electronic consignment note data. Nobody works in GIS EPD directly: shippers, carriers, and consignees do not log in to create or sign notes.

GIS EPD receives data automatically from an IS EPD operator and stores it. Oversight and inspector access are handled by the system without manual business workflow inside the state portal.

### Participants and document flows

The parties are the same as on paper: shipper, carrier, consignee. Each signs their title of the electronic note. The driver also takes part — confirming pickup and delivery, often via the operator’s mobile app.

Flow: the shipper creates the e-TN in the EDI operator service — online or via 1C / another ERP — and signs the first title. The carrier receives it via the same or another operator and signs their title. The driver confirms pickup, often from a phone. After delivery the consignee signs the closing title. At each step the operator forwards data to GIS EPD.

### Why this is not “another app to install”

A contract with an EDI operator and electronic signatures are enough to send the first note. Transfer into the state system happens on the operator side. More on logistics solutions and EDI integration — on the [logistics solutions page](/en/solutions/logistics).

## Path of an electronic consignment note from creation to close

Each stage is a legally significant act with an electronic signature.

### Shipper creates and signs

The shipper fills the first title: cargo, load/unload addresses, party contacts, vehicle details, carriage terms — the same information as on paper, in digital form — then signs with a qualified electronic signature. From that moment the note is legally effective and flows to other parties via the operator.

### Driver accepts the cargo

At loading the driver (or carrier representative) checks condition and signs their title — typically in the mobile app. Signing confirms acceptance for carriage. Damage noted before signing becomes part of the note.

### Consignee closes the note

At unloading the consignee checks completeness and signs the closing title. The e-TN is closed; parties can retrieve the signed file via the operator. The IS EPD operator then sends data to GIS EPD automatically.

### Handling discrepancies

If shortage or damage is found, the consignee does not sign “as is” — they record actual quantities and discrepancies visible to all parties. Separate paper discrepancy acts are usually unnecessary.

For accounting-system handling of such cases, see the [Railmarket freight marketplace case](/en/project/railmarket).

## Choosing an EDI operator for e-TN

The operator is the link through which parties sign and data reach GIS EPD. A bad choice stalls the flow: drivers cannot sign on the phone, counterparties on another platform never receive the file, ERP still needs re-keying.

### What to check

**Roaming with other operators.** Parties often use different operators; without roaming exchange fails.

**Driver mobile app.** Signing happens at the dock or in the cab. Ask about offline behaviour.

**API to your ERP.** Manual web entry is double work. API sends trip-request data without copy-paste. See the [fleet management case](/en/project/swappz).

**Support and SLA.** Freight does not stop on weekends — ask about response times and emergency channels.

### Questions before the contract

- Which operators do you roam with?
- How does the driver sign, and does offline work?
- What signature type do drivers use?
- Is there an API and documentation?
- How is pricing structured at volume?

Specific tariffs are omitted on purpose — they change. Understand per-document / per-user / package logic before go-live.

## Electronic signatures: who needs what

### QES for executives and authorised staff

Shipper, carrier, and consignee sign with a qualified electronic signature (QES / UKFP). Company heads and sole proprietors obtain it via the Federal Tax Service CA; authorised employees via commercial CAs accredited by the Ministry of Digital Development.

### How drivers sign

Drivers confirm pickup and delivery. Issuing a full QES to every driver is often expensive — simple or enhanced unqualified signatures may be allowed under operator rules. In practice signing goes through the mobile app. Required: a machine-readable power of attorney (MRPA / MChD) signed by the head’s QES.

### Driver training

Without a short hands-on briefing, wrong titles and missed confirmations stall the chain. A half-hour walkthrough and a one-page cheat sheet clear most questions before line launch.

## When counterparties are not ready

Every title needs its party. If one link is offline, the chain breaks.

### Talk before you connect

Ask key partners early: do they use electronic freight docs, which operator, do drivers have the app.

### Help a partner connect

Sometimes a joint call with support costs less than waiting. Large shippers already put e-TN requirements into contracts and help carriers onboard.

### Operator roaming

Shipper on one platform, carrier on another — possible via roaming, but verify the pair in advance.

### Mixed paper and electronic mode

During transition, some trips will use e-TN and some paper by mutual consent. Your ERP must handle both streams. Practical tactic: rank partners by readiness and start where the full chain is already live.

## Integrating e-TN with your accounting system

Common pain: “Notes work, but we enter data twice.” Integration fixes that.

### Three ways to connect

Ready 1C modules from major operators; operator API for a custom ERP; custom build when standard tools do not fit — as in [Railmarket](/en/project/railmarket) and [Swappz](/en/project/swappz).

### What integration must do

Minimum: create e-TN from a trip request automatically, and push closed files back to accounting. If closed files never return to ERP, finance hunts them on the operator site — paper problems in digital form.

More on building logistics processes with electronic document exchange — on the [logistics solutions page](/en/solutions/logistics).

## Typical mistakes when switching to e-TN

### Not checking counterparties first

If a key partner is not connected, the chain breaks. Send a readiness survey before the pilot.

### Picking an operator without roaming

Ask which platforms they roam with and when transfer fails.

### Skipping driver training

First day on the live app without practice creates line chaos. Short training on test documents is enough.

### No ERP integration

Operator-only web entry means double typing. Integrate before mass launch.

### Leaving prep “for later”

Operators, signatures, and training take calendar time. Calm prep beats last-week rush before a planning milestone.

### No fallback for outages

App freeze or no warehouse internet — keep emergency paper blanks, a dispatcher playbook, and a way to complete the electronic file later. See the [fleet management case](/en/project/swappz).

### Ignoring current required fields

Copying old paper templates “as is” causes validation rejects. Fill each section to the current operator/format specification.

## Frequently asked questions about e-TN and GIS EPD

### Can paper notes run in parallel with e-TN?

Yes. Shipper and carrier may use a paper consignment note when all parties agree. An electronic note does not automatically cancel paper. Whether the electronic form is mandatory depends on carriage category and cargo type — it is not a single “for everyone from 1 September 2026” rule. Details — in the [EPL vs e-TN article](/en/blog/electronic-waybills-and-etn-from-september-2026).

### What if GIS EPD is down when the truck must leave?

Freight should not wait on a state-platform outage. Operators usually let you form and sign the e-TN in their system and forward to GIS EPD later. Keep emergency paper blanks and a written outage procedure.

### How do you fix an already signed e-TN?

You cannot simply edit a field — that breaks signature integrity. If the consignee has not signed, annul and issue a new note. If closed — issue a correction note. Confirm the exact procedure with your EDI operator and current Ministry of Transport guidance.

### Does every driver need a separate electronic signature?

Drivers sign their title personally. Mobile signing needs a driver signature under operator rules plus an MRPA. Without the driver’s signature the note does not evidence carriage.

### Will tax authorities accept e-TN as proof of carriage costs?

Yes when correctly issued and signed by the parties. Electronic freight documents have the same legal force as paper. Store the e-TN file and be able to present it on audit. Case-specific questions — with an EDI-aware accountant, or via the [WAPP logistics solutions page](/en/solutions/logistics).

## What to start this week

### Step 1: check counterparties

Short ask: do they use e-TN, which operator, will they accept electronic notes.

### Step 2: pick an operator and request a demo

Prefer the platform your key partners already use. Check the driver app, roaming, and integration terms.

### Step 3: issue electronic signatures

For company signatories and drivers under the chosen scheme. Do not postpone — this step most often delays the whole project.

### Step 4: run a pilot trip

One ready partner, one real carriage. Pilot mistakes show where to tune processes and training.

### Step 5: connect 1C or another ERP

In parallel with pilots — push e-TN data into accounting to remove double entry. Help with integration — on the [WAPP site](/en/solutions/logistics).

### How long the switch takes

Small teams often finish in two to three weeks; larger fleets in one and a half to two months. The main factor is partner readiness and signature issuance speed.

Start prep early and calmly: counterparties and operator first, then signatures, pilot, and integration — not in a rush when partners already require electronic exchange.

---

## Blog: Интеграция оплаты на сайт и в приложение: ЮKassa, чеки по 54-ФЗ, ОФД

- **Slug:** `integraciya-oplaty-na-sajt`
- **Locale:** `ru`

Мы в WAPP восемь лет делаем веб-сервисы и мобильные приложения, и почти в каждом проекте есть оплата. Интеграций платёжных систем за это время было больше двадцати. Вывод из них простой: подключить оплату — это дни, а вот сделать так, чтобы платёж, заказ, чек и доставка не расходились между собой, — недели. Ниже то, на чём мы сами спотыкались, и что советуем клиентам до старта.

## С чего мы начинали: 54-ФЗ и онлайн-кассы

Когда мы открыли студию, требования 54-ФЗ к онлайн-кассам уже действовали: каждый, кто принимает оплату через интернет, обязан выдавать покупателю электронный чек. Первые интеграции мы делали на LIFE PAY — я до WAPP работал в этой компании и хорошо знал их кассу изнутри. С тех пор фискализация чеков для нас — не отдельная задача, а обязательная часть любой интеграции оплаты.

Цепочка выглядит так: клиент платит → система меняет статус заказа → формируется чек по 54-ФЗ → данные уходят в ОФД → покупатель получает электронный чек. Сам платёж почти никогда не ломается. Ломается всё, что после него.

По закону расчёт без чека грозит штрафом до 100% от суммы расчёта (КоАП 14.5 ч. 2), а ошибки в реквизитах чека — предупреждением или штрафом до 10 000 ₽ для юрлица (ч. 4). Ошибки в чеках обычно не видны сразу: они копятся месяцами и всплывают при проверке.

## Если продаж мало: не делайте интеграцию

Владельцу небольшого бизнеса, который хочет «просто кнопку оплаты за три дня», я обычно советую вообще не интегрировать оплату в сайт. Достаточно формы заявки и ссылки на оплату. Интернет-эквайринг банка (например, Т-Банка) или ЮKassa позволяют сгенерировать ссылку и отправить её клиенту. Подключение согласуют быстро, а у ЮKassa есть свои электронные чеки: она фискализирует платёж как агент, и отдельная касса не нужна.

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

## Как выбрать провайдера: агрегатор или эквайринг банка

Мой совет — начинать с того, что дешевле. Чаще всего это прямой интернет-эквайринг банка с хорошим API и понятной документацией. Агрегаторы вроде ЮKassa и CloudPayments дороже по комиссии, но подключаются быстро и сразу дают карты, СБП, кошельки, Яндекс Пэй и оплату частями.

По нашему опыту внедрения:

- **ЮKassa** — внедряется легко, есть встроенная фискализация.
- **Т-Банк** — тоже легко, быстро согласовывают подключение.
- **CloudPayments** — удобно внедрять.
- **LIFE PAY** — интегрируется просто, но комиссия высокая.
- **Сбер** — с документацией сложнее всего. В одном проекте мы начали интеграцию со Сбером и в итоге перешли на ЮKassa.

Актуальные тарифы проверяйте на сайтах провайдеров: они зависят от оборота и способа оплаты, по СБП комиссия обычно ниже, чем по картам.

**Главное правило: два независимых эквайринга.** Если у вас больше пяти продаж в день, подключайте две платёжные системы, которые не зависят друг от друга. Мы поняли это на [Xstreet](/ru/project/xstreet). По выбору клиента там стоял эквайринг Райффайзенбанка, и в какой-то момент он начал падать. Пришлось срочно подключать второй, резервный — эквайринг Тинькофф (сейчас Т-Банк). Пока работает только один провайдер, его сбой — это остановка продаж.

## Способы подключения: ссылка, виджет, API, SDK

**Ссылка или платёжная страница.** Клиент переходит к провайдеру, платит и возвращается. Подходит для старта и небольших объёмов.

**Встраиваемый виджет.** Оплата не уводит с сайта, но виджет — ещё одно звено, которое может сломаться. В сети коворкингов, с которой мы работаем, кнопка «Оплатить онлайн» на сайте в какой-то момент перестала открывать окно ЮKassa: клиент выбирал переговорную, нажимал оплату — и ничего не происходило. Чеки при этом формировались корректно, проблема была в связке виджета с платёжным шлюзом. Заодно мы убрали из клиентского интерфейса оплату по счёту и оставили только карту, а у администраторов этот способ остался. Способы оплаты должны настраиваться по ролям.

**Интеграция через API.** Своя платёжная форма, полный контроль над статусами, возвратами и чеками из кода. Нужна, когда оплату надо связывать с личными кабинетами, 1С и доставкой.

**SDK для мобильных приложений.** Оплата в мобильном приложении идёт через платёжный SDK провайдера для iOS и Android. Помните про правила сторов: за цифровые товары и услуги Apple и Google берут комиссию до 30% и требуют свою систему оплаты. Физические товары и офлайн-услуги можно проводить через сторонний SDK. Подробнее о выборе стека для платёжных сценариев — в статье [React Native или натив](/ru/blog/krossplatformennaya-razrabotka).

## Фискализация чеков: 54-ФЗ и ОФД

Есть два сценария. Если вы используете электронные чеки ЮKassa, провайдер сам формирует чек и передаёт его в ОФД, а договор с оператором фискальных данных вам не нужен. Если работаете со своей облачной кассой, договор с ОФД заключаете сами, а чек формирует касса по данным из вашей системы.

Частая ошибка — ставка НДС в чеке не совпадает с налоговым режимом. С 2025 года ИП и компании на упрощённой системе налогообложения с доходом свыше 60 млн ₽ в год платят НДС (5%, 7% или 20%), ниже порога ставка — «без НДС». Проверьте ставку в настройках кассы до запуска.

При предоплате формируется чек с признаком предоплаты, при передаче товара — второй чек с полным расчётом. Возврат тоже оформляется отдельным чеком. Тестовый режим провайдера не отправляет данные в реальный ОФД, поэтому после запуска сделайте пару реальных покупок на минимальную сумму и проверьте, что чек дошёл покупателю.

## Подписки, тарифы и оплата частями

В [Future Volleyball School](/ru/project/future-volleyball-school) ученики покупают тарифы на период. Оплата идёт через ЮKassa, она же фискализирует платежи, а все оплаченные периоды видны администратору в админке. В [Glinka Digital](/ru/project/glinka-digital) оплачиваются и отдельные уроки по модели pay-as-you-go, и подписка, тоже через ЮKassa. Для рекуррентных платежей помните: чек формируется при каждом списании.

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

Оплату частями через «Долями» мы подключали в Xstreet. Клиент хотел дать покупателям рассрочку на дорогие кроссовки, но сервисы рассрочки раз за разом отказывали ему в подключении, пока с «Долями» наконец не удалось договориться. Закладывайте время на согласование с провайдером: техническая часть здесь не самая долгая.

## Связка оплаты с доставкой и статусами заказа

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

С доставкой было ещё веселее. Сначала работали со СДЭК, а когда СДЭК взломали и сервис лёг, пришлось в срочном порядке подключать Яндекс Доставку. С ней мы получили новую проблему: посылка регистрировалась в системе Яндекса, курьер приезжал на отправку, а ему говорили, что в их системе такого заказа нет. Вывод: статусы заказа у вас, у платёжки и у службы доставки — три разные модели, и их согласование — отдельная работа, а не «подключение API».

Ещё одно слабое место — уведомление о платеже (вебхук). Если бэкенд ответил провайдеру «200 OK» до того, как обработал платёж, а потом упал, платёж может потеряться: провайдер повторяет уведомление, только если не получил успешный ответ. Отвечайте только после записи в базу и проверяйте идентификатор платежа, чтобы повторное уведомление не создало дубль заказа.

## Типичные проблемы, которые мы видели

**Человеческий фактор.** Самая частая причина сбоев — не код. Менеджеры выставляют счета вне системы, и такие оплаты не подтягиваются, статус не обновляется, фискализация не запускается. Когда сотрудники придумывают свои процессы поверх системы вместо того, чтобы ей пользоваться, выходит плохо. Обучение команды — часть интеграции. Об этом подробнее — в статье про [автоматизацию бизнес-процессов](/ru/blog/avtomatizaciya-biznes-processov).

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

**Чек и учёт — разные звенья.** В том же проекте фискализация работала без ошибок, но заказ уходил в 1С только после оплаты, а при создании иностранной организации интеграция с 1С плодила дубли клиентов. Связку с 1С тестируйте отдельно от кассы.

**Сбой на стороне провайдера.** Однажды ошибка оплаты оказалась сбоем в API ЮKassa, а не в нашем коде. Логи запросов к платёжке экономят часы поиска виноватого.

## С чем мы работали

ЮKassa — [Future Volleyball School](/ru/project/future-volleyball-school), [Glinka Digital](/ru/project/glinka-digital), [сеть коворкингов](/ru/project/coworking-spb). Эквайринг Райффайзенбанка и Тинькофф, «Долями», касса LIFE PAY, СДЭК и Яндекс Доставка — [Xstreet](/ru/project/xstreet). Эквайринг Сбербанка в Казахстане — [Fiftyfour](/ru/project/fiftyfour): клиент сам выбрал Сбер. Платёжный SDK для iOS — [Beeline Kazakhstan](/ru/project/beeline-kazakhstan).

## Чек-лист перед запуском

- Решите, нужна ли интеграция или хватит ссылки на оплату
- Если продаж больше пяти в день — подключите два независимых эквайринга
- Выберите сценарий фискализации: чеки провайдера или своя касса с договором ОФД
- Проверьте ставку НДС под ваш налоговый режим
- Настройте вебхуки: ответ только после записи в базу, проверка идентификатора платежа
- Разведите правила автоотмены для заказов клиента и администратора
- Проверьте связку с 1С и службой доставки отдельно от оплаты
- Проведите реальные покупки на минимальную сумму всеми способами оплаты и проверьте чеки
- Объясните менеджерам, почему счета нельзя выставлять мимо системы

## Частые вопросы

### Нужна ли своя онлайн-касса, если подключить ЮKassa?

Не обязательно. ЮKassa может сама формировать электронные чеки и передавать их в ОФД как агент — тогда отдельная касса и договор с ОФД не нужны. Своя облачная касса нужна, если вы хотите полностью управлять чеками из своей системы.

### Сколько времени занимает интеграция оплаты?

Подключение оплаты и фискализации обычно укладывается в месяц. Если нужно связать оплату с доставкой, учётом в 1С и управлением чеками, как в Xstreet, закладывайте около двух месяцев.

### Когда нужен второй эквайринг?

Если у вас больше пяти продаж в день. Сбой единственного провайдера останавливает продажи, а резервный эквайринг позволяет переключиться без простоя.

### Можно ли принимать оплату без интеграции с сайтом?

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

## Выводы

Интеграция оплаты — это не кнопка, а цепочка «платёж → статус → чек → доставка → учёт». Для маленького проекта достаточно ссылки на оплату от банка или ЮKassa. Когда платежей много, нужны интеграция, два независимых эквайринга и время на согласование статусов между всеми сервисами. По нашему опыту больше всего проблем создают не платёжные системы, а звенья вокруг них и процессы людей.

Если нужно подключить оплату к сайту или приложению и выстроить надёжную цепочку от платежа до чека, [обсудите задачу с WAPP](/ru/contacts).

---

## Blog: Сократили 70% штата: к чему готовиться, когда запускаешь агентский бизнес в ИТ

- **Slug:** `it-agency-business-mistakes`
- **Locale:** `ru`

## Введение

Моей веб-студии уже несколько лет. За это время я прошёл путь от «вау, я предприниматель» до суровой реальности агентского бизнеса: касса, продажи, найм, срывы сроков и неизбежные решения по штату.

Этот материал — не мотивация, а честный разбор того, к чему стоит готовиться, если вы запускаете ИТ-агентство.

## О чём пойдёт речь

- Деньги и дисциплина учёта.
- Продажи без «волшебного» inbound.
- Команда: когда расти и когда останавливаться.
- Типовые ошибки, которые дорого стоят в ретроспективе.

Полный текст с восемью разделами-ошибками и личными историями переносится в MDX; здесь — заявка на структуру и SEO для ленты блога.

---

## Blog: We cut 70% of staff: what to expect when you launch an IT agency business

- **Slug:** `it-agency-business-mistakes`
- **Locale:** `en`

## Introduction

The studio has been running for several years. Along the way I moved from “wow, I’m a founder” to the hard reality of agency work: cash flow, sales, hiring, slipped deadlines, and the inevitable staffing decisions.

This is not a pep talk — it is a blunt look at what to expect if you launch an IT services business.

## What we will cover

- Money and accounting discipline.
- Sales without magical inbound.
- Team: when to scale and when to stop.
- Expensive mistakes that only look obvious in hindsight.

The full eight-part story is being migrated into MDX; this stub anchors structure and SEO for the blog index.

---

## Blog: React Native или натив: что выбрать для приложения

- **Slug:** `krossplatformennaya-razrabotka`
- **Locale:** `ru`

Выбор между React Native и нативом часто делают по привычке или по чужому холивару — а не по задаче продукта. Ниже — критерии, по которым можно отличить типовой сервисный клиент от сценария, где без нативного стека не обойтись. Материал опирается на практику [мобильной разработки WAPP](/ru/services/mobile-development): в стеке студии и React Native, и SwiftUI. Порог проекта — от 1,5 млн ₽.

## Два реальных примера: когда стек совпал с задачей

Дискуссия «React Native против натива» легко уходит в веру: кто-то помнит уход Airbnb с React Native, кто-то приводит Discord или Shopify. Чужой опыт без контекста бесполезен. Полезнее смотреть на конкретную задачу и на то, что уже сделано в портфолио.

**Нативная задача — платёжный SDK.** В кейсе [рефакторинга YandexPayProxySDK для Beeline](/ru/project/beeline-kazakhstan) речь о платёжном SDK для iOS в highload-приложении на SwiftUI: адаптация и рефакторинг под требования оператора и эквайринга. Здесь нужен прямой контроль над нативным UI платёжного экрана и над бинарным SDK — кроссплатформенная обёртка не закрывает такой контур.

**React Native — клиент онлайн-уроков.** [Glinka Digital](/ru/project/glinka-digital) — приложение для онлайн-уроков музыки на React Native: чат на Matrix, кастомный WebRTC для связи, бэкенд на Laravel. Там, где стандартных модулей React Native не хватило — например, переключение на широкий угол камеры для постановки рук — часть SDK доработали нативными модулями. Одна кодовая база для iPhone и iPad, точечный натив там, где этого требует сценарий урока.

### Общая ошибка при выборе

Ошибка не в том, что «React Native плох» или «натив всегда дороже». Ошибка — выбирать стек до карты сценариев: без ответа, где типовой UI и серверная логика, а где железо, медиапоток или платёжный SDK. Дальше в статье — критерии и матрица, чтобы зафиксировать подход до старта разработки, а не после первого провалившегося релиза.

## Кроссплатформенная и нативная разработка: в чём разница на практике

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

### Нативная разработка: два приложения, два мира

Нативная разработка означает, что для каждой платформы пишется отдельный код на «родном» языке программирования. Для iOS это Swift (или SwiftUI как фреймворк пользовательского интерфейса), для Android — Kotlin. Два репозитория, две команды разработчиков, два параллельных процесса тестирования и запуска.

Главная особенность: нативные приложения получают полный доступ ко всем API и функциям устройства сразу после выхода новых версий операционных систем. Камера, Bluetooth, ARKit, HealthKit, платёжные сервисы — всё работает без прослоек и костылей. Производительность максимальная, потому что код компилируется напрямую под конкретную платформу.

Но за это приходится платить. И речь не только про бюджет. Каждую новую фичу нужно реализовать дважды, протестировать дважды, поддерживать дважды. Любой баг-фикс — это изменения в двух кодовых базах. Найти и удержать разработчиков на два отдельных стека тоже сложнее.

### Кроссплатформенная разработка: одна кодовая база, две платформы

Кроссплатформенная разработка позволяет создавать приложения для iOS и Android из единой кодовой базы. Популярные кроссплатформенные фреймворки в 2026 году — React Native, Flutter (от Google, язык Dart), Kotlin Multiplatform. Xamarin фактически ушёл со сцены, уступив место .NET MAUI, но и тот используется реже.

Идея проста: команда пишет код один раз, а фреймворк адаптирует результат под разные платформы. На практике это позволяет использовать общий исходный код для бизнес-логику, элементы интерфейса и работу с данными на разных устройствах. Разработка кроссплатформенных приложений сокращает объём работы, но говорить «вдвое дешевле» — преувеличение. Часть кода всё равно приходится писать нативно: биометрия, сложные анимации экрана, интеграция с платёжными SDK. Подробнее о том, как это влияет на [стоимость разработки](/ru/blog/mobile-app-development-cost), разберём в отдельном разделе далее в статье.

### Что изменилось к 2026 году: старые сравнения больше не работают

Если кто-то ссылается на статьи 2019–2021 годов о том, что React Native «тормозит» — эти данные устарели. Главная техническая перемена: React Native перешёл на новую архитектуру с JSI (JavaScript Interface) вместо старого bridge. Раньше каждый вызов между JavaScript и нативным кодом шёл через асинхронный мост с сериализацией данных, и это создавало узкое место. Сейчас JSI позволяет JavaScript напрямую вызывать нативные функции — быстро, синхронно, без лишней обработки.

Flutter тоже не стоял на месте: Impeller-рендерер решил давнюю проблему с «джанком» на первых кадрах, а поддержка веб- и десктоп-платформ вышла из статуса эксперимента.

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

## Миф про двойную экономию: сколько реально стоит общая кодовая база

Один код — два приложения — вдвое дешевле. Эту формулу повторяют так часто, что она превратилась в аксиому. Но на практике кроссплатформенная разработка мобильных приложений экономит ощутимо, только не в два раза. И если заложить в бюджет ожидание двукратной экономии, проект рискует остаться без денег на финишной прямой.

### Где экономия реальна

Общая кодовая база действительно сокращает объём работы. Бизнес-логику, экраны каталогов, формы авторизации, личные кабинеты, списки заказов — всё это команда пишет один раз на JavaScript или Dart, и код работает сразу на iOS и Android. Для приложений с типовым пользовательским интерфейсом — а это большая часть сервисов доставки, маркетплейсов, корпоративных порталов — переиспользуемая часть кода может быть значительной. Вместо двух отдельных команд разработчиков (Swift/Kotlin) достаточно одной, которая использует React Native или Flutter. Это позволяет быстро выкатить первую версию продукта на обе платформы и сократить сроки запуска.

### Куда уходят «сэкономленные» деньги

Проблема в том, что создать приложение — это не только написать UI-компоненты и логику на фреймворке. Вот что остаётся за рамками единой кодовой базы:

- **Нативные модули.** Биометрия, Bluetooth, push-уведомления, работа с камерой — всё это требует отдельных решений для каждой операционной системы. Некоторые библиотеки уже готовы, но под конкретной задачей часто приходится писать обёртки вручную.
- **Тестирование на двух ОС.** Один файл кода не гарантирует одинаковое поведение на разных устройствах. Приложение нужно проверять на десятках комбинаций версий iOS и Android, разрешений экрана, чипсетов. Это отдельная строка в бюджете, и она не меньше, чем при нативной разработке.
- **Адаптация UX-паттернов.** Пользователи iOS ожидают жесты и элементы навигации, отличные от того, к чему привыкли пользователи Android. Кнопку «Назад», поведение свайпов, стиль модальных окон — всё это нужно адаптировать под каждую платформу. Дизайн пользовательского интерфейса «один на всех» выглядит чужеродно и снижает конверсию.
- **Ревью в App Store и Google Play.** У магазинов приложений разные требования, разные сроки проверки, разная политика обновления. Подготовка сборок, скриншотов, описаний — двойная работа вне зависимости от подхода к разработке.
- **Интеграция с платформенными API и сервисами.** HealthKit, Google Fit, NFC, ARKit — эти возможности привязаны к конкретной системы и потребуют нативного кода, даже если весь остальной проект на React Native.

### Считайте на горизонте поддержки

Главная ловушка — оценивать стоимость разработки только до запуска. После релиза приложения живут годами: новые версии операционных систем, изменения в API, обновления зависимостей. С единой кодовой базой вносить изменения проще и быстрее, потому что правка в одном месте сразу попадает на обе платформы. Поддержка двух нативных приложений обходится дороже: две команды, два набора инструментов, два потока багов.

Именно на дистанции — год, два, три — кроссплатформенный подход даёт наибольшие преимущества. Но конкретный процент экономии зависит от проекта: от сложности интеграций, количества нативных модулей, интенсивности обновлений. Универсальной цифры тут нет. Подробнее о том, из чего складывается бюджет, — в [разборе стоимости разработки мобильных приложений](/ru/blog/mobile-app-development-cost).

Для проектов с порогом от 1,5 млн ₽ вопрос выбора между кроссплатформой и нативом — это не вопрос «сэкономить или нет». Это вопрос того, на что именно пойдут ресурсы: на дублирование кода или на качественную проработку функций, которые делают продукт полезным для клиентов.

## Когда React Native закрывает задачу

Большинство мобильных приложений на рынке делает одно и то же: забирает данные с сервера, показывает их пользователю в виде списков, карточек и форм, отправляет обратно. Никаких тяжёлых вычислений на устройстве, никакой обработки видео в реальном времени. Основная нагрузка ложится на API и бэкенд, а клиентская часть отвечает за отображение и навигацию. Именно для таких сценариев React Native подходит хорошо.

### Сценарии, где кроссплатформенная разработка закрывает задачу

**MVP для проверки гипотезы.** Когда нужно быстро выйти на рынок и проверить, готовы ли пользователи платить за продукт, писать два нативных приложения — расточительство. Одна кодовая база позволяет запустить версии для iOS и Android сразу, сократить сроки и сохранить бюджет для маркетинга. Если гипотеза не сработала, потери меньше. Сработала — можно масштабировать на той же базе.

**Личные кабинеты и внутренние сервисы компании.** Элементы пользовательского интерфейса здесь стандартные: формы ввода, список заказов, контакты, история операций. Такие приложения живут на данных из бэкенда, и кроссплатформенный фреймворк справляется с этим без компромиссов.

**Каталоги товаров и маркетплейсы.** Карточки, фильтры, корзина, экран оформления заказа. Логику обработки платежей берёт на себя серверная часть, а на клиенте остаётся только UI. Discord и Shopify, например, годами используют React Native в продакшене для подобных задач.

**Сервисы доставки и логистики.** Карта, статус заказа, чат с курьером. Производительность здесь зависит от качества API и интеграции с картографическими SDK, а не от вычислительной мощности устройства.

**Контентные платформы и блог-приложения.** Лента статей, система управления подписками, push-уведомления. Создавать такие приложения на кроссплатформенных фреймворках проще и быстрее, чем разрабатывать отдельных клиентов для каждой операционной системы.

### Реальный пример

[Glinka Digital](/ru/project/glinka-digital) — клиент онлайн-уроков музыки на React Native: одна кодовая база для iPhone и iPad, чат на Matrix, кастомный WebRTC для видеосвязи. Там, где стандартных модулей не хватило (широкий угол камеры, звук инструмента без агрессивного шумоподавления), часть логики вынесли в нативные модули. Это не «чистый» UI-каталог — но и не повод сразу писать два полностью нативных клиента: общий слой на React Native, точечный натив под сценарий урока.

### Каким проектам этого достаточно

Если главная задача продукта — показать данные и дать пользователю удобно с ними взаимодействовать, React Native обычно закрывает контур без потери качества. Сценарии, где без натива не обойтись, — отдельно ниже.

## Когда без натива не обойтись

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

### Глубокая работа с железом

Камера с кастомным пайплайном обработки, Bluetooth Low Energy для медицинских устройств, NFC для пропускных систем, продвинутые датчики — всё это API, которые на каждой платформе реализованы по-разному. React Native позволяет обращаться к ним через мосты, но когда нужна тонкая настройка, например, управление фокусом камеры покадрово или парсинг нестандартных BLE-характеристик, мост становится узким местом. Код приходится писать на Swift или Kotlin отдельно под iOS и Android, и кроссплатформенная обёртка превращается в иллюзию единой кодовой базы.

### Обработка медиа в реальном времени

Видеоредакторы, приложения с AR-сценами, аудиообработка с минимальной задержкой. Производительность здесь критична: каждый лишний слой между кодом и GPU добавляет миллисекунды, а пользователь видит дропнутые кадры или рассинхрон звука. Ни Flutter, ни React Native не дают прямого доступа к Metal на iOS или Vulkan на Android без нативных модулей. Если ядро продукта — медиа, проще сразу разрабатывать на нативном языке программирования каждой платформы.

### Платёжные SDK и финтех

Банки и платёжные системы выпускают SDK с жёсткими требованиями: конкретная версия Xcode, подпись сертификатами, запрет на модификацию бинарного файла. Попытка завернуть такой SDK в JavaScript-мост создаёт хрупкую конструкцию, которую приходится чинить после каждого обновления. Пример из портфолио: [рефакторинг и адаптация YandexPayProxySDK для Beeline](/ru/project/beeline-kazakhstan) — платёжный SDK для iOS в highload-приложении на SwiftUI. Нужен прямой контроль над нативным платёжным UI и над самим SDK; кроссплатформенный фреймворк здесь не закрывает задачу.

### Игры, 3D и сложные анимации

60 fps при рендере трёхмерных сцен, физика, шейдеры — всё это территория нативных движков. Для мобильных игр используется Unity или Unreal, для интерактивных 3D-элементов интерфейса — SceneKit, RealityKit, OpenGL ES. Кроссплатформенные фреймворки здесь попросту не конкуренты: они проектировались для пользовательского интерфейса бизнес-приложений, а не для рендера в реальном времени.

### Приложения с повышенными требованиями к безопасности

Банкинг, хранение данных клиентов, работа с биометрией на уровне операционных систем. Когда политика конфиденциальности и регуляторные требования диктуют использование Keychain, Secure Enclave, Android Keystore напрямую, без промежуточных слоёв, нативный подход закрывает эти задачи быстрее и надёжнее. Некоторые компании проходят аудит безопасности, и аудиторы хотят видеть прямые вызовы системных API, а не обёртки.

### Честная позиция

Выбрать натив — не значит «всегда дороже». Это значит, что конкретной задаче нужен конкретный инструмент. Важно не путать реальную необходимость с перестраховкой: многие запросы «только натив» на деле закрываются React Native, если продукт — типовой сервисный клиент. Нативная разработка оправдана, когда техническая особенность продукта сразу попадает в список выше. Во всех остальных случаях стоит считать ресурсы и сроки.

## Нативные модули внутри кроссплатформенного проекта: гибридная реальность

На практике кроссплатформенная разработка почти никогда не бывает «чистой». Любой проект средней сложности рано или поздно упирается в точку, где JavaScript-код на React Native не может дотянуться до нужной функции операционной системы напрямую. И тогда приходится писать нативные модули — куски кода на Swift, Kotlin или Objective-C, которые работают как мост между кроссплатформенным слоем и «железом» устройства.

Это не баг фреймворка. Это реальность.

### Где заканчивается кроссплатформа и начинается натив

У типового приложения с каталогом, корзиной и личным кабинетом основная часть кода обычно общая для двух платформ. Экраны, формы, навигация, бизнес-логика — это React Native закрывает без проблем. Но вот список того, что регулярно требует отдельных нативных модулей для iOS и Android:

- Биометрия (Face ID, сканер отпечатков) с кастомной обработки сценариев
- Bluetooth Low Energy для связи с внешними устройствами
- Сложные анимации пользовательского интерфейса, привязанные к жестам
- Push-уведомления с нестандартной логикой (например, Rich Notifications с интерактивными элементами)
- Работа с камерой и AR-функциями, которые завязаны на API конкретной платформы
- Платёжные SDK, которые поставляются только в нативном виде

Готовые библиотеки закрывают часть этих задач. Но когда нужна конкретная интеграция под конкретный сервис — например, [платёжный SDK для оператора связи](/ru/project/beeline-kazakhstan) — приходится спускаться на уровень нативного кода и писать модуль вручную.

### Что это значит для команды

Главная ловушка: компании набирают команду из React Native-разработчиков и думают, что этого достаточно. А потом выясняется, что для создания модуля под Bluetooth нужен человек, который понимает CoreBluetooth на iOS и BluetoothGattServer на Android. Два разных API, два разных подхода к управления соединениями, две версии кода.

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

Именно поэтому WAPP держит в стеке и React Native, и SwiftUI: [разработка мобильных приложений](/ru/services/mobile-development) на практике — это гибридный подход, а не выбор одного инструмента навсегда. Кроссплатформенный фреймворк берёт на себя общий объём работы, нативная разработка точечно закрывает то, что фреймворк не тянет.

### Это нормально — и вот почему

Некоторые воспринимают необходимость нативных модулей как провал кроссплатформенного подхода. Думают: «Раз всё равно приходится писать нативный код, зачем вообще было выбирать React Native?» На практике это нормальный гибрид: общий слой закрывает экраны и бизнес-логику на обеих платформах, а нативные модули точечно дотягивают железо и SDK. Обновления общей логики вносятся один раз; нативные модули тестируют изолированно — без полного дублирования двух клиентов.

Звучит просто, но на практике важно сразу закладывать эту гибридность в архитектуру. Если проект изначально спроектирован так, что нативные модули подключаются как изолированные блоки, добавлять новые функции можно быстро, без рефакторинга всего приложения. Если нет — каждый нативный модуль превращается в костыль, и качество продукта падает.

## Стоимость поддержки: расходы, о которых забывают на старте

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

### Что входит в стоимость поддержки мобильного приложения

Каждый год Apple и Google выкатывают новые версии iOS и Android. Это не формальность. Изменения затрагивают API, политику конфиденциальности, требования к элементам пользовательского интерфейса, работу фоновых сервисов. Приложение, которое отлично работало в июне, к октябрю может начать вылетать на свежих устройствах. Нужно адаптировать код, проводить тестирование, заливать обновления в магазины.

Если проект написан нативно на Swift и Kotlin, команда делает эту работу дважды: отдельно для каждой платформы. Два разработчика, два цикла проверки, два релиза. Ресурсы на поддержку удваиваются, и это не разовая история, а ежегодная. При единой кодовой базе на React Native или Flutter адаптация проще: большую часть изменений вносят один раз в общий код. Но есть подвох.

### Зависимость от экосистемы фреймворка

Кроссплатформенные фреймворки сами по себе быстро меняются. React Native перешёл на New Architecture, Flutter обновляет Dart и движок рендеринга. Эти изменения иногда ломают совместимость со сторонними библиотеками, на которых построена часть приложения. Результат: разработчик обновляет не только свой исходный код, но и разбирается, почему популярные пакеты перестали работать после миграции на новую версию фреймворка.

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

### Чем это оборачивается на практике

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

Второй сценарий: проект использует пять-шесть сторонних JavaScript-библиотек, одна из которых перестала поддерживаться автором. Нужно либо написать замену, либо форкнуть репозиторий и сопровождать его самостоятельно. Оба варианта дорогие.

Третий: команда хочет добавить новые функции, но архитектура не готова к расширению. Каждая фича требует рефакторинга, сроки растут, и стоимость поддержки мобильного приложения за год может сравняться с расходами на его создание. Думаю, это главная ошибка, которую делают на старте: считают только бюджет на запуск и забывают, что приложение живёт годами. Выбор стека определяет не только скорость первого релиза, а полный цикл расходов на весь период жизни продукта. Подробнее о формировании бюджета на разных этапах разработки можно прочитать в [блоге WAPP](/ru/blog/mobile-app-development-cost).

## Матрица выбора: тип проекта → рекомендуемый подход

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

### Как читать матрицу

По строкам — типовые бизнес-сценарии, с которыми приходят клиенты. По столбцам — рекомендуемый подход и главная причина, почему именно он. Кроссплатформенная разработка обозначена как «КП», нативная — «Натив», гибридный вариант (единая кодовая база + нативные модули для отдельных функций) — «Гибрид».

| Тип проекта | Подход | Ключевой аргумент |
|---|---|---|
| MVP / стартап на стадии проверки гипотезы | КП (React Native, Flutter) | Скорость запуска на iOS и Android сразу из одной кодовой базы. Бюджет меньше, время до рынка — короче. Если гипотеза не сработает, потери минимальны |
| Маркетплейс / e-commerce (каталог, корзина, личный кабинет) | КП | Основная логика живёт на сервере, приложение отображает данные и работает с API. Элементы пользовательского интерфейса типовые |
| Банкинг / финтех с платёжными SDK | Гибрид или Натив | Интеграция платёжных SDK часто требует нативного кода на Swift или Kotlin. Политика конфиденциальности и требования регуляторов диктуют контроль над каждой платформой. Пример нативной задачи — [рефакторинг YandexPayProxySDK для Beeline](/ru/project/beeline-kazakhstan) |
| Приложение с AR / камерой / обработки видео в реальном времени | Натив | Производительность критична. Кроссплатформенные фреймворки добавляют прослойку, которая съедает кадры. Нативная разработка даёт прямой доступ к GPU и API устройств на уровне операционных систем |
| Корпоративный портал / CRM / внутренний сервис | КП | Дизайн стандартный, аудитория пользователей ограничена. Писать два отдельных приложения — расточительство. Фреймворк вроде React Native или Flutter позволяет создать решение быстрее и проще поддерживать силами одной команды |
| Сервис с видеосвязью и чатом (уроки, консультации) | КП с нативными модулями | Общий клиент на React Native, точечный натив под камеру и звук. Пример — [Glinka Digital](/ru/project/glinka-digital): Matrix, кастомный WebRTC, нативные модули для широкого угла камеры |
| Сервис доставки (карты, геолокация, push, трекинг) | КП с нативными модулями | Большая часть интерфейса — списки, экран карты, чат. Фоновая геолокация и Bluetooth-терминалы на разных устройствах лучше реализовать нативно. Гибридный подход здесь — оптимальный вариант |
| Приложение с тяжёлой медиа-обработкой (видеоредактор, стриминг, 3D) | Натив | JavaScript-мост не справляется с потоковой обработкой данных. Нужен прямой доступ к железу, библиотеки на C++ и нативные API каждой платформы. Других решений пока нет |

### Почему матрица — ориентир, а не приговор

Думаю, главная ошибка — воспринимать такие таблицы как готовый ответ. Это не так. Разработка кроссплатформенных приложений для e-commerce может потребовать нативных модулей, если в проекте есть сложные анимации или AR-примерка. А нативное мобильное приложение для банка иногда имеет смысл стартовать как кроссплатформенный MVP, чтобы быстро проверить спрос, и только потом переписать.

Выбор стека зависит от конкретной ситуации: какие ресурсы есть у команды, какие сроки ставит бизнес, какие новые функции планируются через полгода. Матрица даёт направление. Финальное решение — за теми, кто знает контекст проекта изнутри. Если нужна помощь с оценкой, подробнее об [услуги мобильной разработки](/ru/services/mobile-development) и процессе работы — на сайте WAPP.

## Частые вопросы о кроссплатформенной разработке

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

### Правда ли, что кроссплатформенные приложения тормозят?

Этот миф тянется из начала 2010-х, когда фреймворки вроде Xamarin и ранних версий React Native действительно проигрывали нативным приложениям по скорости. В 2026 году ситуация другая. React Native с New Architecture и JSI (JavaScript Interface) убрал старый «мост» между JavaScript и нативным кодом. Вызовы к платформенным API идут напрямую, без сериализации данных в JSON-файл. Результат: анимации пользовательского интерфейса работают на 60 fps, холодный запуск приложения сопоставим с нативным. Для большинства бизнес-приложений — каталогов, сервисов доставки, личных кабинетов — разницу в производительности пользователей заметить не получится. Тормоза возникают там, где кроссплатформенная разработка применяется не по назначению: обработка видео в реальном времени, тяжёлая 3D-графика, сложных вычислений на устройствах без серверной поддержки.

### Можно ли перейти с React Native на натив, если упрёмся в ограничения?

Да, и это не катастрофа, если архитектура проекта выстроена грамотно. React Native позволяет использовать модульный подход: бизнес-логику выносят в отдельные слои, а экраны создают как независимые компоненты. Когда конкретной части приложения не хватает возможностей фреймворка, её переписывают на Swift или Kotlin — без полного сноса кодовой базы. Так же устроен гибрид в [Glinka Digital](/ru/project/glinka-digital): общий клиент на React Native, нативные модули там, где нужен контроль камеры и звука. Главная рекомендация: закладывайте модульность сразу на старте, чтобы изменения не потребовали переписать всё с нуля.

### Flutter или React Native — что выбрать в 2026 году?

Оба фреймворка готовы к продакшену, оба позволяют создавать приложения для iOS и Android из единой кодовой базы. Различия — в деталях. Flutter использует язык программирования Dart и рисует UI собственным движком, что даёт больше контроля над дизайном, но иногда усложняет интеграцию с нативными библиотеками платформы. React Native работает поверх нативных элементов каждой операционной системы, и экосистема JavaScript-разработчиков шире. В WAPP делаем ставку на React Native: рынок JS-специалистов больше, поддержка проекта обходится дешевле, а новые нативные API от Apple и Google подключаются быстро. Но если в команде сильный опыт с Dart или нужен нестандартный пользовательский интерфейс с кастомной отрисовкой — Flutter вполне подходит.

### Сколько стоит разработка кроссплатформенного приложения?

Стоимость разработки зависит от сложности продукта, количества экранов, интеграций с внешними сервисами и требований к дизайну. Порог входа для мобильных приложений среднего уровня — от 1,5 млн ₽. Простой MVP с авторизацией, каталогом и корзиной обойдётся дешевле, чем сервис с программой лояльности, Telegram-ботом, системами управления и аналитикой. Кроссплатформенный подход экономит бюджет на разработку по сравнению с созданием двух отдельных нативных приложений, но не вдвое — часть работы всё равно уникальна для каждой платформы: тестирование, адаптация, публикация в магазины. Подробный разбор ценообразования — в [статье о стоимости разработки мобильных приложений](/ru/blog/mobile-app-development-cost).

### Нужны ли отдельные разработчики для iOS и Android при кроссплатформенном подходе?

Полный штат из двух разных команд не нужен. Основную часть кода пишет одна команда React Native-разработчиков на JavaScript. Но вот без нативной экспертизы обойтись сложно: когда приложению нужна работа с Bluetooth, биометрией, специфическими API операционных системах или сложными анимациями — кто-то в команде должен уметь писать нативные модули на Swift и Kotlin. На практике хватает одного-двух специалистов с нативным опытом на проект, а не отдельных команд для каждой платформы. Это сокращает ресурсы и сроки, но сохраняет качество на разных устройствах.

## Выводы

Выбор между React Native и нативной разработкой — не вопрос «что лучше». Это вопрос «что подходит конкретной задаче, бюджету и горизонту планирования». Универсального ответа нет, и любой, кто утверждает обратное, скорее всего, продаёт один-единственный подход.

Вот три вещи, которые стоит забрать из этой статьи.

Экономия на кроссплатформенной разработке реальна, но не двукратная. Единая кодовая база сокращает объём работы, ускоряет запуск на iOS и Android сразу. Однако тестирование на разных устройствах, адаптация пользовательского интерфейса под особенности каждой платформы, нативные модули для Bluetooth или биометрии — всё это съедает часть сэкономленного. Итоговый результат зависит от типа продукта: для каталога или личного кабинета разница ощутима, для приложения с обработкой видео в реальном времени экономия может оказаться иллюзией.

Большинству бизнес-приложений React Native хватает. Каталоги, сервисы доставки, маркетплейсы, корпоративные программы — всё это работает на кроссплатформе без заметных компромиссов для пользователей. Но нативные модули — часть реальности, а не исключение. Практически в каждом проекте средней сложности команда сталкивается с необходимостью написать код на Swift или Kotlin для отдельных функций. Это нормально, и к этому нужно быть готовым сразу.

Считайте стоимость на горизонте двух-трёх лет. Дешёвый запуск иногда оборачивается дорогой поддержкой, а дорогой старт с нативной разработкой — стабильной и предсказуемой эксплуатацией. Обновления операционных систем, новые версии фреймворков, изменения в API — всё это влияет на бюджет после релиза. Главная ошибка — выбирать стек, глядя только на первый чек.

Если есть сомнения, какой подход подходит конкретному проекту, команда WAPP готова разобрать задачу и помочь выбрать стек — без привязки к одному инструменту. [Оставьте заявку на консультацию](/ru/services/mobile-development), и получите рекомендацию, основанную на восьми годах работы с мобильными приложениями на React Native и SwiftUI.

---

## Blog: React Native or native: what to choose for your app

- **Slug:** `krossplatformennaya-razrabotka`
- **Locale:** `en`

Choosing between React Native and native is often habit or someone else’s holy war — not the product’s actual job. Below are criteria that separate a typical service client from a scenario that needs a native stack. The piece draws on [WAPP’s mobile development practice](/en/services/mobile-development): the studio ships both React Native and SwiftUI. Project floor — from RUB 1.5M.

## Two real examples: when the stack matched the job

The “React Native vs native” debate easily becomes faith: some remember Airbnb leaving React Native; others cite Discord or Shopify. Other people’s experience without context is useless. It is more useful to look at the concrete task and at what is already in the portfolio.

**A native job — a payment SDK.** The [YandexPayProxySDK refactor for Beeline](/en/project/beeline-kazakhstan) is a payment SDK for iOS in a high-load app on SwiftUI: adaptation and refactoring for the operator’s and acquirer’s requirements. You need direct control over the native payment-screen UI and the binary SDK — a cross-platform wrapper does not close that loop.

**React Native — an online-lesson client.** [Glinka Digital](/en/project/glinka-digital) is a music online-lesson app on React Native: Matrix chat, custom WebRTC for calls, Laravel backend. Where standard React Native modules were not enough — for example switching to the ultra-wide camera for hand placement — parts of the SDK were extended with native modules. One shared codebase for iPhone and iPad, point native where the lesson scenario requires it.

### The shared mistake when choosing

The mistake is not that “React Native is bad” or “native is always more expensive.” The mistake is picking a stack before a scenario map: without answering where you have typical UI and server logic, and where you have hardware, a media stream, or a payment SDK. The rest of this article is criteria and a matrix so you lock the approach before development starts — not after the first failed release.

## Cross-platform and native development: the practical difference

Before you choose how to build mobile apps, it helps to understand how the two main options differ in practice — not on marketing slides, but at the level of code, team, and day-to-day work.

### Native development: two apps, two worlds

Native development means separate code for each platform in its “home” language. For iOS that is Swift (or SwiftUI as the UI framework); for Android — Kotlin. Two repositories, two developer teams, two parallel testing and release processes.

The main trait: native apps get full access to every device API and feature as soon as new OS versions ship. Camera, Bluetooth, ARKit, HealthKit, payment services — all without layers and hacks. Performance is maximal because code compiles directly for the platform.

But you pay for that — and not only in budget. Every new feature must be implemented twice, tested twice, supported twice. Any bug fix is a change in two codebases. Finding and retaining developers for two separate stacks is harder too.

### Cross-platform development: one codebase, two platforms

Cross-platform development lets you build apps for iOS and Android from a single codebase. Popular cross-platform frameworks in 2026 are React Native, Flutter (from Google, Dart language), and Kotlin Multiplatform. Xamarin has effectively left the stage for .NET MAUI, which is also used less often.

The idea is simple: the team writes code once, and the framework adapts the result to different platforms. In practice you can share source for business logic, UI elements, and data work across devices. Building cross-platform apps reduces workload, but saying “half the cost” is an exaggeration. Some code still has to be native: biometrics, complex screen animations, payment SDK integration. How that affects [development cost](/en/blog/mobile-app-development-cost) is covered later in this article.

### What changed by 2026: old comparisons no longer work

If someone cites 2019–2021 articles claiming React Native “lags” — that data is outdated. The main technical shift: React Native moved to a new architecture with JSI (JavaScript Interface) instead of the old bridge. Previously every call between JavaScript and native code went through an asynchronous bridge with data serialization, creating a bottleneck. Now JSI lets JavaScript call native functions directly — fast, synchronously, without extra processing.

Flutter did not stand still either: the Impeller renderer fixed the long-standing first-frame jank problem, and web and desktop support left experimental status.

Result: building mobile apps with cross-platform tools in 2026 is no longer a compromise for savings alone. For a large set of tasks, the cross-platform approach delivers quality comparable to native. But the zones where native is irreplaceable have not disappeared — and we cover them next.

## The double-savings myth: what a shared codebase really costs

One code — two apps — half the price. That formula is repeated so often it became an axiom. In practice, cross-platform mobile development saves meaningfully — just not by half. If you budget for twofold savings, the project risks running out of money near the finish line.

### Where savings are real

A shared codebase does reduce work. Business logic, catalogue screens, auth forms, personal accounts, order lists — the team writes once in JavaScript or Dart, and the code runs on both iOS and Android. For apps with typical UI — most delivery services, marketplaces, corporate portals — the reusable share can be large. Instead of two separate developer teams (Swift/Kotlin), one team on React Native or Flutter is enough. That lets you ship a first product version on both platforms quickly and shorten time to market.

### Where the “saved” money goes

The problem is that building an app is more than UI components and framework logic. Here is what stays outside the shared codebase:

- **Native modules.** Biometrics, Bluetooth, push notifications, camera work — all need separate solutions per OS. Some libraries are ready, but under a concrete task you often write wrappers by hand.
- **Testing on two OSes.** One code file does not guarantee identical behaviour on different devices. The app must be checked across dozens of iOS and Android version combinations, screen resolutions, and chipsets. That is a separate budget line, and it is no smaller than in native development.
- **UX pattern adaptation.** iOS users expect gestures and navigation elements different from what Android users are used to. The Back button, swipe behaviour, modal styles — all must be adapted per platform. A “one size fits all” UI looks foreign and hurts conversion.
- **App Store and Google Play review.** Stores have different requirements, review timelines, and update policies. Preparing builds, screenshots, and descriptions is double work regardless of development approach.
- **Platform API and service integration.** HealthKit, Google Fit, NFC, ARKit — these capabilities are tied to a specific system and need native code even if the rest of the project is React Native.

### Count the support horizon

The main trap is estimating development cost only up to launch. After release, apps live for years: new OS versions, API changes, dependency updates. With a shared codebase, changes are easier and faster because a fix in one place lands on both platforms. Supporting two native apps costs more: two teams, two toolchains, two bug streams.

It is over distance — one, two, three years — that the cross-platform approach delivers the greatest advantage. But the concrete savings percentage depends on the project: integration complexity, number of native modules, update intensity. There is no universal number. More on what makes up the budget — in [our breakdown of mobile app development cost](/en/blog/mobile-app-development-cost).

For projects from RUB 1.5M, the cross-platform vs native choice is not “save or not.” It is about where resources go: duplicating code, or polishing the features that make the product useful to customers.

## When React Native covers the job

Most mobile apps on the market do the same thing: pull data from a server, show it as lists, cards, and forms, send it back. No heavy on-device computation, no real-time video processing. Load sits on the API and backend; the client handles display and navigation. For those scenarios React Native fits well.

### Scenarios where cross-platform development covers the job

**MVP to test a hypothesis.** When you need to reach the market quickly and see whether users will pay, writing two native apps is wasteful. One codebase lets you launch iOS and Android versions together, shorten timelines, and keep budget for marketing. If the hypothesis fails, losses are smaller. If it works — you can scale on the same base.

**Personal accounts and internal company services.** UI elements here are standard: input forms, order lists, contacts, transaction history. These apps live on backend data, and a cross-platform framework handles that without compromise.

**Product catalogues and marketplaces.** Cards, filters, cart, checkout screen. Payment processing logic sits on the server; the client keeps only UI. Discord and Shopify, for example, have used React Native in production for years on similar work.

**Delivery and logistics services.** Map, order status, courier chat. Performance depends on API quality and map SDK integration, not on device compute power.

**Content platforms and blog apps.** Article feeds, subscription management, push notifications. Building such apps on cross-platform frameworks is simpler and faster than separate clients per OS.

### A real example

[Glinka Digital](/en/project/glinka-digital) is a music online-lesson client on React Native: one codebase for iPhone and iPad, Matrix chat, custom WebRTC for video. Where standard modules were not enough (ultra-wide camera, instrument audio without aggressive noise suppression), part of the logic moved into native modules. That is not a pure UI catalogue — and not a reason to write two fully native clients: a shared React Native layer, point native for the lesson scenario.

### Which projects this is enough for

If the product’s main job is to show data and let users work with it conveniently, React Native usually closes the loop without quality loss. Scenarios that need native are covered next.

## When you cannot do without native

Those projects share one trait: the app must work close to the hardware or squeeze the maximum from the device. Here is a concrete list of scenarios where native development remains the only reasonable option.

### Deep hardware work

Camera with a custom processing pipeline, Bluetooth Low Energy for medical devices, NFC for access systems, advanced sensors — all APIs implemented differently per platform. React Native can reach them through bridges, but when you need fine control — frame-by-frame camera focus, parsing non-standard BLE characteristics — the bridge becomes a bottleneck. Code has to be written in Swift or Kotlin separately for iOS and Android, and the cross-platform wrapper becomes an illusion of a shared codebase.

### Real-time media processing

Video editors, apps with AR scenes, audio processing with minimal latency. Performance is critical: every extra layer between code and GPU adds milliseconds, and users see dropped frames or audio desync. Neither Flutter nor React Native gives direct access to Metal on iOS or Vulkan on Android without native modules. If media is the product core, it is simpler to develop in each platform’s native language from the start.

### Payment SDKs and fintech

Banks and payment systems ship SDKs with hard requirements: a specific Xcode version, certificate signing, no binary modification. Wrapping such an SDK in a JavaScript bridge creates a fragile construct that breaks after every update. From the portfolio: [refactoring and adapting YandexPayProxySDK for Beeline](/en/project/beeline-kazakhstan) — a payment SDK for iOS in a high-load app on SwiftUI. You need direct control over the native payment UI and the SDK itself; a cross-platform framework does not close that job.

### Games, 3D, and complex animations

60 fps rendering of 3D scenes, physics, shaders — that is native-engine territory. Mobile games use Unity or Unreal; interactive 3D UI elements use SceneKit, RealityKit, OpenGL ES. Cross-platform frameworks are simply not competitors here: they were designed for business-app UI, not real-time rendering.

### Apps with elevated security requirements

Banking, client data storage, biometrics at the OS level. When confidentiality policy and regulatory requirements dictate using Keychain, Secure Enclave, and Android Keystore directly, without intermediate layers, the native approach closes those tasks faster and more reliably. Some companies undergo security audits, and auditors want to see direct system API calls, not wrappers.

### An honest position

Choosing native does not mean “always more expensive.” It means the concrete task needs a concrete tool. Do not confuse real necessity with over-insurance: many “native only” requests are closed by React Native when the product is a typical service client. Native development is justified when a technical trait of the product lands in the list above. In all other cases, count resources and timelines.

## Native modules inside a cross-platform project: hybrid reality

In practice, cross-platform development is almost never “pure.” Any mid-complexity project eventually hits a point where JavaScript on React Native cannot reach a needed OS function directly. Then you write native modules — pieces of Swift, Kotlin, or Objective-C that bridge the cross-platform layer and device hardware.

That is not a framework bug. That is reality.

### Where cross-platform ends and native begins

For a typical app with catalogue, cart, and personal account, most of the code is usually shared across both platforms. Screens, forms, navigation, business logic — React Native covers that without trouble. Here is what regularly needs separate native modules for iOS and Android:

- Biometrics (Face ID, fingerprint) with custom scenario handling
- Bluetooth Low Energy for external devices
- Complex UI animations tied to gestures
- Push notifications with non-standard logic (for example, Rich Notifications with interactive elements)
- Camera and AR features tied to a platform’s APIs
- Payment SDKs shipped only in native form

Ready libraries cover part of these tasks. But when you need a concrete integration for a concrete service — for example, a [payment SDK for a telecom operator](/en/project/beeline-kazakhstan) — you drop to native code and write the module by hand.

### What this means for the team

The main trap: companies hire a React Native team and assume that is enough. Then it turns out a Bluetooth module needs someone who understands CoreBluetooth on iOS and BluetoothGattServer on Android. Two different APIs, two approaches to connection management, two code versions.

Hence the rule: in any cross-platform project beyond “screens + forms,” you need at least one developer with native experience. Not necessarily a full-time hire — sometimes point engagement is enough. But if that person is missing entirely, the project risks stalling on the first non-trivial feature.

That is why WAPP keeps both React Native and SwiftUI in stack: [mobile app development](/en/services/mobile-development) in practice is a hybrid approach, not choosing one tool forever. The cross-platform framework takes the bulk of the work; native development point-closes what the framework cannot carry.

### That is normal — and here is why

Some treat the need for native modules as a failure of the cross-platform approach. They think: “If we still write native code, why choose React Native at all?” In practice this is a normal hybrid: the shared layer covers screens and business logic on both platforms, and native modules point-extend hardware and SDKs. Shared-logic updates land once; native modules are tested in isolation — without fully duplicating two clients.

It sounds simple, but in practice you should bake hybridity into the architecture from day one. If the project is designed so native modules plug in as isolated blocks, new features can be added quickly without refactoring the whole app. If not — every native module becomes a crutch, and product quality drops.

## Support cost: expenses people forget at the start

Architecture quality at kickoff is checked not at launch, but six months later. That is when the first OS updates arrive, third-party libraries break, and users start asking for new features. And that is when the cross-platform vs native choice affects budget more than at build time.

### What goes into mobile app support cost

Every year Apple and Google ship new iOS and Android versions. That is not a formality. Changes hit APIs, privacy policy, UI element requirements, background services. An app that worked fine in June may start crashing on fresh devices by October. You need to adapt code, test, and push store updates.

If the project is native on Swift and Kotlin, the team does that work twice: once per platform. Two developers, two QA cycles, two releases. Support resources double — and this is annual, not one-off. With a shared React Native or Flutter codebase, adaptation is easier: most changes land once in the shared code. But there is a catch.

### Dependency on the framework ecosystem

Cross-platform frameworks themselves change quickly. React Native moved to the New Architecture; Flutter updates Dart and the rendering engine. Those changes sometimes break compatibility with third-party libraries the app relies on. Result: the developer updates not only their source, but also digs into why popular packages stopped working after a framework migration.

Native development is not immune either, but dependency on foreign code is usually lower. SwiftUI or Jetpack Compose is supported by the platform vendor, and backward compatibility is a priority. In a cross-platform project an extra abstraction layer sits between the app and the OS, and any failure in that layer lands on the support team.

### What this looks like in practice

In WAPP’s practice one scenario shows up most often: the client launched a mobile app, spent the budget to the last coin, and did not reserve support resources. A new iOS version ships — the app stops rendering screen elements correctly or loses camera access. The fix costs money that was never planned.

Second scenario: the project uses five or six third-party JavaScript libraries, one of which the author stopped maintaining. You either write a replacement or fork the repo and maintain it yourself. Both options are expensive.

Third: the team wants to add features, but the architecture is not ready to grow. Every feature needs refactoring, timelines slip, and annual support cost can match the cost of building the app. That is the main early mistake: counting only the launch budget and forgetting the app lives for years. Stack choice determines not only first-release speed, but the full cost cycle over the product’s life. More on budgeting across development stages — in the [WAPP blog](/en/blog/mobile-app-development-cost).

## Choice matrix: project type → recommended approach

Let’s collapse everything above into one practical tool. Below is a matrix that links project type to a mobile development approach. It does not replace a full audit, but it helps you orient on stack choice before the first meeting with a development team.

### How to read the matrix

Rows are typical business scenarios clients bring. Columns are the recommended approach and the main reason for it. Cross-platform is marked “CP,” native “Native,” hybrid (shared codebase + native modules for selected features) “Hybrid.”

| Project type | Approach | Key argument |
|---|---|---|
| MVP / startup validating a hypothesis | CP (React Native, Flutter) | Launch speed on iOS and Android from one codebase. Smaller budget, shorter time to market. If the hypothesis fails, losses are minimal |
| Marketplace / e-commerce (catalogue, cart, personal account) | CP | Core logic lives on the server; the app displays data and talks to APIs. UI elements are typical |
| Banking / fintech with payment SDKs | Hybrid or Native | Payment SDK integration often needs native Swift or Kotlin. Privacy policy and regulators demand control per platform. A native-task example — [YandexPayProxySDK refactor for Beeline](/en/project/beeline-kazakhstan) |
| App with AR / camera / real-time video processing | Native | Performance is critical. Cross-platform frameworks add a layer that drops frames. Native development gives direct GPU and device API access at the OS level |
| Corporate portal / CRM / internal service | CP | Design is standard; the user audience is limited. Writing two separate apps is wasteful. A framework like React Native or Flutter lets you build faster and support with one team |
| Service with video calls and chat (lessons, consultations) | CP with native modules | Shared React Native client, point native for camera and audio. Example — [Glinka Digital](/en/project/glinka-digital): Matrix, custom WebRTC, native modules for ultra-wide camera |
| Delivery service (maps, geolocation, push, tracking) | CP with native modules | Most of the UI is lists, map screen, chat. Background geolocation and Bluetooth terminals on different devices are better native. Hybrid is optimal here |
| App with heavy media processing (video editor, streaming, 3D) | Native | The JavaScript bridge cannot handle streaming data. You need direct hardware access, C++ libraries, and each platform’s native APIs. There is no other option yet |

### Why the matrix is a guide, not a verdict

The main mistake is treating such tables as a finished answer. They are not. Cross-platform e-commerce apps may still need native modules if the project has complex animations or AR try-on. And a native banking app sometimes makes sense to start as a cross-platform MVP to test demand, then rewrite later.

Stack choice depends on the concrete situation: team resources, business timelines, features planned in six months. The matrix gives direction. The final call belongs to those who know the project context from inside. If you need help assessing, more on [mobile development services](/en/services/mobile-development) and the working process — on the WAPP site.

## Frequently asked questions about cross-platform development

Below are the questions people ask most often before a project starts. Each without fluff.

### Is it true that cross-platform apps are slow?

This myth dates to the early 2010s, when frameworks like Xamarin and early React Native really lost to native apps on speed. In 2026 the picture is different. React Native with the New Architecture and JSI (JavaScript Interface) removed the old “bridge” between JavaScript and native code. Platform API calls go directly, without serializing data to JSON. Result: UI animations run at 60 fps; cold start is comparable to native. For most business apps — catalogues, delivery services, personal accounts — users will not notice a performance difference. Slowdowns appear where cross-platform is used for the wrong job: real-time video processing, heavy 3D graphics, complex on-device computation without server support.

### Can you move from React Native to native if you hit limits?

Yes — and it is not a catastrophe if the architecture is sound. React Native supports a modular approach: business logic lives in separate layers, screens are independent components. When one part of the app outgrows the framework, you rewrite it in Swift or Kotlin without demolishing the whole codebase. The same hybrid pattern appears in [Glinka Digital](/en/project/glinka-digital): a shared React Native client, native modules where camera and audio need control. Main recommendation: design for modularity from the start so changes do not force a full rewrite.

### Flutter or React Native — what to choose in 2026?

Both frameworks are production-ready; both let you build iOS and Android apps from one codebase. Differences are in the details. Flutter uses Dart and draws UI with its own engine, which gives more design control but can complicate integration with native platform libraries. React Native sits on each OS’s native elements, and the JavaScript developer ecosystem is wider. At WAPP we bet on React Native: the JS talent market is larger, project support costs less, and new native APIs from Apple and Google connect quickly. But if the team has strong Dart experience or you need a non-standard UI with custom drawing — Flutter is a solid fit.

### How much does cross-platform app development cost?

Development cost depends on product complexity, screen count, external integrations, and design requirements. The entry floor for mid-level mobile apps is from RUB 1.5M. A simple MVP with auth, catalogue, and cart costs less than a service with loyalty, a Telegram bot, management systems, and analytics. The cross-platform approach saves development budget versus two separate native apps — but not by half: some work stays unique per platform: testing, adaptation, store publishing. A detailed pricing breakdown is in the [article on mobile app development cost](/en/blog/mobile-app-development-cost).

### Do you need separate iOS and Android developers with a cross-platform approach?

A full staff of two different teams is not required. Most code is written by one React Native team in JavaScript. But native expertise is hard to avoid: when the app needs Bluetooth, biometrics, OS-specific APIs, or complex animations — someone on the team must write native modules in Swift and Kotlin. In practice one or two specialists with native experience per project is enough, not separate teams per platform. That cuts resources and timelines while keeping quality across devices.

## Conclusions

Choosing between React Native and native development is not “which is better.” It is “what fits the concrete task, budget, and planning horizon.” There is no universal answer, and anyone who claims otherwise is usually selling a single approach.

Here are three takeaways from this article.

Savings from cross-platform development are real, but not twofold. A shared codebase reduces work and speeds launch on iOS and Android together. But testing on different devices, adapting UI to each platform, native modules for Bluetooth or biometrics — all of that eats part of the savings. The outcome depends on product type: for a catalogue or personal account the difference is tangible; for an app with real-time video processing the savings may be an illusion.

Most business apps are fine on React Native. Catalogues, delivery services, marketplaces, corporate programs — all work cross-platform without noticeable compromise for users. But native modules are part of reality, not an exception. In almost every mid-complexity project the team must write Swift or Kotlin for selected features. That is normal, and you should be ready for it from day one.

Count cost over a two-to-three-year horizon. A cheap launch can turn into expensive support; an expensive native start can mean stable, predictable operations. OS updates, new framework versions, API changes — all affect post-release budget. The main mistake is choosing a stack looking only at the first invoice.

If you are unsure which approach fits a concrete project, the WAPP team can unpack the task and help choose a stack — without locking to one tool. [Leave a request for a consultation](/en/services/mobile-development) and get a recommendation based on eight years of mobile work on React Native and SwiftUI.

---

## Blog: Автоматизация лаборатории: что автоматизировать в первую очередь и с чего начать

- **Slug:** `lab-automation-where-to-start`
- **Locale:** `ru`

Руководство требует сократить сроки выдачи протоколов, повысить точность, пройти проверку без замечаний. Автоматизация лаборатории нужна — но с чего начать, когда оцифровать хочется всё сразу, а ресурсов на это недостаточно?

Ниже — алгоритм: как разобрать процессы лаборатории, расставить приоритеты и выбрать систему под реальные задачи.

## С чего начинается автоматизация лаборатории: схема процессов

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

### Что это такое и зачем

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

Пример. Специалист принял пробу, записал в лабораторный журнал, отнёс на рабочее место. Второй провёл измерения, записал от руки, потом внёс в Excel. Третий подставил значения в шаблон итогового документа. На этих переходах — ручной ввод, передача информации между людьми, риск ошибок и потери времени. Именно здесь скрыта главная возможность для автоматизации.

### Как составить схему

Самый надёжный способ — пройти путь пробы физически. Встать рядом с приёмкой и проследить: кто принимает заявку, куда вносит сведения, как образец попадает на анализ, где фиксируются результаты. На каждом шаге задавать два вопроса: делает ли сотрудник лаборатории то, что могло бы выполнять автоматизированное рабочее место? Переписываются ли данные из одного места в другое?

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

Без схемы внедрение превращается в лотерею. Лаборатория покупает дорогую систему и обнаруживает, что узкое место было не там. Деньги потрачены, а сотрудники по-прежнему копируют цифры между таблицами.

## Что автоматизировать в первую очередь

Оцените каждый процесс по двум осям: эффект и сложность внедрения. Высокий эффект при низком пороге входа — первые кандидаты.

### Регистрация проб

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

### Учёт реактивов в лаборатории

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

### Электронный лабораторный журнал

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

### Формирование протоколов

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

### Внутрилабораторный контроль качества

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

### Частая ошибка

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

Разумная стратегия — связка регистрация проб плюс формирование протоколов. Два конца одной цепочки. Остальное подключается на следующем этапе.

## Почему Excel опасен для аккредитованной лаборатории

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

Вторая проблема — разрозненность. Учёт проб в одном файле, журналы оборудования в другом, реестр протоколов на сетевом диске, часть записей на бумаге. Единой картины работы лаборатории нет, а перед проверкой специалист собирает сведения по разным компьютерам и сверяет версии. Информационная система решает эту задачу за минуты: данные лежат в одной базе, поиск идёт по любому параметру.

Excel работает, пока объёмы малы. С ростом числа образцов файлы конфликтуют при одновременном доступе, формулы ломаются, версии множатся. Для лаборатории, которая растёт, это вопрос времени.

Отдельная тема — сопротивление персонала. Даже дорогая ЛИМС превращается в витрину для аудиторов, если интерфейс противоречит реальной работе за вытяжным шкафом. Почему так происходит и как этого избежать, мы разобрали в статье [«Почему лаборанты саботируют LIMS»](/ru/blog/why-lab-staff-bypass-lims) — там же лежит сравнительная таблица решений, представленных на рынке.

## Системы автоматизации лабораторий: что выбрать

### Excel и Google Таблицы

Бесплатно, запускается за день. На старте подходит. Но без прослеживаемости правок для аккредитованной лаборатории это накопление рисков: контроль качества держится на внимательности персонала, а не на системе.

### 1С для лаборатории

Знакомый интерфейс, интеграция с бухгалтерией и складом, привычная техническая поддержка. В медицинской и производственной практике такие системы встречаются часто. Модули 1С закрывают базовый учёт материалов и отчётность, но управление лабораторными испытаниями, расчёт неопределённости, генерация протоколов по методикам — всё это приходится дописывать, и доработки такой системы стоят дорого.

### Коробочная ЛИМС

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

### Кастомная разработка

Лабораторно-информационная система строится вокруг реального пути образца и правил конкретной лаборатории. Так работает платформа, которую мы сделали для [СпектроХим](/ru/project/spektrokhim): компания проводит межлабораторные сличительные испытания нефтепродуктов, и раньше администратор вручную сводил сотни файлов из разных лабораторий. Сейчас через систему работают более 250 лабораторий и 600 лаборантов, а подготовка итогового отчёта ускорилась втрое. После закрытия раунда данные замораживаются — изменить их нельзя, что критично для регламентов.

Универсального варианта нет. Выбор системы зависит от масштаба лаборатории и количества нестандартных задач. Подробнее — на странице [решений для химических лабораторий](/ru/solutions/chem-lab) и в разделе [ЛИМС](/ru/solutions/chem-lab/lims).

## Сколько занимает внедрение и что подготовить

Проект проходит цепочку: аудит процессов лаборатории, сбор технических требований, разработка и настройка системы, пробный запуск на одном участке, обучение и масштабирование.

Со стороны заказчика нужно подготовить немногое, но обязательно. Ниже — минимум, без которого внедрение буксует.

- Выделить ответственного. Специалиста, для которого проект — основная задача, а не нагрузка сверху.
- Описать текущие процессы. Путь образцов, учёт материалов и продукции, формы протоколов.
- Собрать требования участников. Лаборанты скажут про формы ввода результатов, служба качества — про сроки годности и соответствие правилам, ИТ — про совместимость системы и защиту персональных данных.
- Определить пробный участок. Один процесс, одна группа методик, одно рабочее место.
- Подготовить команду. Люди боятся не технологий, а неизвестности.

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

## Частые вопросы об автоматизации лаборатории

### С чего начать автоматизацию лаборатории?

Со схемы реального пути образца — не с wishlist «как в той программе, только удобнее». Пока нет карты процессов, любая система внедряется вслепую. На созвоне WAPP фиксирует, что закроет базовый LIMS, а что уйдёт во второй этап.

### Почему сотрудники обходят LIMS?

Интерфейс спорит с перчатками и темпом у прибора. Подробный разбор — в статье [«Почему лаборанты саботируют LIMS»](/ru/blog/why-lab-staff-bypass-lims).

### LIMS и СпектроХим — это одно и то же?

Нет. LIMS ведёт жизненный цикл пробы внутри лаборатории. [СпектроХим](/ru/project/spektrokhim) — платформа межлабораторных проверок квалификации. Одинаковая отрасль, разные задачи.

### Где смотреть хаб решений и условия LIMS?

На странице [химических лабораторий](/ru/solutions/chem-lab) и в разделе [LIMS](/ru/solutions/chem-lab/lims): бесплатный старт для небольших лабораторий, очередь и FAQ.

## Выводы

Автоматизация лаборатории начинается со схемы процессов, а не с выбора платформы. Пока нет ясной картины пути образца, любая система будет внедряться вслепую. Схема занимает пару рабочих дней и экономит месяцы.

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

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

### Что сделать прямо сейчас

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

Нужен разбор процессов или техническое задание на разработку? [Обсудите задачу с командой WAPP](/ru/solutions/chem-lab) — мы проектируем системы под реальные процессы, а не продаём коробку.

---

## Blog: Сколько стоит разработка мобильного приложения: из чего складывается цена и реальные бюджеты

- **Slug:** `mobile-app-development-cost`
- **Locale:** `ru`

Пять коммерческих предложений на одно и то же мобильное приложение. Цены: 200 тысяч, 800 тысяч, 2,5 млн, 4 млн и 8 млн рублей. Каждый подрядчик считает свою смету рыночной. Знакомая история? За восемь лет работы WAPP видел такой разброс десятки раз, и почти всегда главная причина одна: разные компании закладывают в стоимость разработки мобильного приложения разный объём задач. Кто-то считает только код, кто-то включает аналитику и дизайн, а кто-то честно добавляет серверную инфраструктуру, тестирование и поддержку после запуска. Давайте разберём, из чего складывается реальная цена, чтобы при сравнении КП вы сравнивали одинаковое с одинаковым.

## Из чего складывается стоимость разработки мобильного приложения

### Аналитика и проектирование: около 15% бюджета

Разработка мобильного приложения начинается не с кода, а с вопросов. Аналитик собирает требования заказчика, изучает конкурентов, описывает сценарии пользователей и формирует техническое задание. На выходе — ТЗ, карты экранов и прототип. Этот этап занимает от двух до шести недель и составляет около 15% проектного бюджета.

Пропустить аналитику — значит заложить риски: без ТЗ разработчики будут додумывать логику сами, а каждое «мы имели в виду другое» на этапе разработки обойдётся в часы переделок.

Стоимость аналитики зависит от сложности бизнес-логики продукта и числа интеграций с внешними сервисами. Анализ конкурентов и карты пользовательского взаимодействия — обязательные элементы этого этапа, которые помогают сократить сроки дальнейшей разработки. Подробнее о том, как мы превращаем идею в ТЗ, — в [статье про написание технического задания](/ru/blog/specs-we-write-ourselves).

### UI/UX-дизайн: около 20% бюджета

После аналитики команда проектирует интерфейс мобильного приложения. UX-дизайн — это не «сделать красиво». Это продумать, как пользователь перемещается между экранами, где расположить кнопку оплаты, как работает авторизация. В среднем дизайн приложения для iOS и Android забирает около 20% проектного бюджета: сложные анимации или нестандартный интерфейс добавляют десятки часов работы специалистов.

Базовая стоимость UX-дизайна мобильного приложения среднего уровня сложности — от 300 тысяч рублей. Если подрядчик не выделяет дизайн строкой в смете, спросите, входит ли он вообще. Макеты, стиль элементов интерфейса и UI-дизайн экранов — всё это должен содержать полный состав работ. Качественный UX-процесс на основе данных о поведении аудитории напрямую влияет на конверсию готового продукта.

### Разработка приложения: около 50% бюджета

Самая большая часть расходов на создание мобильного приложения — около половины проектного бюджета. Сюда входит фронтенд (то, что видит пользователь на устройстве) и бэкенд (серверная часть, API, базы данных). Стоимость на этом этапе зависит от количества функций, интеграций с внешними сервисами и выбора платформы.

Например, приложение доставки еды с личным кабинетом, чатом поддержки и интеграцией с платёжными системами требует больше часов, чем простое приложение-каталог товаров для интернет-магазина. Разработка мобильного приложения для онлайн-магазина включает программы лояльности, push-уведомления и управление заказами — типовые задачи, которые чаще всего встречаются в коммерческих проектах. Подробнее о подходе к мобильной разработке — на [странице услуги](/ru/services/mobile-development).

### Тестирование и публикация: около 15% бюджета

Тестирование (QA) и подготовка к публикации забирают около 15% проектного бюджета. Публикация в App Store и Google Play — процесс с оплатой аккаунтов разработчиков (Apple берёт $99 в год, Google — $25 единоразово). Вместе с аналитикой, дизайном и разработкой эти четыре доли как раз закрывают 100% проектной сметы.

### Что обычно не входит в базовую смету

Серверная инфраструктура стоит денег каждый месяц. Обновления приложения под новые версии операционных систем нужны минимум дважды в году. Техническая поддержка после релиза — необходимость: без неё приложение быстро теряет пользователей. Доработки, исправление ошибок и адаптация под новые устройства — это запас сверх проектного бюджета (ориентир 15–30%), а не доля внутри полосы «разработка + дизайн». Если в КП нет ни слова про эти расходы, итоговая сумма вырастет уже после запуска.

## Экономика команды: почему софт не бывает «за 300 тысяч»

Разработка мобильного приложения — это аренда квалифицированной команды. В полноценный состав входят дизайнер, iOS- и Android-разработчики (или кроссплатформенный разработчик), бэкенд-специалист, тестировщик и менеджер проекта.

Средняя стоимость месяца работы такой команды — порядка **500 000 рублей**. Сюда входит не только фонд оплаты труда, но и инфраструктура, софт для управления и контроль качества.

Отсюда базовые ориентиры:

- **Минимальный срок:** от 3 месяцев. Быстрее спроектировать, собрать, протестировать и выпустить работающий продукт без потери качества почти невозможно.
- **Минимальный бюджет:** от **1,5 млн рублей**.

Если обещают «аналог Uber» за 300 тысяч, на проекте будут экономить: на качестве кода, безопасности или тестировании. Такой технический долг потом обходится дороже первоначальной «экономии».

## Реальные бюджеты по типам проектов

Вопрос «сколько стоит разработка мобильного приложения» звучит примерно как «сколько стоит построить дом». Без понимания, что именно строить, любые цифры не имеют смысла. Но ориентиры всё же есть — они проверены опытом десятков проектов.

### Простое MVP-приложение

Каталог товаров, визитка компании, простое мобильное приложение с авторизацией и несколькими экранами. Базовый набор функциональности, дизайн без сложных анимаций. Команда из двух-трёх специалистов. Сроки разработки: 2–3 месяца.

Бюджет начинается **от 1,5 млн рублей** — это порог входа, ниже которого сложно получить качественный результат. Создание MVP позволяет проверить идею бизнеса с контролируемыми инвестициями. Подробнее — в [статье про запуск MVP](/ru/blog/razrabotka-mvp-kak-sozdat-minimalno-zhiznesposobnyy-produkt-dlya-startapa).

### Системы управления бизнесом (B2B / CRM)

Ориентировочный бюджет: **2–3 млн рублей**. Инструменты для автоматизации: статусы заказов, заявки, интеграция с внутренней CRM и складскими системами. Такие решения окупаются за счёт сокращения издержек и меньшего числа ошибок ручного ввода.

### Приложение среднего уровня сложности

Сервис доставки, e-commerce с личным кабинетом, системы бронирования. Здесь появляются интеграции с платёжными системами, push-уведомления, чат поддержки, аналитика поведения. Объём работы — от 800 до 2000 рабочих часов. Команда: 4–6 человек. Сроки: 4–7 месяцев. Стоимость — **от 3 до 8 млн рублей** в зависимости от функциональности.

Для логистических решений стоимость зависит от числа ролей и глубины интеграции с сервером. Пример — [система управления флотом SWAPPZ](/ru/project/swappz) для аренды электротранспорта в ОАЭ: пять ролей, MVP за 90 дней. Среднее время в этой категории — около 1200 рабочих часов.

### Сложные платформы, мессенджеры и корпоративные системы

Маркетплейсы, финтех, корпоративная связь, продукты с передачей данных в реальном времени и высокими нагрузками. Пример — [корпоративная система Push-to-Talk](/ru/project/mts-ptt) с интеграцией SIP, RTP и FreeSwitch.

Ориентир бюджета: **от 5–6 млн рублей**, крупные системы часто выходят заметно выше. Срок — от 8–14 месяцев, команда — от 6 до 12 специалистов. Такие проекты требуют отраслевого опыта и проектирования под нагрузку.

## Почему оценка «с прошлого КП» уже не работает

С 2023 года рынок мобильной разработки в России ощутимо подорожал. Зарплаты разработчиков выросли на 25–40% — это видно по вакансиям. Вместе с рынком растут ставки и стоимость инфраструктуры.

Смету двухлетней давности нельзя брать за ориентир. Точную оценку дают только после ТЗ, разбора конкурентов и списка функций. Без ТЗ любой бюджет — оценка «на глаз».

## Стоимость разработки для iOS и Android: нативный или кроссплатформенный подход

Вот вопрос, который напрямую влияет на стоимость разработки мобильного приложения для iOS и Android: писать два приложения или обойтись одним проектом под обе операционные системы? Разница в бюджете может составлять 40–60%, и выбор здесь зависит не от технологии, а от конкретных задач бизнеса.

### Нативная разработка: два приложения вместо одного

Нативная разработка мобильного приложения означает, что команда пишет код для каждой платформы. Для iOS используют Swift, для Android — Kotlin. Два языка программирования, два набора инструментов, часто два разработчика. По сути, заказчик оплачивает создание двух разных продуктов с общей логикой и дизайном.

Когда это оправдано? Если мобильное приложение работает с «железом» телефона на уровне, где кроссплатформенные решения дают сбои: обработка видео в реальном времени, интеграция с платёжными системами на уровне SDK, функции дополненной реальности. Финтех, медицинские сервисы, корпоративные приложения связи — здесь нативный подход обычно единственный вариант. Показательна задача такого класса — [рефакторинг платёжного SDK для Beeline](/ru/project/beeline-kazakhstan) на SwiftUI: работа с платёжной библиотекой на уровне нативного кода.

Стоимость нативных мобильных приложений выше, но и качество готового продукта отличается. Разработка нативных приложений под две платформы обходится примерно в 1,5–1,8 раза дороже, чем кроссплатформенный проект. Расходы на поддержку тоже растут: каждое обновление нужно делать дважды, тестирование проходит для каждой версии приложения. Многие стартапы на первом этапе выбирают одну платформу, чтобы сократить затраты.

### Кроссплатформенная разработка: один код — две платформы

Кроссплатформенная разработка мобильного приложения с помощью [React Native](/ru/services/react-native) или Flutter позволяет написать один код и собрать приложения для App Store и Google Play. Общая кодовая база сокращает объём работы разработчиков на 30–50% по сравнению с нативным путём.

Кроссплатформенный подход подходит для MVP, e-commerce приложений, каталогов товаров, сервисов доставки, контентных и информационных приложений — там, где интерфейс типовой, а бизнес-логика живёт на серверной части. Если целевой аудитории нужен личный кабинет, уведомления, чат поддержки и интеграция с CRM — кроссплатформенная разработка приложения дешевле и быстрее. Этот способ выбирают большинство стартапов и компаний среднего уровня.

Но есть нюанс. Некоторые функции — биометрическая авторизация на устройствах, сложные пользовательские анимации, глубокая работа с Bluetooth — иногда требуют написания нативных модулей внутри кроссплатформенного проекта. Это добавляет часов к смете.

### А что насчёт no-code и веб-приложений?

No-code и low-code платформы позволяют собрать простое приложение за несколько дней без единой строчки кода. Бюджет — минимальный. Но важно понимать: масштабирование, нагрузки больше пары тысяч пользователей, нестандартный дизайн, интеграция с внешними API — всё это быстро упирается в ограниченные возможности платформы. No-code подходит для проверки идеи, но строить на нём реальный бизнес-продукт не стоит.

## Почему дешёвая разработка обходится дороже и когда мобильное приложение не нужно

### Когда клиент платит дважды

Предложение разработать мобильное приложение за 100–200 тысяч рублей выглядит привлекательно. Но за восемь лет работы с проектами разной сложности мы видели десятки случаев, когда такая экономия приводила к удвоению расходов. Схема одинаковая: фрилансер берёт заказ, собирает приложение на шаблонных решениях без тестирования, сдаёт результат. Через несколько месяцев код начинает деградировать, а новые функции добавить невозможно — архитектура не продумана. Клиент приходит в студию с просьбой доработать, а получает ответ: дешевле создать мобильное приложение с нуля. Как это выглядит на практике, видно в [кейсе Glinka Digital](/ru/project/glinka-digital), где над продуктом пришлось работать заново после двух предыдущих подрядчиков.

Вот что конкретно идёт не так при заниженном бюджете разработки мобильного приложения:

- Тестирование отсутствует или ограничено проверкой «у меня на телефоне работает»
- Код написан без документации — другие разработчики не могут в нём разобраться
- Серверная часть не рассчитана на рост нагрузки выше сотни пользователей
- Безопасность, защита и хранение персональных данных пользователей не обеспечены
- Интеграции с внешними сервисами сделаны некачественно и ломаются при обновлениях API

В итоге стоимость мобильного приложения в таком сценарии оказывается на 40–60% выше, чем если бы проект делала нормальная команда. Стандартная практика — сразу заказать разработку у проверенной команды.

### Фрилансер, студия или инхаус

Выбор модели работы влияет и на цену, и на качество результата. Фрилансер обойдётся дешевле всех: ставка ниже. Но один человек не закроет аналитику, дизайн, бэкенд и тестирование одновременно. Сроки разработки приложения плывут, а ответственность не зафиксирована.

Студия стоит дороже, зато за проектом стоит выстроенный процесс: менеджер, специалисты по UX/UI, разработчики мобильных приложений, QA-инженеры. Инхаус-команда — самый дорогой вариант на старте: поиск сотрудников, зарплаты, инфраструктура. Но если у компании несколько продуктов и вы планируете развитие на годы, собственный отдел разработки мобильных приложений окупается быстрее. Каждая модель отвечает разным целям бизнеса.

### Когда мобильное приложение вообще не нужно

Честный вопрос: а нужно ли вам мобильное приложение? Если целевой аудитории хватит адаптивного сайта с личным кабинетом, создание приложения для iOS и Android — лишние затраты. Для сервиса доставки с небольшим объёмом заказов хватит Telegram-бота. Для корпоративного каталога товаров подойдёт PWA — прогрессивное веб-приложение, которое выглядит как нативное.

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

## Как мы считаем деньги: от «вилки» до Fix Price

Финальную цену на первом созвоне не называют — это было бы гаданием. В WAPP оценка идёт этапами, которые страхуют бюджет:

1. **Брифинг и эстимация.** За **2–3 рабочих дня** даём предварительную «вилку» (диапазон «от и до») и обязуемся не выходить за верхний порог при сохранении текущих требований.
2. **Техническое задание.** Архитектура, логика экранов, схемы данных — документ, по которому можно сравнивать подрядчиков.
3. **Fix Price.** Только после согласования ТЗ фиксируем цену в договоре: она не меняется в процессе, пока не меняется объём.

Прозрачность процесса — через трекер **Plane**: клиент видит задачи, спринты и прогресс без «чёрного ящика». Предварительная оценка для заказчика бесплатна.

## Как спланировать бюджет и выбрать подрядчика: практические рекомендации

Вы отправили запросы в пять компаний и получили цены от 300 тысяч до 9 млн рублей. Кто из них прав? Скорее всего, все. Каждый заложил разный объём работ, разные сроки и разный уровень качества. Вопрос не в том, сколько стоит разработка мобильного приложения «вообще», а в том, за что конкретно вы платите.

### Как сравнивать коммерческие предложения

Главная ошибка заказчика — смотреть на итоговую сумму. Одна компания включает в стоимость разработки мобильного приложения аналитику, UX-проектирование, тестирование, публикацию в сторах, два месяца поддержки после релиза. Другая пишет только «разработка приложения» и цену ниже вдвое. Но потом выясняется, что дизайн приложения, серверная часть и исправление ошибок — дополнительные услуги.

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

### Вопросы, которые стоит задать до подписания договора

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

1. Что входит в стоимость, а что оплачивается как дополнительные статьи расходов? Например, входит ли создание бэкенда или подключение сторонних сервисов.
2. Кому принадлежит исходный код готового мобильного приложения? Политика некоторых студий — сохранять права на код. В случае разрыва отношений клиент остаётся без продукта.
3. Сколько часов заложено на тестирование и исправление багов? Если в ТЗ не указан объём — результат будет поверхностным.
4. Как устроена поддержка после запуска? Обновления операционных систем iOS и Android выходят каждый год. Политика конфиденциальности и безопасность персональных данных тоже требуют регулярных изменений и настройки.
5. Есть ли в портфолио кейсы, похожие на ваш проект разработки? Опыт команды в вашей нише важнее общего количества проектов. Пример нишевого решения — [приложения для химических лабораторий](/ru/project/spektrokhim).
6. Какая модель оплаты: фиксированная цена или Time & Material? Условия каждого варианта подходят для разных задач.
7. Кто будет вести проект: выделенный менеджер или разработчики? Управление проектом разработки — функция, которая должна быть закреплена за конкретным сотрудником.

### Запас на непредвиденное

Заложите 20–30% бюджета сверх согласованной суммы на разработку мобильного приложения. Это реальная практика. Техническое задание не покрывает всех ситуаций: появляются новые требования от пользователей, меняются API сторонних сервисов, Apple обновляет правила публикации. Без финансового запаса любые изменения превращаются в остановку проекта.

Если планируете запуск, закладывайте расходы на маркетинг и продвижение после релиза. Само по себе приложение в сторах не соберёт аудиторию — нужны инвестиции в каналы и работу с отзывами. Разработка — только часть пути.

## Частые вопросы о стоимости мобильной разработки

### Сколько минимум стоит качественное мобильное приложение?

Ориентир входа — **от 1,5 млн рублей** при сроке от трёх месяцев. Ниже этой планки обычно режут тестирование, архитектуру или безопасность — и потом платят за переделку.

### Почему нельзя назвать точную цену на первом созвоне?

Без карты функций и интеграций любая цифра — гадание. За 2–3 рабочих дня можно дать вилку; финальный Fix Price появляется после согласованного ТЗ.

### Fix Price или Time & Materials?

Fix Price подходит, когда объём зафиксирован в ТЗ. Time & Materials — когда требования ещё плывут. В WAPP к фиксированной цене переходят после ТЗ, чтобы бюджет не «поплыл» на середине спринта.

### Натив или кроссплатформа — что дешевле?

Для большинства сервисных и корпоративных продуктов кроссплатформа ([React Native](/ru/services/react-native) / Flutter) дешевле и быстрее. Натив оправдан при тяжёлой работе с железом, спецSDK и высокой нагрузке на UI.

### Где смотреть услугу и оставить заявку?

На странице [мобильной разработки](/ru/services/mobile-development) или через [контакты](/ru#contact). Предварительная оценка не обязывает к договору.

---

Хотите получить точную оценку стоимости разработки мобильного приложения? Расскажите о проекте — цели, функционал и аудиторию. [Оставьте заявку на странице мобильной разработки](/ru/services/mobile-development) или [свяжитесь через контакты](/ru#contact) — разберём задачу, дадим смету по этапам и покажем, с чего лучше начинать.

---

## Blog: How much does mobile app development cost: what drives the price and real budgets

- **Slug:** `mobile-app-development-cost`
- **Locale:** `en`

Five commercial proposals for the same mobile app. Prices: RUB 200K, 800K, 2.5M, 4M, and 8M. Every vendor calls their estimate “market rate.” Sound familiar? In eight years, WAPP has seen this spread dozens of times — and the main reason is almost always the same: each company includes a different scope in the cost of mobile app development. Some quote code only; others add analytics and design; others honestly include server infrastructure, testing, and post-launch support. Here is what actually drives the price, so when you compare proposals you compare like with like.

## What makes up the cost of mobile app development

### Analytics and discovery: about 15% of budget

Mobile app development does not start with code — it starts with questions. An analyst gathers requirements, studies competitors, maps user scenarios, and produces a technical specification. The output is a spec, screen maps, and a prototype. This stage takes two to six weeks and is about 15% of the project budget.

Skipping analytics means baking in risk: without a spec, developers fill gaps themselves, and every “that’s not what we meant” during build costs hours of rework.

Analytics cost depends on business logic complexity and the number of third-party integrations. Competitor analysis and user journey maps are mandatory parts of this stage and shorten later development. More on how we turn an idea into a spec — in [our article on writing technical specifications](/en/blog/specs-we-write-ourselves).

### UI/UX design: about 20% of budget

After analytics, the team designs the mobile app interface. UX design is not “make it pretty.” It is about how users move between screens, where the pay button sits, how sign-in works. On average, iOS and Android app design takes about 20% of the project budget: complex animations or custom UI add dozens of specialist hours.

Baseline UX design for a mid-complexity mobile app starts around RUB 300K. If a vendor does not list design as a line item, ask whether it is included at all. Mockups, UI patterns, and screen design should all be in scope. A solid UX process based on audience behavior directly affects conversion of the finished product.

### Development: about 50% of budget

The largest share of spend on building a mobile app — about half the project budget. This covers the frontend (what users see on device) and backend (server, API, databases). Cost at this stage depends on feature count, integrations, and platform choice.

A food delivery app with a personal account, support chat, and payment integrations needs more hours than a simple product catalogue for an online store. E-commerce mobile apps typically include loyalty programs, push notifications, and order management — common tasks in commercial projects. More on our mobile development approach — on the [service page](/en/services/mobile-development).

### Testing and store release: about 15% of budget

QA and store-ready packaging take about 15% of the project budget. Publishing to the App Store and Google Play requires developer accounts (Apple: $99/year; Google: $25 one-time). Together with analytics, design, and development, these four shares make up 100% of the project quote.

### What usually sits outside the base quote

Server infrastructure costs money every month. OS updates require app updates at least twice a year. Post-launch support is not optional — without it, apps lose users quickly. Enhancements, bug fixes, and new device support are a contingency on top of the project budget (roughly 15–30%), not a slice inside the delivery bar. If a proposal says nothing about these items, the total will grow after launch.

## Team economics: why software is never “RUB 300K”

Building a mobile app means renting a skilled team: designer, iOS/Android (or cross-platform) engineers, backend, QA, and a project manager.

A full team month costs about **RUB 500,000** — payroll plus tools, infrastructure, and quality control.

Base market floors:

- **Minimum timeline:** from 3 months. Faster without cutting quality is rare.
- **Minimum budget:** from **RUB 1.5M**.

If someone promises an “Uber clone” for RUB 300K, they will cut code quality, security, or testing — and you pay for the debt later.

## Real budgets by project type

“How much does mobile app development cost?” is a bit like “how much does a house cost?” Without scope, any number is noise. Still, benchmarks exist — validated across dozens of projects.

### Simple MVP app

Product catalogue, company profile, auth and a handful of screens. Basic features, no heavy animation. Team of two or three. Timeline: 2–3 months.

Budget starts at **RUB 1.5M** — below that, quality rarely holds. An MVP validates the idea with controlled spend. More in [our MVP launch article](/en/blog/razrabotka-mvp-kak-sozdat-minimalno-zhiznesposobnyy-produkt-dlya-startapa).

### Business systems (B2B / CRM)

Rough budget: **RUB 2–3M**. Order statuses, requests, CRM and warehouse integrations. Payoff comes from fewer manual errors and lower operating cost.

### Mid-complexity app

Delivery, e-commerce with accounts, booking. Payments, push, support chat, analytics. Scope: 800–2,000 hours. Team: 4–6. Timeline: 4–7 months. Cost: **RUB 3–8M** depending on scope.

For logistics, cost tracks roles and server depth. Reference: [SWAPPZ fleet system](/en/project/swappz) in the UAE — five roles, MVP in 90 days. Average build time in this band: ~1,200 hours.

### Complex platforms, messengers, and enterprise systems

Marketplaces, fintech, corporate comms, real-time and high-load products. Example: [Push-to-Talk](/en/project/mts-ptt) with SIP, RTP, and FreeSwitch.

Budget floor: **from RUB 5–6M**; large systems go higher. Timeline: 8–14 months; team: 6–12. Domain experience and load design are mandatory.

## Why last year’s quote is not a plan

Since 2023, mobile development in Russia has gotten more expensive. Developer salaries rose 25–40%. Rates and infrastructure followed.

A two-year-old quote is not a benchmark. Accurate cost needs a spec, competitor review, and feature list. Without a spec, every budget is a guess.

## iOS and Android cost: native vs cross-platform

A question that directly affects mobile app cost for iOS and Android: two apps or one codebase for both? Budget difference can be 40–60%, and the right choice depends on business tasks, not technology fashion.

### Native development: two apps instead of one

Native mobile development means separate code per platform. iOS: Swift; Android: Kotlin. Two languages, two toolchains, often two developers. In practice, you pay for two products with shared logic and design.

When is it justified? When the app touches device hardware where cross-platform stacks struggle: real-time video, payment SDK-level integration, AR. Fintech, medical services, corporate comms — native is often the only viable path. A case in point: [Beeline payment SDK refactor](/en/project/beeline-kazakhstan) on SwiftUI — payment library work at native code level.

Native apps cost more, and the finished product behaves differently. Two-platform native delivery runs about 1.5–1.8× a cross-platform project. Support costs rise too: every update ships twice; testing runs per platform. Many startups pick one platform first to reduce spend.

### Cross-platform: one codebase — two stores

Cross-platform mobile development with [React Native](/en/services/react-native) or Flutter means one codebase for App Store and Google Play. Shared code cuts engineering effort 30–50% vs native.

Cross-platform fits MVPs, e-commerce, catalogues, delivery, content apps — typical UI, business logic on the server. If the audience needs accounts, notifications, support chat, and CRM integration, cross-platform is cheaper and faster. Most startups and mid-size companies choose this path.

There is a caveat. Biometrics, complex custom animation, deep Bluetooth work sometimes need native modules inside a cross-platform project — extra hours on the estimate.

### What about no-code and web apps?

No-code and low-code can ship a simple app in days with minimal budget. But scaling, loads beyond a few thousand users, custom design, and external API integration hit platform limits quickly. No-code is fine for idea validation; building a real business product on it usually fails.

## Why cheap development costs more — and when you do not need an app

### When the client pays twice

A RUB 100–200K mobile app quote looks attractive. Over eight years we have seen dozens of cases where that “saving” doubled total spend. Same pattern: a freelancer builds on templates without proper testing and hands off. Months later the code degrades; new features cannot be added — architecture was never designed for growth. The client asks a studio to “fix it” and hears: cheaper to rebuild from scratch. See [Glinka Digital](/en/project/glinka-digital), where the product had to be rebuilt after two prior vendors.

What typically goes wrong on an underpriced mobile app:

- No QA — or only “works on my phone”
- Undocumented code — no one else can maintain it
- Backend not sized beyond ~100 users
- Security and personal data handling not engineered
- Integrations brittle and breaking on API updates

Total cost in that scenario often runs 40–60% above a proper team from day one. Standard practice: engage a verified team upfront.

### Freelancer, agency, or in-house

The engagement model affects price and outcome. Freelancers cost least per hour but one person rarely covers analytics, design, backend, and QA. Timelines slip; accountability is unclear.

Agencies cost more but bring process: PM, UX/UI, mobile developers, QA. In-house is the most expensive start — hiring, payroll, infrastructure. With multiple products and a multi-year roadmap, an internal mobile team can pay off faster. Each model serves different business goals.

### When you do not need a mobile app at all

Honest question: do you need a mobile app? If a responsive site with a personal account is enough, iOS and Android apps are extra spend. A small delivery service may only need a Telegram bot. A corporate catalogue may work as a PWA.

A mobile app pays off when offline access, heavy animation, camera/sensor integration, or high-performance data processing matter. Otherwise, validate with a simpler channel first and preserve budget.

## How we price: from a range to Fix Price

We do not quote a final number on the first call — that would be guessing. WAPP stages the estimate so the budget stays protected:

1. **Brief and estimate.** In **2–3 business days** you get a range (“from–to”); we commit not to exceed the top end if requirements stay the same.
2. **Technical specification.** Architecture, screens, data model — a document you can use to compare vendors.
3. **Fix Price.** After the spec is approved, price is locked in the contract until scope changes.

Delivery stays visible in **Plane**: tasks, sprints, and progress without a black box. The preliminary estimate is free.

## How to plan budget and choose a vendor

You emailed five companies and got quotes from RUB 300K to 9M. Who is “right”? Probably all of them — each scoped differently, with different timelines and quality bars. The question is not “what does mobile development cost in general” but what you are paying for.

### How to compare proposals

The classic mistake: comparing totals only. One vendor includes analytics, UX, QA, store submission, two months post-launch support. Another lists “app development” at half the price — then design, backend, and bug fixes are extras.

Compare scope, not price. Ask for a stage breakdown: analytics, mobile UI design, development, testing, launch, support. That reveals real development cost vs hidden lines. Check legal terms: who owns the code, what are delivery commitments.

### Questions to ask before signing

Before choosing a mobile development vendor, ask directly:

1. What is included vs billed separately? e.g. backend build, third-party integrations.
2. Who owns source code? Some studios retain rights — you can lose the product if the relationship ends.
3. How many QA and bug-fix hours are in scope? Without a number in the spec, quality stays shallow.
4. What does post-launch support look like? iOS and Android update yearly; privacy and security need ongoing work.
5. Are there similar cases in the portfolio? Niche experience beats project count. Example: [lab software](/en/project/spektrokhim).
6. Fixed price or time & materials? Each suits different situations.
7. Who runs the project — dedicated PM or developers ad hoc? Someone must own delivery.

### Contingency buffer

Plan 20–30% above the agreed mobile app budget. Specs never cover everything: new user requirements, third-party API changes, Apple policy updates. Without buffer, change requests stall the project.

Budget marketing after release. Apps do not acquire users by themselves — channels and review management need investment. Development is one leg of the journey; promotion follows.

## Frequently asked questions about mobile app cost

### What is the minimum for a quality mobile app?

Entry floor: **from RUB 1.5M** with at least three months. Below that, teams usually cut QA, architecture, or security — and you pay for a rebuild later.

### Why no exact price on the first call?

Without a feature and integration map, any number is a guess. In 2–3 business days we can give a range; Fix Price comes after an approved spec.

### Fix Price or time & materials?

Fix Price fits a locked spec. Time & materials fits moving requirements. WAPP locks Fix Price after the spec so the budget does not drift mid-sprint.

### Native or cross-platform — which is cheaper?

For most service and corporate products, cross-platform ([React Native](/en/services/react-native) / Flutter) is cheaper and faster. Native fits deep hardware work, special SDKs, and heavy UI.

### Where to request a quote?

On the [mobile development page](/en/services/mobile-development) or via [contacts](/en#contact). A preliminary estimate does not create an obligation.

---

Want a precise estimate for your mobile app? Describe goals, features, and audience. [Request a quote on our mobile development page](/en/services/mobile-development) or [get in touch](/en#contact) — we will map the task, break down a stage-by-stage estimate, and suggest where to start.

---

## Blog: Основные изменения в сфере UI/UX дизайна и их влияние на индустрию

- **Slug:** `osnovnye-izmeneniya-v-sfere-ui-ux-dizayna-i-ih-vliyanie-na-industriyu`
- **Locale:** `ru`

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

## Упростить работу через фокус на задачах пользователя

Современный дизайн убирает лишние дистракторы, чтобы человек мог сосредоточиться на главном. Мы называем это иммерсивным подходом: интерфейс «растворяется» и не мешает выполнять целевое действие.

Допустим, Виталий заказал разработку системы для управления складом. Дизайнеры добавили туда модные градиенты и неоновые тени, но забыли про контекст. В итоге на складе при тусклом освещении Виталий просто не видит границы полей ввода на экране терминала. Попытка сделать «красиво» вместо «удобно» оборачивается замедлением приемки товара на 20%.

Чтобы избежать таких сценариев, WAPP использует метод погружения в процессы:
* В проекте СпектроХим аналитики две недели наблюдали за движениями лаборантов у центрифуги.
* Мы выяснили, что в толстых перчатках невозможно попасть по мелким элементам, и увеличили зоны клика в 3 раза.
* Система сама скрывает лишние вкладки, когда идет процесс замера, чтобы химик не отвлекался на уведомления.

## Обеспечить бесшовный опыт на любых устройствах

Адаптивность в 2024 году — это не просто корректное отображение сайта на телефоне, а гарантия того, что ваш клиент завершит оплату или заказ в любых условиях. Разрыв в пользовательском опыте между десктопом и мобильной версией ведет к потере лидов.

В кейсе логистической платформы Fiftyfour мы разделили интерфейсы под разные задачи. Диспетчер видит огромную карту со всеми бортами, а водитель на трассе — только две крупные кнопки статуса рейса. Это позволяет не перегружать мозг сотрудника лишней информацией.

## Внедрить микроинтеракции для снижения когнитивной нагрузки

Маленькие анимации и визуальные отклики системы — это не украшение, а способ мгновенной обратной связи. Микроинтеракции подтверждают успешность действия и снимают тревогу пользователя, когда процесс занимает время.

Ранее в проекте Maller мы допустили ошибку в архитектуре, из-за чего сложные вычисления на стороне фронтенда подтормаживали интерфейс. Этот опыт научил нас использовать визуальные индикаторы прогресса:
* Когда вы нажимаете кнопку «Оплатить» в платежной платформе Xstreet, система мгновенно меняет состояние кнопки, даже если банк-эквайер отвечает долго.
* Плавная анимация загрузки сообщает, что процесс идет, и пользователь не пытается нажать на кнопку еще десять раз.
* Микро-отклики в полях ввода показывают ошибку в номере карты сразу, не дожидаясь общей отправки формы.

## Сделать интерфейс доступным для всех групп пользователей

Инклюзивность в дизайне — это способ расширить аудиторию и показать заботу бренда о людям. Мы проектируем системы так, чтобы ими могли пользоваться люди с разными физическими или когнитивными особенностями.

Допустим, ваш лендинг приносит конверсию в 15%, но часть клиентов не может прочитать текст из-за низкой контрастности или отсутствия поддержки экранных дикторов. Вы сознательно отсекаете сегмент платежеспособных пользователей.

В WAPP мы придерживаемся стандартов доступности:
* Адаптивные шрифты позволяют изменять размер текста без потери верстки.
* Цветовые схемы подбираются так, чтобы элементы были различимы даже при ярком солнечном свете.
* Навигация с клавиатуры и голосовые подсказки дублируют основные функции управления.

## Интегрировать дополненную реальность в бизнес-процессы

AR-технологии перестали быть развлечением и начали приносить практическую пользу. Это мост между физическим оборудованием и цифровыми данными.

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

Голосовые интерфейсы дополняют этот опыт, позволяя управлять системой, когда руки заняты работой с реактивами или грузами. Развитие ИИ делает распознавание речи точным, превращая голос в надежный инструмент ввода данных.

## Заключение

UI/UX дизайн в 2024 году направлен на одну цель: сделать взаимодействие с технологиями естественным и понятным. Если интерфейс бережет время вашего сотрудника или помогает клиенту Xstreet быстрее провести платеж, значит, дизайн приносит деньги.

WAPP создает продукты, в которых за каждым пикселем стоит логика бизнеса. Мы не просто рисуем макеты — мы проектируем сценарии успеха для вашего продукта.

---

## Blog: Своя платформа для онлайн-школы или готовый сервис: что выбрать и сколько стоит

- **Slug:** `platforma-dlya-onlayn-shkoly`
- **Locale:** `ru`

## Кому и зачем нужна своя платформа для онлайн-уроков

Разработка собственной платформы для онлайн-уроков стоит от 1,5 млн ₽ и занимает от трёх месяцев. Подписка на готовый сервис — от 3 000 рублей в месяц, регистрация за 14 дней, и можно сразу проводить занятия. Кажется, выбор очевиден? Но через год-два ситуация часто переворачивается: комиссии растут, ученики упираются в чужой интерфейс, а преподаватель не может создать урок в нужном ему формате. И вот уже «бесплатный тариф» обходится дороже, чем собственное приложение.

Студия WAPP разрабатывает EdTech-продукты для компании и организации разного масштаба и видит обе стороны этого выбора. На [странице решений для онлайн-образования](/ru/solutions/edtech) собраны проекты разного масштаба: от индивидуальных уроков музыки до платформ для университетов. Этот опыт даёт понятным язык для разговора о том, когда готовые инструменты закрывают все задачи, а когда становятся тормозом.

### Три сценария — три разных ответа

Универсального решения не существует. Но есть чёткие критерии, которые помогают выбрать быстро.

**Первый сценарий — преподаватель на старте.** Репетитор по английскому языку с 30 учениками. Ему нужен личный кабинет, расписание, возможность давать домашние задания, чат и видеосвязь. Конструктор курсов на готовой образовательной платформе типа GetCourse или Антитренингов закроет необходимое. Тратить время и деньги на разработку здесь бессмысленно: база учеников маленькая, процесс обучения стандартный, учебные материалы — видео, текст, файлы — укладываются в шаблоны. Можно попробовать бесплатно и работать так год или два без ограничений.

**Второй сценарий — онлайн-школа, которая выросла.** 500 учеников, несколько курсов, группы разных уровней. Тарифы готовых сервисов на таком количестве пользователей начинают кусаться. Комиссия с каждой оплаты, невозможность создавать интерактивные задания своей логики, отсутствие доступа к данным учащихся для аналитики, чужой сайт вместо собственного бренда. Школа тратит время на обходные решения и теряет контакты студентов при каждом обновлении платформы. Здесь уже стоит считать: иногда дополнительные расходы на подписку за год превышают стоимость создания собственной системы.

**Третий сценарий — крупная школа или учебный центр.** 2 000+ учеников, вебинары, запись уроков, приём платежей, интеграция с CRM, мобильное приложение, встроенный чат между преподавателями и студентами, сложная программа обучения с ветвлением. Готовые решения на этом масштабе работать могут, но каждая новая функция — это костыль. Своя платформа для онлайн-занятий здесь окупается, потому что даёт полный доступ к данным, снимает любые ограничения и позволяет строить продукт под задачи бизнеса, а не подстраивать бизнес под чужой интерфейс.

### Для кого этот материал

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

## Когда GetCourse и готовых сервисов достаточно

Честно: если у преподавателя 30–80 учеников и один-два онлайн-курса, тратить время на выбором между фреймворками и базами данных — пустая история. Готовый сервис закроет все задачи быстрее и дешевле. Вот конкретные ситуации, когда собственная разработка не нужна вообще.

### Преподаватель на старте: скорость важнее идеала

Допустим, репетитор по английскому языку решил масштабироваться. Раньше вёл индивидуальные занятия по Zoom, теперь хочет создать записанный курс и продавать доступ. Учеников пока несколько десятков, оборот скромный. Первый порыв — сделать «свою платформу, чтобы всё было по-взрослому». Не надо.

GetCourse, Антитренинги, Stepik, Teachable — любая из этих образовательных платформ позволяет за два-три дня собрать личный кабинет для учащихся, загрузить видео, прикрепить файлы с учебными материалами, настроить домашние задания и подключить приём оплаты. Конструктор уроков понятным интерфейсом проведёт через каждый шаг. Регистрации хватит, чтобы начать работать в тот же день.

Тарифы стартуют от 3 000–5 000 рублей в месяц. За эти деньги — встроенный чат с учениками, система тестов, запись вебинаров, база контактов студентов. Некоторые платформы дают бесплатный тариф или пробный период на 14 дней, чтобы попробовать инструменты без вложений. На Stepik, например, можно бесплатно разместить онлайн-курс и набрать первую группы пользователей.

36 000–60 000 рублей в год за готовое решение против минимум 1,5 млн рублей и трёх месяцев на разработку. Арифметика очевидна.

### Типовой формат обучения — типовая платформа

Онлайн-школа, которая работает по классической схеме: записанные уроки, проверка домашних заданий, обратная связь от преподавателя, иногда вебинары. Количество учеников — до сотни. Формат контента — видео, текст, презентации, тесты. Никаких интерактивных симуляций, разветвлённых программ обучения или сложной аналитики.

Для таких задач готовые сервисы подходят идеально. GetCourse закрывает воронку продаж и проведения онлайн-уроков одним приложением. Антитренинги дают простой интерфейс для создания курсов без лишних функций. Teachable удобен, если школа работает на англоязычную аудиторию. Каждого из этих решений хватит на годы вперёд — пока школа не дорастёт до масштаба, где ограничения платформы станут ощутимы.

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

А вот когда количество учеников переваливает за сотню и появляются нетиповые сценарии — тогда разговор о собственной платформе становится предметным. Об этом дальше.

## Что реально ограничивает в готовых платформах

Первое ограничение, с которым сталкивается растущая онлайн-школа, обычно денежное — но важно не перепутать эквайринг с наценкой платформы. Комиссия Get Модуля (GetCourse Pay) — это плата за приём платежей: по срезу на 2026 год около 3,5% по картам РФ, СБП и Pay-сервисам и около 10% по зарубежным картам. Тарифы пересматриваются, поэтому перед расчётом стоит сверить актуальные условия. Это не «наценка GetCourse сверх эквайринга», а сам эквайринг внутри экосистемы.

Настоящая ловушка масштаба — другая. Тариф GetCourse считается не от активных учеников, а от всей накопленной базы контактов. По срезу на 2026 год ступени начинаются примерно с 4 400–5 900 ₽ в месяц и на верхних тарифах доходят до порядка 145 000 ₽ в месяц — школа платит и за тех, кто давно не учится. База растёт с каждой воронкой и рекламной кампанией, а с ней растёт и ежемесячный счёт. Плюс ценовая политика может измениться: ступени поднимут, условия ужесточат, а ученики, материалы и история платежей остаются внутри сервиса.

### Чужой домен, чужой бренд

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

### Логика уроков и механики занятий

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

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

### Данные учеников заперты

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

### Когда ограничения становятся критичными

Граница проходит не по количеству учеников, а по сложности задач. Если онлайн-школа масштабируется и хочет создавать уникальный образовательный продукт — с чатом поддержки внутри урока, с нелинейной подготовкой материалов, с собственным мобильным приложением — выбором остаётся либо мириться, либо строить своё. Первый путь дешевле на дистанции в несколько дней, второй — на дистанции в два года. И здесь начинается разговор о том, из чего состоит собственная платформа для дистанционного обучения и сколько это стоит.

## Из чего состоит своя платформа для онлайн-школы

Своя платформа для онлайн-школы — это не один монолитный сервис, а набор модулей. Каждый решает конкретную задачу. И собирать их можно постепенно: сначала то, без чего вообще не запуститься, потом — всё остальное.

Разберём, из каких блоков состоит образовательная платформа и что каждый из них делает.

### Кабинеты ролей

Первый и самый очевидный модуль. У каждого пользователя свой интерфейс:

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

Разделение ролей звучит просто, но на готовых сервисах гибко настроить его почти невозможно. Если у онлайн-школы несколько филиалов, каждому нужны свои администраторы с ограниченным доступом. Пример такого решения — [платформа для школы волейбола с филиалами](/ru/project/future-volleyball-school), где у каждого отделения свои кураторы и своё расписание.

### Расписание и календарь

Для онлайн-уроков и занятий в реальном времени расписание — критичный инструмент. Ученик бронирует слот, преподаватель подтверждает, система отправляет напоминания. Если школа проводит индивидуальные уроки (английский язык, музыка), нужна запись на конкретное время с учётом часовых поясов. Для групповых онлайн-занятий — другая логика: лимит мест, лист ожидания, автоматическая отмена при недоборе.

### Доставка контента

Это ядро любой образовательной платформы: видео, текст, тесты, файлы, презентации, домашние задания. Конструктор уроков позволяет преподавателю собирать материалы в нужном порядке без помощи программиста. Для проведения онлайн-курсов с нелинейной программой (когда следующий урок зависит от результатов тестов) нужна встроенная система проверки знаний. Именно так устроена [платформа для онлайн-уроков музыки Glinka Digital](/ru/project/glinka-digital): интерактивные задания, быстрый доступ к записи урока, подготовка материалов под каждого учащегося.

### Оплата и подписки

Приём платежей, управление тарифами, автопродление подписок, возвраты. Эквайринг платится в любом случае — и на готовом сервисе, и на своей платформе. По срезу на 2026 год базовая ставка ЮKassa по картам начинается примерно от 2,8%, СБП — порядка 0,4–0,7%; у Get Модуля по картам РФ, СБП и Pay-сервисам — около 3,5%. Разница около 0,7 п. п. сама по себе разработку модуля оплаты не окупает, а ЮKassa можно подключить и внутри GetCourse. Тарифы эквайеров пересматриваются — цифры ниже стоит перепроверить перед решением.

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

### Аналитика и отчёты

Сколько учеников завершили курс? На каком уроке чаще всего бросают? Какой преподаватель получает лучшие оценки? Эти инструменты помогают принимать решения на основе данных, а не интуиции. На готовых сервисах аналитика ограничена несколькими стандартными отчётами. Своя платформа позволяет создавать любые срезы — вплоть до количества дней между регистрацией и первой оплатой.

### Необязательно строить всё сразу

Главное, что стоит понять: это не монолит. Можно начать с кабинетов, расписания и доставки контента, а чат, мобильное приложение и продвинутую аналитику добавить через несколько месяцев. Такой подход сокращает первоначальный бюджет и время до запуска — реально выбрать необходимое и запуститься за 60–90 дней, а не ждать полгода.

## Видеосвязь для онлайн-уроков: почему это отдельная сложная задача

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

### Почему обычный видеочат не подходит для онлайн-занятий

Первый враг — качество звука. Для рабочего созвона сжатие аудио до 32 кбит/с терпимо: голос разборчив, собеседники понимают друг друга. Но попробуйте провести урок музыки с таким битрейтом. Ученик берёт аккорд на гитаре, а преподаватель слышит кашу — алгоритмы шумоподавления срезают обертоны, потому что принимают их за фоновый шум. Та же история с уроками английского языка или русского языка: интонации, придыхания, тонкие фонетические различия теряются. Для платформы онлайн-обучения, где звук — основной инструмент передачи знаний, это критично.

Второй враг — задержка (latency). В обычном видеочате задержка 300–500 мс нормальна. Но при интерактивных занятиях, где преподаватель просит ученика повторить фразу или сыграть пассаж, полсекунды превращают диалог в мучение. Люди перебивают друг друга, теряют ритм, устают быстрее. Для индивидуальных уроков это раздражает, для групповых — убивает процесс. Когда в виртуальном классе сидят 15–20 учащихся и каждого нужно по очереди слушать, задержки складываются и дают хаос.

### Групповые уроки — отдельная головная боль

Стабильность соединения при групповых онлайн-занятиях зависит от самого слабого звена. Один ученик заходит с мобильного приложения через 3G в пригороде, другой — с ноутбука через домашний Wi-Fi, третий сидит в коворкинге с перегруженной сетью. Система видеосвязи должна адаптироваться к каждому из них: снижать разрешение видео для слабого канала, сохраняя при этом приемлемое качество звука. Готовые решения вроде встроенного Zoom или Jitsi этим управляют ограниченно — у них нет доступа к логике урока и они не знают, кому сейчас необходимое приоритетное соединение: тому, кто отвечает, или тому, кто демонстрирует презентации на онлайн-доске.

При разработке [платформы Glinka Digital для онлайн-уроков музыки](/ru/project/glinka-digital) именно видеосвязь стала ключевым вызовом. Задача была не просто создать видеозвонок, а сделать инструмент, в котором преподаватель слышит нюансы звукоизвлечения ученика в реальном времени. Пришлось отказаться от стандартных кодеков и работать с аудиопотоком отдельно от видео, выставляя приоритеты так, чтобы звук шёл без потерь даже при просадке канала.

Похожие задачи, но с другой спецификой, решались в [проекте для Сколтеха](/ru/project/skoltech). Там сотни студентов подключались одновременно, и платформа должна была работать стабильно при разных сценариях проведения лекций и семинаров — от потокового вещания на 200 человек до камерных групп по 5–8 студентов с обратной связью.

### На что обратить внимание при выборе

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

## Сколько стоит разработка своей платформы и сколько занимает по времени

Перейдём к самому болезненному вопросу — деньгам и срокам. Стоимость разработки платформы для онлайн-уроков зависит от десятков переменных, и любой, кто называет точную цифру до анализа задачи, скорее всего, лукавит. Но ориентиры дать можно.

### Из чего складывается бюджет

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

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

Третий — интеграции. Подключение платёжных систем, сервисов рассылок, CRM, видеосвязи, хранилищ для учебных материалов и файлов. Каждая интеграция требует времени на разработку, тестирование и поддержку.

Детальный разбор структуры затрат на создание приложения — [по ссылке](/ru/blog/mobile-app-development-cost). Там же понятным языком объясняется, почему мобильное приложение удваивает бюджет по сравнению с веб-версией.

### MVP, полноценная платформа и поддержка

MVP — минимальная рабочая версия, с помощью которой можно начать обучать первых учеников. Обычно это личный кабинет для двух ролей, доступ к урокам, простой формат подачи контента, базовые задания. MVP образовательной платформы начинается от 1,5 млн ₽, срок — от трёх месяцев. Точная оценка зависит от числа ролей и набора модулей.

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

Мобильное приложение для iOS и Android — отдельная строка расходов, которая прибавляет к проекту и время, и деньги.

### Ошибка, которую допускают почти все

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

Без выделенного бюджета на сопровождение платформа за полгода-год устаревает. Это не гипотетический сценарий, это закономерность. Поддержка включает серверную инфраструктуру, обновления безопасности и обработки персональных данных, быстрый фикс багов, адаптацию под новые версии операционных систем. Забыть про эти расходы — всё равно что купить автомобиль и не заложить деньги на бензин и ТО.

Прежде чем выбрать между готовым сервисом и собственной разработкой, стоит честно посчитать не только первый платёж, но и совокупные затраты за два-три года. Иногда готовые решения с бесплатным тарифом на старте оказываются дороже, а иногда собственная платформа не окупается вовсе. Всё зависит от масштаба: количество учеников, число курсов, задачи, которые не решить без кастомной разработки.

## Как принять решение: чек-лист для вашей школы

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

### Вопросы, которые решают всё

**Сколько у вас учеников прямо сейчас?** Если до 200 человек, готовые сервисы закрывают задачи без ограничений. Конструктор уроков, личный кабинет студентов, приём оплаты, домашние задания, чат с преподавателем — всё это доступно бесплатно или за несколько тысяч рублей в месяц. Тратить время на разработку при таком масштабе нет смысла.

**Какой размер базы контактов и какой тариф платформы?** На GetCourse счёт растёт от накопленной базы, а не только от активных учеников. Посчитайте подписку за год вместе с эквайрингом — и сравните с тем, сколько из базы реально учится.

**Нужна ли уникальная логика уроков и заданий?** Интерактивные тесты с ветвлением, адаптивные траектории обучения, нестандартная система оценки — если что-то из этого критично, готовые тарифы вряд ли справятся. На стандартных платформах для онлайн-курсов можно создавать видеоуроки, текстовые материалы, простой формат тестов. Но создать нестандартную механику, скажем, для занятий по английскому языку с распознаванием речи — уже нельзя.

**Критична ли встроенная видеосвязь?** Если школа проводит онлайн-уроки в реальном времени, вебинары или индивидуальные занятия, подумайте: устраивает ли вас Zoom как отдельных инструмент? Или нужна запись уроков, интерактивные доска и презентации прямо внутри платформы? Второе — это уже история про собственную разработку.

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

**Есть ли в команде технический специалист?** Хотя бы один человек, который понимает, как работать с подрядчиками, ставить задачи разработчикам и проверять результат. Без такого человека образовательная платформа на заказ рискует затянуться на месяцы. Это не повод отказываться, но повод заложить дополнительные 14 дней на подготовку.

**Насколько важен доступ к базе учеников и данным?** Политика персональных данных, контакты учащихся, аналитика по каждому уроку — на чужом сайте всё это принадлежит не вам. Если хотите получить полный контроль, строить CRM-связи и использовать данные для маркетинга — нужна своя система.

### Три сценария по результатам

**Большинство ответов указывают на малый масштаб.** Менее 200 учеников, оборот до 300 000 ₽, стандартные задания, нет потребности в уникальных функциях. Решение: оставайтесь на готовом сервисе, попробуйте бесплатный тариф и не усложняйте. Первый приоритет — контент и продажи, а не разработка.

**Школа растёт, но не всё критично.** 300–1000 учеников, несколько курсов, оборот выше 500 000 ₽, есть пара задач, которые готовые инструменты решают плохо. Решение: мигрируйте частично. Используйте готовую платформу как базу, а отдельные модули — приложение, проведения онлайн-занятий с видео, нестандартные задания — закажите на стороне.

**Всё упирается в ограничения.** Более 1000 учеников, высокий оборот, уникальные методики обучения, потребность в связи данных с CRM и маркетингом. Решение: стройте свою образовательную платформу. Запросите расчёт у двух-трёх студий и сравните. С примерами реализованных проектов разных масштабов можно ознакомиться по [ссылке](/ru/solutions/edtech).

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

## Часто задаваемые вопросы

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

### Можно ли перенести учеников и контент с готового сервиса на свою платформу?

Да, но процесс зависит от конкретного сервиса. GetCourse и другие крупные платформы позволяют выгрузить базу учеников, контакты, историю оплат и учебные материалы в формате файлов CSV или через API. Видеозаписи уроков, домашние задания, тесты и презентации придётся переносить вручную или с помощью скриптов. Первый шаг — запросить у текущего сервиса полный экспорт персональных данных пользователей: по закону отказать не могут.

### Сколько времени займёт запуск MVP своей платформы для онлайн-уроков?

Минимальный работающий продукт с личным кабинетом, расписанием занятий, приёмом оплаты и доставкой видеоконтента создают за 2–4 месяца. Сроки зависят от количества ролей (ученик, преподаватель, администратор), сложности интерактивных заданий и необходимости встроенной видеосвязи. Если нужна быстрая проверка гипотезы — можно сделать первый релиз за 6–8 недель, а дополнительные функции добавлять после запуска.

### Что дешевле в перспективе двух лет — готовый сервис или своя разработка?

Для онлайн-школы с количеством учеников до 300–500 готовый сервис обойдётся дешевле: тарифы от 3 000 до 15 000 рублей в месяц, за два года выходит до 360 000 ₽. Своя образовательная платформа стартует от 1,5 млн ₽ на разработку, но ежемесячные расходы после запуска — только хостинг и поддержка. При обороте выше 500 000 ₽ в месяц и тысяче студентов комиссии и ограничения готовых решений начинают «съедать» экономию, и собственная разработка окупается уже к концу первого года.

### Обязательно ли делать мобильное приложение для онлайн-школы?

Нет, на старте достаточно адаптивного сайта. Большинство учащихся проходят онлайн-курсы с телефона через браузер, и если интерфейс удобный — приложение не даёт заметного прироста конверсии. Приложение имеет смысл создавать, когда у школы больше 1 000 активных учеников, есть потребность в пуш-уведомлениях, офлайн-доступе к материалам или чат для обратной связи работает в реальном времени. Попробовать бесплатно можно с помощью конструктора PWA — это промежуточный формат между сайтом и нативным приложением.

### Как обеспечить стабильную видеосвязь для групповых онлайн-занятий?

Главные задачи — низкая задержка звука (до 200 мс), адаптивный битрейт видео и устойчивость при слабом интернете у отдельных участников. Для проведения онлайн-уроков в группах до 30 человек хорошо работают готовые SDK: Daily, Whereby Embedded, Agora. Если занятия проводят для большего числа, нужен медиасервер с SFU-архитектурой, который распределяет нагрузку. Не стоит использовать простой WebRTC peer-to-peer для групп — система начнёт «сыпаться» уже при 5–6 участниках. Подробнее о реализации видеосвязи для онлайн-образования — в [кейсе платформы для уроков музыки](/ru/project/glinka-digital).

## Выводы

Вся эта история с выбором между готовым сервисом и собственной платформой для онлайн-уроков сводится к трём числам: количество учеников, ежемесячный оборот и число курсов. Не к философии, не к амбициям, не к тому, что «хочу как у больших». К цифрам.

Преподаватель с 30–50 учениками, который проводит занятия по английскому языку или ведёт несколько онлайн-курсов, не нуждается в собственной разработке. Готовые инструменты закрывают задачи такого масштаба целиком: личный кабинет для учеников, домашние задания, запись вебинаров, приём оплаты, чат с группой. Бесплатный тариф или подписка за 3–5 тысяч рублей в месяц — и можно работать, а не тратить время на согласование макетов интерфейса с разработчиками.

Онлайн-школа с 300–500 учениками и несколькими преподавателями попадает в серую зону. Сервис ещё справляется, но ограничения уже ощутимы. Комиссии с каждого платежа съедают бюджет. Нет доступа к базе персональных данных студентов в удобном формате. Нельзя создать индивидуальные сценарии уроков, встроить нестандартные интерактивные задания или подключить собственное мобильное приложение. Образовательная платформа, которая раньше помогала расти, начинает тормозить. И тут у каждого владельца возникают вопросы: платить ли дальше за чужие ограничения или вложиться в своё решение?

Точка перелома наступает, когда стоимость использования готового сервиса за год превышает стоимость первого этапа разработки. Для большинства онлайн-школ это происходит где-то между 500 и 2 000 учеников — зависит от тарифов, комиссий и того, какие дополнительные функции приходится докупать. Подготовка к переезду на свою платформу занимает несколько месяцев, и лучше начать считать заранее, а не когда ограничения станут критичными.

Быстрый чек-лист для принятия решения: возьмите оборот за последние 90 дней, посчитайте, сколько из него уходит сервису (подписка + комиссии + сторонние интеграции). Если сумма перевалила за 50–70 тысяч рублей в месяц и продолжает расти — есть смысл получить расчёт на создание собственной системы. Если нет — продолжайте работать на готовой платформе, это разумный выбор, а не компромисс.

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

Определите свою стадию, сделайте расчёт — и ответ станет понятным без любых статей. А если цифры говорят, что пора строить своё, — команда [WAPP](/ru/solutions/edtech) готова обсудить задачи и сроки.

---

## Blog: Custom online school platform or ready-made SaaS: what to choose and what it costs

- **Slug:** `platforma-dlya-onlayn-shkoly`
- **Locale:** `en`

## Who needs a custom platform for online lessons — and why

Building your own online lesson platform starts around 1.5M RUB and three months. A SaaS subscription starts around 3,000 RUB per month, with signup in about two weeks — and you can teach immediately. The choice looks obvious. A year or two later it often flips: fees climb, students hit someone else’s UI, and teachers cannot run the lesson format they need. The “free plan” ends up costing more than a product you own.

WAPP builds EdTech products for companies of different sizes and sees both sides of this choice. On the [EdTech solutions page](/en/solutions/edtech) we show projects from one-to-one music lessons to university platforms. That experience gives a clear language for when boxed tools are enough — and when they become a brake.

### Three scenarios — three different answers

There is no universal answer. There are clear criteria that help you choose quickly.

**Scenario one — a teacher at the start.** An English tutor with 30 students. They need a portal, a schedule, homework, chat, and video. A course builder on GetCourse, Antitrainingi, or similar covers that. Custom development is a waste here: the student base is small, the learning flow is standard, and materials — video, text, files — fit templates. You can try free plans and work for a year or two without hard limits.

**Scenario two — a school that has grown.** 500 students, several courses, groups at different levels. SaaS pricing starts to bite. Commission on every payment, no way to build interactive tasks with your own logic, weak access to student data for analytics, someone else’s site instead of your brand. The school invents workarounds and loses contacts on every platform update. Here you should run the numbers: sometimes a year of extra SaaS cost exceeds the first stage of a custom system.

**Scenario three — a large school or training centre.** 2,000+ students, webinars, lesson recording, payments, CRM, a mobile app, teacher–student chat, a branching curriculum. Boxed products can still run — but every new feature is a crutch. A custom online lesson platform pays off because you own the data, remove product limits, and shape the product around the business instead of the other way around.

### Who this article is for

Below is concrete detail for each scenario: what development costs, what drives the price, how to run live lessons without call dropouts, and why video is a separate hard problem. If you want learning that scales without overpaying — we walk through teaching online on your own stack or on SaaS, and when the first option wins.

## When GetCourse and similar SaaS are enough

Honestly: if a teacher has 30–80 students and one or two courses, debating frameworks and databases is a waste of time. SaaS is faster and cheaper. Here are situations where custom build is not needed at all.

### Teacher at the start: speed beats perfection

An English tutor used to teach on Zoom and now wants a recorded course with paid access. Dozens of students, modest revenue. The first impulse — “our own platform so it looks serious.” Don’t.

GetCourse, Antitrainingi, Stepik, Teachable — any of these let you assemble a student portal in two or three days, upload video, attach files, set homework, and take payments. A lesson builder walks you through each step. Signup is enough to start the same day.

Plans start around 3,000–5,000 RUB per month. That includes chat, quizzes, webinar recording, and a contact base. Some products offer a free tier or a 14-day trial. On Stepik you can publish a course for free and grow the first cohort.

36,000–60,000 RUB a year for SaaS versus at least 1.5M RUB and three months to build. The arithmetic is clear.

### Standard learning format — standard platform

A school that runs recorded lessons, homework review, teacher feedback, occasional webinars. Under a hundred students. Content is video, text, decks, quizzes. No custom simulations, branching programmes, or deep analytics.

For that, SaaS fits. GetCourse covers sales funnel and lesson delivery in one product. Antitrainingi keeps course creation simple. Teachable works for English-speaking audiences. Any of these can last years — until the school hits limits that hurt.

If you teach under a hundred people online, custom build is a distraction. Time spent on specs and developer cycles is better spent on new lessons and acquiring students. At the start the product is the education outcome, not the platform.

When student count passes a hundred and non-standard flows appear — then a custom platform becomes a real conversation.

## What really limits you on ready-made platforms

The first limit growing schools hit is money — but do not confuse acquiring fees with a platform markup. Get Module (GetCourse Pay) commission is payment processing: as of a 2026 snapshot, about 3.5% for Russian cards, SBP and Pay services, and about 10% for foreign cards. Rates change, so check current terms before you model costs. That is acquiring inside the ecosystem, not GetCourse charging “on top of” acquiring.

The real scale trap is different. GetCourse pricing is based on the full accumulated contact base, not on active students. As of a 2026 snapshot, plans start around 4,400–5,900 RUB per month and climb to about 145,000 RUB on the top tiers — you keep paying for people who stopped learning long ago. Every funnel and ad campaign grows the base, and with it the monthly bill. Pricing policy can also shift: tiers rise, terms tighten, while students, materials and payment history stay locked inside the product.

### Someone else’s domain, someone else’s brand

The school runs on a platform subdomain or a template site. Student portals look the same for every customer of that SaaS. You cannot build a memorable learning environment that stands for your brand. An app? Only if the vendor ships one — under their name.

### Lesson logic and classroom mechanics

This is where builders break first. You want gamification: points for homework, group rankings, topics unlocked by progress. Ready-made LMS tools rarely support that. Stitching third-party tools is fragile.

Or you need interactive tasks with live checking — not multiple choice, but richer logic. Or personal paths where the next lesson depends on previous results. That is outside what course constructors can do.

### Student data is locked

Webinars ran, videos uploaded, the base grew — but raw data access is limited. You get the reports the vendor designed. Contacts, material history, homework files sit on someone else’s servers. Privacy policy is theirs, not yours. If the service shuts down or changes terms, continuous learning is hard to keep. Export is usually a thin CSV.

### When limits become critical

The line is not only student count — it is task complexity. If you need in-lesson support chat, non-linear materials, or your own mobile app, you either live with limits or build. The first path is cheaper for a few days; the second for a two-year horizon. That is when you ask what a custom distance-learning platform is made of — and what it costs.

## What a custom online school platform is made of

A custom platform is not one monolith. It is a set of modules. You can assemble them gradually: first what you need to launch, then the rest.

### Role portals

Each user type gets its own interface:

- **Student portal** — schedule, lesson access, homework, payment history. No extra buttons.
- **Teacher portal** — create lessons, upload materials, review work, give feedback. No finance screens.
- **Admin portal** — tariffs, registrations, analytics, payments.
- **Curator portal** — group progress and retention support.

Role split sounds simple; flexible setup on SaaS is almost impossible. Multi-branch schools need limited admins per branch. Example: the [volleyball school platform with branches](/en/project/future-volleyball-school), where each site has its own curators and schedule.

### Schedule and calendar

For live lessons, scheduling is critical. Students book slots, teachers confirm, the system sends reminders. One-to-one lessons need time zones. Group lessons need seat limits, waitlists, and auto-cancel when underfilled.

### Content delivery

The core of any learning platform: video, text, quizzes, files, decks, homework. A lesson builder lets teachers assemble materials without engineers. Non-linear courses need knowledge checks built in. That is how the [Glinka Digital music lesson platform](/en/project/glinka-digital) works: interactive tasks, fast access to recordings, materials tuned per student.

### Payments and subscriptions

Payments, tariffs, renewals, refunds. Acquiring is paid either way — on SaaS and on a custom platform. As of a 2026 snapshot, YuKassa’s base card rate starts around 2.8%, SBP around 0.4–0.7%; Get Module for Russian cards, SBP and Pay services is about 3.5%. A gap of roughly 0.7 pp does not pay for building a payments module by itself, and YuKassa can also be connected inside GetCourse. Acquirer rates change — re-check the numbers before you decide.

What a custom platform gives here is not “savings on a middleman fee”, but freedom to pick the acquirer and payment flows: instalments, subscriptions, SBP-first with a lower fee, your own refund rules and access statuses. The payments module exists so money follows the school’s logic, not a course-builder template.

### Analytics and reports

Who finished the course? Where do people drop? Which teachers get the best scores? SaaS analytics is a handful of standard reports. A custom platform can cut any slice — down to days between signup and first payment.

### You do not have to build everything at once

This is not a monolith. Start with portals, schedule, and content delivery; add chat, mobile, and advanced analytics months later. That cuts initial budget and time to launch — often 60–90 days instead of half a year.

## Video for online lessons: why it is a separate hard problem

Among all modules, video is the trickiest. It looks like “drop in any call tool and send a link.” In practice, “run a meeting” and “run a lesson” are far apart.

### Why a normal video chat fails for lessons

First enemy — audio quality. For a work call, 32 kbps is fine. Try a music lesson at that bitrate: noise suppression cuts overtones as “background noise.” The same happens in language lessons: intonation and fine phonetics disappear. When sound carries knowledge, that is critical.

Second enemy — latency. In chat, 300–500 ms is normal. In interactive lessons where a student must repeat a phrase or play a passage, half a second breaks the dialogue. People talk over each other and tire faster. In a class of 15–20, delays stack into chaos.

### Group lessons are another headache

Stability follows the weakest link. One student on 3G, another on home Wi‑Fi, a third on a crowded coworking network. The system must adapt per participant: drop video resolution on a weak link while keeping usable audio. Zoom or Jitsi manage this only roughly — they do not know lesson logic or who needs priority: the speaker answering now or the person sharing a whiteboard.

On [Glinka Digital for music lessons](/en/project/glinka-digital), video was the key challenge. The goal was not a call — it was hearing sound production nuance in real time. Standard codecs were not enough; audio was handled separately from video so sound stayed clean when the channel dipped.

Related load problems appeared on the [Skoltech project](/en/project/skoltech): hundreds of students online, from broadcast lectures for 200 to small groups of 5–8 with feedback.

### What to check when choosing

If you run live lessons — not only recorded video — treat video as a separate workstream early. Test latency, devices, and unstable networks. Free trials help, but the final choice follows the subject: homework-heavy courses care less about call quality; live voice interaction makes video the foundation.

## What custom development costs and how long it takes

Cost depends on dozens of variables; anyone naming an exact figure before discovery is guessing. Orientations still help.

### What drives the budget

First — number of roles. One student type and one teacher is simpler than admins, curators, methodologists, and groups with separate portals and rights. Each role means dozens of screens.

Second — feature set. Course builder, auto-graded homework, live schedule, chat, payments, webinar recording, boards, mobile — each is a module. More modules in v1 means longer timelines and higher budget.

Third — integrations. Payments, email, CRM, video, file storage. Each needs build, test, and support time.

A deeper cost breakdown for apps is in [this article](/en/blog/mobile-app-development-cost). It also explains why a native mobile app roughly doubles budget versus web-only.

### MVP, full platform, and support

MVP is the smallest product that can teach the first students: portals for two roles, lesson access, simple content, basic tasks. An EdTech MVP often starts from 1.5M RUB and three months — exact scope depends on roles and modules.

A full platform with per-student analytics, flexible schedule, live video lessons, and multi-group tariffs is estimated after discovery.

A mobile app for iOS and Android is a separate line that adds time and money.

### The mistake almost everyone makes

Schools fund the build, launch, celebrate — and three months later need UI updates, teacher tools, device-specific fixes, and OS adaptations. Support is a monthly line every year.

Without a support budget the platform ages in six to twelve months. Hosting, security, personal-data handling, bugfixes, OS updates are not optional — they are fuel and maintenance.

Before you choose SaaS vs custom, count total cost over two or three years, not only the first invoice. Sometimes a “free” SaaS plan is more expensive; sometimes custom never pays back. It depends on scale: students, courses, and tasks that cannot be solved without custom work.

## How to decide: a checklist for your school

Numbers are in, pros and cons are clear — and choice still stalls because every project is unique. Answer the questions below honestly and match the recommendation at the end.

### Questions that decide everything

**How many students do you have now?** Under 200, SaaS covers the basics: lesson builder, student portal, payments, homework, chat — free or a few thousand RUB a month. Custom build is not worth it at that scale.

**How large is the contact base, and which SaaS plan are you on?** On GetCourse the bill grows with the accumulated base, not only with active students. Add a year of subscription plus acquiring — and compare that to how many contacts still learn.

**Do you need unique lesson and task logic?** Branching quizzes, adaptive paths, non-standard scoring — if any of that is critical, boxed plans rarely cope. Standard platforms do video, text, and simple tests. Speech recognition for English lessons is already out of scope.

**Is built-in video critical?** If you run live lessons or webinars, is Zoom as a separate tool fine — or do you need recording, boards, and decks inside the product? The second path is custom.

**Will you grow two or three times in a year?** If yes, user count and SaaS fees grow together. Each new student raises cost on someone else’s platform.

**Is there a technical owner on the team?** Someone who can brief vendors and check delivery. Without that person a custom project stretches. Not a reason to refuse — a reason to add two weeks of prep.

**How important is ownership of the student base?** Contacts, per-lesson analytics, CRM links — on someone else’s site that is not fully yours. Full control means your system.

### Three outcomes

**Most answers point to small scale.** Under 200 students, under 300k RUB revenue, standard tasks, no unique features. Stay on SaaS, try a free plan, do not overcomplicate. Priority is content and sales.

**The school is growing, but not everything is critical.** 300–1000 students, several courses, revenue above 500k RUB, a few poorly served tasks. Migrate partly: keep SaaS as the base, custom-build video or special tasks on the side.

**Everything hits limits.** Over 1000 students, high revenue, unique methods, CRM and marketing data needs. Build your platform. Get quotes from two or three studios. Examples at different scales are on the [EdTech solutions page](/en/solutions/edtech).

The choice is not binary. Start on SaaS today and grow into custom over a year. Staged migration beats building everything before you know which features your cohorts actually need.

## Frequently asked questions

Common questions from online school owners choosing between SaaS and a custom build.

### Can you migrate students and content from SaaS to your own platform?

Yes, but it depends on the vendor. GetCourse and similar products usually export students, contacts, payments, and materials as CSV or via API. Video, homework, quizzes, and decks often need manual transfer or scripts. First step — request a full personal-data export; by law they cannot refuse.

### How long does an MVP for online lessons take?

A working product with portals, schedule, payments, and video content delivery usually takes 2–4 months. Timeline depends on roles (student, teacher, admin), interactive tasks, and whether video is built in. For a fast hypothesis check, a first release can land in 6–8 weeks, with more features after launch.

### What is cheaper over two years — SaaS or custom?

For schools with up to 300–500 students, SaaS is usually cheaper: 3,000–15,000 RUB per month, up to ~360k RUB over two years. A custom platform starts from ~1.5M RUB to build, then hosting and support. Past 500k RUB monthly revenue and about a thousand students, SaaS fees and limits eat the savings — custom often pays back by the end of year one.

### Is a mobile app mandatory for an online school?

No. An adaptive site is enough at the start. Most students learn on phones in the browser; if UX is good, an app rarely moves conversion. An app makes sense past ~1,000 active students when you need push, offline materials, or real-time chat. A PWA constructor is a middle step between site and native apps.

### How do you keep stable video for group online lessons?

Goals: audio latency under ~200 ms, adaptive video bitrate, resilience when some participants have weak internet. For groups up to ~30, SDKs like Daily, Whereby Embedded, or Agora work well. Larger groups need an SFU media server. Plain WebRTC peer-to-peer collapses around 5–6 participants. More on lesson video in the [music lesson platform case](/en/project/glinka-digital).

## Takeaways

Choosing between SaaS and a custom online lesson platform comes down to three numbers: student count, monthly revenue, and number of courses — not ambition or “we want what the big schools have.”

A teacher with 30–50 students running English lessons or a few courses does not need custom development. SaaS covers portals, homework, webinar recording, payments, and group chat. A free plan or 3–5k RUB per month lets you work instead of approving UI mockups.

A school with 300–500 students and several teachers sits in the grey zone. SaaS still works, but limits show: commissions, awkward data export, no custom lesson scenarios or mobile app. The platform that helped growth starts to slow it.

The tipping point is when a year of SaaS cost exceeds the first custom stage. For most schools that lands somewhere between 500 and 2,000 students — depending on fees, commissions, and add-ons. Migration prep takes months; start counting before limits become critical.

Quick check: take the last 90 days of revenue and sum what goes to the vendor (plan + commissions + side tools). Past 50–70k RUB a month and still rising — get a custom quote. If not — staying on SaaS is a rational choice, not a compromise.

Education is moving online for good. Tools must match business scale, not the other way around. Do not build from scratch for 20 students. Do not keep paying for someone else’s limits when custom pays back in a year.

Find your stage, run the numbers — and the answer becomes clear without any article. If the numbers say it is time to build, the [WAPP](/en/solutions/edtech) team can discuss scope and timelines.

---

## Blog: Pokepok: полмиллиона просмотров в TikTok и поиск смысла

- **Slug:** `pokepok-tiktok-half-million`
- **Locale:** `ru`

![]()
Борьба с СДВГ — это не просто забывчивость, это постоянный поиск стимулов. Проект **Pokepok** начинался как попытка создать «цифровой костыль», который за счёт дофаминовых петель и геймификации поможет мозгу удерживать фокус. Но в процессе разработки мы поняли: никакое приложение не станет «волшебной таблеткой».

## Эволюция стека: от веба к нативному приложению

Первоначальный прототип мы собрали на **Laravel и HTMX**. Это позволило быстро проверить механику в вебе. Однако внимание человека с СДВГ — ресурс мобильный. Помощь нужна здесь и сейчас, поэтому мы перешли к разработке полноценного приложения на **React Native**.

**Выбранная архитектура «Local-first»:**
* **Локальное хранилище:** Все данные живут на устройстве. Это позволяет работать без интернета, не давая пользователю повода зайти в сеть и случайно «провалиться» в ленту соцсетей.
* **Редкая синхронизация:** Сервер используется только как бэкап, чтобы данные не терялись при смене устройства. Это обеспечило максимальную приватность и мгновенный отклик интерфейса.

## Почему мы решили не выпускать продукт

В процессе разработки мы осознали, что рынок перенасыщен качественными решениями (например, **Habitica**), которые проработаны гораздо глубже. Но была и более важная, внутренняя причина.

С появлением тренда на **вайб-кодинг (vibe coding)** стало понятно: сегодня каждый может собрать инструмент «под себя», под свои уникальные триггеры и привычки. Массовое, жестко структурированное приложение — это компромисс, который не всегда оправдан. 

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

## Функционал и дизайн

### 01. Экраны приложения: тишина и порядок

### 02. Компоненты и элементы системы

## Основные вызовы

* **Алгоритмы внимания:** Мы проектировали дофаминовые петли, которые поддерживают мотивацию, но не вызывают привыкания к самому приложению.
* **Секретность данных:** Личная информация о привычках и здоровье резидентов зашифрована. Мы понимаем, что это «слишком» личные данные, которые не должны покидать устройство пользователя.

## Команда проекта

**Сергей** — Product Design. Искал баланс между простотой и функциональностью, чтобы интерфейс не отпугивал, а помогал формировать привычки.

**Андрей** — Fullstack Developer. Реализовал переход от HTMX к React Native и выстроил оффлайн-архитектуру с локальным хранилищем.

**Максим** — Management. Отвечал за стратегию и принял решение о смене курса проекта в пользу более честного и рационального подхода к проблеме концентрации.

---

## Blog: Our app video hit half a million TikTok views. Why Pokepok is for everyone (including you)

- **Slug:** `pokepok-tiktok-half-million`
- **Locale:** `en`

To be honest, not every task makes you want to jump in right away. We often have to push ourselves — and then fight the urge to get distracted. You can keep to-do lists the old-fashioned way in a planner or notes, and there are countless todo apps to choose from. But our **WAPP** team decided to build our own interactive offline task planner, Pokepok.

We did not have grand plans: we mostly intended to use it ourselves. Still, we told the story in our cozy [TikTok blog](https://www.tiktok.com/@wappdev) — and the video reached half a million views. We received 3,500 beta requests, so it became clear: the app is not just for us.

## Who Pokepok is for and why

**Pokepok** is an app for people with ADHD — attention deficit hyperactivity disorder. Its symptoms — trouble focusing, restlessness, losing interest quickly — get in the way of productivity for a lot of people. According to [this research](https://pmc.ncbi.nlm.nih.gov/articles/PMC7916320/), persistent ADHD occurs in about 2.58% of adults, while symptomatic ADHD (broader criteria) is around 6.76%.

Similar struggles happen without an ADHD diagnosis: when we keep avoiding important work or quit halfway, we do not see the outcome of our effort. Then the brain produces less dopamine — the chemical linked to pleasure, including the satisfaction of finished tasks, and motivation. If that keeps happening, frustration with yourself builds up. It is easy to fall into habits that deliver quick dopamine hits — pizza, funny clips online. Motivation and effectiveness drop, and mental health suffers.

**Pokepok** helps, first, nudge you to do at least something. Second, keep attention on a task. Third, get the dopamine reward you want — the feeling of a job actually done.

## How the first version works

The first version is a friendly task list in a straightforward flow. Users create cards like “clear inbox,” “buy groceries,” “call mom,” then tap “Start session.” By default a session can hold five tasks, but you can raise the limit in settings. We recommend capping at seven so attention does not scatter. With too many items, motivation is harder to sustain because some tasks may stay unfinished.

The flow offers two tasks from the session — you compare them and pick the one you are ready to do right now. The other goes to the back of the queue and will come back later for another pairwise choice. Tasks you keep postponing still have to get done sooner or later.

When you finish, you tap a button, get praise from the app, then move on to the next task or end the session.

## What we plan next

We are still dogfooding the beta and already seeing early results. For example, we like to start the day by checking different stats — numbers help flip the work switch. We add that to the session daily and believe a todo app should include as many pleasant tasks as possible.

The app is not publicly downloadable yet: we are polishing the test build and using it ourselves. Later we will roll it out to first users to learn what they still need in **Pokepok**. The backlog already includes features we want to add:

- **Task ordering by how much you want to do them.** The most enjoyable task can come first — easier to warm up and get an early dopamine win.
- **Time tracking** for how long a task takes — handy for counting work hours, for example.
- **Time-based reminders.** We skipped notifications in v1 to ship faster.
- **Hyperfocus awareness.** Focus is good, but meals and rest matter. When the flow detects you have been on one task too long, it will suggest switching or taking a break. Focus-session length will be configurable.
- **Gamification.** Competing with yourself adds drive — a little more every day than yesterday. First we will add an in-app currency earned for completed tasks; later, more advanced unlocks tied to points.
- **Curated task card packs** — from universal sets to collaborations with creators.
- **Dark mode.** Many people prefer a night-friendly UI and have already asked for it.

We originally built **Pokepok** for ourselves, but audience interest and our own results showed the idea resonates widely. We hope it helps people start work or life tasks with less friction. Even when cleaning the flat or finishing a report is not exciting, a small dopamine hit after another “Nice work!” is worth it. That is what **Pokepok** is about.

---

## Blog: Протокол испытаний: состав документа и автоматизация оформления

- **Slug:** `protokol-ispytaniy`
- **Locale:** `ru`

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

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

## Протокол испытаний, акт и заключение — в чём разница

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

### Протокол испытаний: первичный документ

Протокол испытаний — это документ, содержащий результаты конкретных испытаний, выполненных по конкретной методике. Он включает сведения о лаборатории, описание образцов, условия проведения испытаний, методы измерений, полученные значения и оценку неопределённости. Протокол отвечает на вопрос: «Что именно проверяли, как проверяли, что получили?»

Главное свойство протокола — возможность проследить каждое значение до первичной записи. Уникальный номер, дата проведения, наименование продукции, реквизиты средств измерений, подписи ответственных лиц — всё это обязательные элементы. Общие требования к оформлению задаёт стандарт ГОСТ ISO/IEC 17025, и именно по нему оценивают компетентность испытательной лаборатории при подтверждении аккредитации. Официальный текст стандарта доступен на сайте Росстандарта.

Когда проверяющий приходит в лабораторию, он берёт протокол и сверяет его с записями. Не заключение, не акт — именно протокол, потому что это первичный документ, на котором строится вся система подтверждения соответствия.

### Акт испытаний: факт без деталей

Акт испытаний фиксирует сам факт: испытания состоялись, образцы приняты, работа выполнена. Но акт обычно не содержит ни описания методов, ни результатов измерений. Например, акт может зафиксировать передачу образцов строительных материалов, но конкретных показателей прочности изделия в нём не будет.

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

### Заключение: экспертный вывод

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

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

## Обязательные элементы протокола испытаний

Какие обязательные элементы должны содержаться в протоколе испытаний, чтобы он прошёл проверку? Базовый минимум по ГОСТ ISO/IEC 17025 одинаков для всех аккредитованных лабораторий. Правила оформления распространяются на испытательный центр любого профиля — от химического до строительного.

### Сведения об испытательной лаборатории

Наименование организации, юридический адрес, номер аттестата аккредитации, срок его действия, контакты и номер телефона, ИНН юридического лица. Без этих данных документ невозможно проверить в реестре Росаккредитации, а значит, для оценки соответствия продукции он не подходит. Дополнительная информация — область аккредитации и дата её утверждения.

### Информация о заказчике

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

### Описание объекта испытаний

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

### Ссылка на методику испытаний

Протокол включает указание на нормативные документы, по которым проводятся исследования. Нельзя просто написать «по стандартной методике» — нужен точный номер и год действия документа. Стандарт ГОСТ ISO/IEC 17025 требует однозначной идентификации применяемого метода.

### Условия проведения испытаний

Температура, влажность, давление, сведения о конкретных средствах измерений — всё, что влияет на результаты испытаний. Протокол, оформленный без этого блока, не выдержит экспертной проверки в сфере государственной аккредитации.

### Результаты измерений

Ядро документа. Результаты фиксируют в единицах, указанных в методике, с необходимой точностью. Заключение о соответствии вносят только когда это прямо оговорено заказчиком или нормативным документом. Для целей определения соответствия продукции техническим регламентам это обязательное условие.

### Оценка неопределённости измерений

ГОСТ ISO/IEC 17025 требует, чтобы протокол содержал оценку неопределённости — или обоснование, почему она неприменима. Неопределённость — обязательный элемент для государственной оценки соответствия, сертификации и принятия решений органами федерального надзора.

### Дата проведения и подписи

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

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

## Что проверяют при аудите: данные и их источники

Возможность проследить полную цепочку — откуда взялось значение в протоколе, кто его внёс, когда, на основании какой записи — это требование ГОСТ ISO/IEC 17025. Лаборатория, проводившая испытания, должна предъявить первичные записи по любому выданному протоколу. На практике это удаётся не всегда.

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

### Где возникают проблемы

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

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

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

## Типичные ошибки при оформлении протоколов

Вот ошибки, которые встречаются чаще всего — и способны затянуть проверку или поставить под вопрос результаты испытаний целой серии образцов.

**Значения в протоколе не совпадают с записями.** Инженер копирует результаты испытаний в шаблон и где-то допускает неточность. Проверяющий при сверке протокола с первичными записями фиксирует несоответствие.

**Устаревший шаблон документа.** Методику обновили, стандарт пересмотрели, а оформление идёт по старому бланку. В документе указан отменённый нормативный акт или отсутствует поле из новой редакции. Для подтверждения соответствия продукции требованиям технических регламентов такой протокол испытаний не примут.

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

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

**Нет истории изменений.** Кто-то исправил значение в готовом протоколе испытаний — когда, зачем, на каком основании неизвестно. Для аккредитованной лаборатории отсутствие фиксации изменений — серьёзное несоответствие.

Все эти ошибки объединяет одно: их источник — ручной ввод информации. При потоке в десятки документов в месяц проверка вручную отнимает часы, необходимые для проведения самих испытаний.

## Почему ручной ввод результатов — системная проблема

Инженер проводит испытания и фиксирует результаты. Открывает шаблон, вносит данные. Берёт калькулятор и делает расчёты. Полученные значения снова вносит в шаблон. Форматирует документ. Отправляет на подпись. Шесть этапов, на каждом информация проходит через руки человека.

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

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

## Как работает автоматическое формирование протокола

Замена ручного процесса на автоматический — задача, которую решает использование лабораторной информационной системы (ЛИМС). Механика укладывается в следующие шаги: данные попадают в базу, система считает по заложенным методикам, готовый документ собирается автоматически.

### Откуда берутся данные

Всё начинается с [ЛИМС](/ru/solutions/chem-lab/lims) — лабораторной информационной системы. Результаты испытаний попадают туда напрямую: с приборов через интеграцию, из электронной формы регистрации образцов. Запись привязана к конкретному образцу, методике, дате и ответственному лицу.

### Расчёты без человеческого фактора

Формулы методик заложены в систему. ЛИМС автоматически пересчитывает значения в установленных единицах, проводит оценку неопределённости и формирует заключение о соответствии — если это входит в область аккредитации. Человек не пересчитывает вручную, не путает формулы. Ошибка возможна только на этапе настройки — и её можно проверить один раз.

### Шаблон подбирается по методике

У каждой методики свой шаблон оформления. Система сама определяет, какой использовать, и собирает документ автоматически. Когда методика обновляется — обновляется и шаблон. Старые протоколы испытаний остаются привязаны к прежней версии, а новые испытания автоматически используют актуальный вариант.

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

### Фиксация действий без дополнительных усилий

Действие в системе фиксируется: кто внёс данные, когда, какие результаты попали в расчёт. Можно поднять полную историю любого протокола испытаний и показать цепочку от первичных данных до готового документа. Такой подход при разработке лабораторных систем реализует, например, [студия WAPP](/ru/solutions/chem-lab).

Для разбора конкретного исправления полезно видеть рядом исходное и новое значение, автора и время изменения. Связь записи с образцом или протоколом позволяет восстановить контекст исправления.

## До и после: как меняется работа лаборатории

**Срок оформления.** При ручной работе оформление часто растягивается на десятки минут или часы. После автоматизации система подтягивает сведения из базы, выполняет расчёт и формирует документ за минуты.

**Количество ошибок.** В системе информация попадает в документ напрямую из электронной записи. Ошибки не исчезают полностью, но их становится существенно меньше.

**Готовность к проверке.** Если протоколы испытаний формируются в ЛИМС, вся информация структурирована и доступна для поиска. Подготовка к проверке занимает дни, а не недели.

**Нагрузка на инженера.** Автоматизация убирает рутинную часть работы, которая не требует квалификации, но съедает часы. Инженер тратит время на сами испытания и анализ результатов.

Как это выглядит на практике, можно посмотреть на примере [проекта для СпектроХим](/ru/project/spektrokhim). Если задумались о подобных изменениях — в [статье о старте автоматизации](/ru/blog/lab-automation-where-to-start) дана пошаговая логика: от аудита текущих процедур до выбора необходимых модулей и технологий.

Время прохождения одного протокола стоит отслеживать по событиям: регистрация образца → импорт с прибора → расчёт → выпуск PDF и подписание. Интервалы между событиями включают ожидание и сами испытания, поэтому их нельзя целиком считать временем оформления или переносить на все методики.

## Частые вопросы о протоколах испытаний

### Есть ли единая утверждённая форма протокола?

Нет. Состав и оформление зависят от области аккредитации и применяемой методики. Но ГОСТ ISO/IEC 17025 устанавливает перечень обязательных элементов: уникальный номер, дата, наименование лаборатории, сведения об образцах, методы испытаний, результаты, реквизиты ответственных лиц. Общие правила применения стандарта едины для национальной системы аккредитации России.

### Можно ли вносить исправления в выданный протокол?

Можно. Лаборатория выпускает дополнение, где указывает, какие данные изменены, по какой причине и кто принял решение. Старый протокол не уничтожают — он остаётся для обеспечения прослеживаемости. При наличии электронной системы история изменений фиксируется автоматически.

### Обязательно ли указывать неопределённость измерений?

Для аккредитованной лаборатории — да. Это прямое требование ГОСТ ISO/IEC 17025. Оценка неопределённости должна присутствовать, когда она влияет на оценку соответствия продукции. На практике это почти всегда.

### Можно ли выдавать протокол в электронном виде?

Да. Протокол испытаний в электронной форме имеет юридическую силу при наличии квалифицированной электронной подписи. Многие испытательные центры уже перешли на электронную выдачу: клиент получает PDF с ЭЦП, а экземпляр в бумажном виде печатают только по запросу. Использование электронной формы регулируется на уровне федерального законодательства в установленном порядке.

## Выводы

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

Первое. Состав протокола испытаний жёстко определён требованиями ГОСТ ISO/IEC 17025 и правилами национальной системы аккредитации. Сведения о лаборатории, заказчике, образцах, методах испытаний, условиях, результаты с оценкой неопределённости, подписи — всё это обязательные элементы. Пропуск хотя бы одного блока — замечание при проверке.

Второе. Основные ошибки — неточности при вводе значений, расхождение с первичными записями, устаревшие бланки, отсутствие истории изменений. Это не вопрос компетентности специалистов, а системная проблема ручного оформления.

Третье. Автоматизация формирования протоколов испытаний устраняет ручной ввод данных, сокращает трудозатраты и обеспечивает полную фиксацию действий — от первичного измерения до готового документа. На сайте WAPP есть [материал о том, с чего начать автоматизацию](/ru/blog/lab-automation-where-to-start), а [раздел ЛИМС](/ru/solutions/chem-lab/lims) покажет, как устроена работа с протоколами испытаний на практике.

---

## Blog: Test report (protocol): required contents and how to stop filling it by hand

- **Slug:** `protokol-ispytaniy`
- **Locale:** `en`

In a testing laboratory, a noticeable share of working time goes not to the tests themselves, but to documentation. The test report (protocol) is the central document of that work. Any engineer who has copied research results from working notes into a blank form knows the cost of a mistake: an inaccurate value — and a finding from the assessor, negotiation with the client, lost time.

This article covers what matters for the test report: how it differs from an act and a conclusion, and concrete ways to automate drafting. It is written so a newcomer can understand the structure, and an experienced engineer can take away a checklist of required sections and a review of typical form mistakes.

## Test report, act, and conclusion — the difference

These documents have different purposes, and mixing them costs labs time and audit findings. The test report, act, and conclusion are often treated as interchangeable. In practice each records different information and carries different legal weight. For conformity assessment against Customs Union technical regulations, that distinction is essential.

### Test report: the primary document

A test report contains the results of specific tests performed against a specific method. It includes laboratory details, sample description, test conditions, measurement methods, obtained values, and an uncertainty evaluation. The report answers: “What was tested, how, and what was obtained?”

Its key property is traceability of every value back to a primary record. Unique number, test date, product name, measuring-instrument details, responsible signatures — all required elements. General drafting requirements come from ISO/IEC 17025 (GOST ISO/IEC 17025 in Russia), and competence of the testing laboratory is assessed against it for accreditation. The official standard text is available from the national standards body.

When an assessor visits, they take the report and cross-check it with records. Not the conclusion, not the act — the report, because it is the primary document the whole conformity system rests on.

### Act of testing: fact without detail

An act records the fact: tests happened, samples were received, work was done. It usually contains neither methods nor measurement results. An act may record handover of construction materials, without strength values.

Using an act instead of a report fails when organizations try to use it for product certification. Certification bodies do not accept it: they need a full test report.

### Conclusion: expert opinion

A conclusion is the next level. It states conformity: whether the product passed. It relies on the report but adds expert interpretation. Certificates of conformity may be issued on that basis.

That is why hierarchy matters: the report is primary. Without a correct test report, the conclusion has no foundation, and certification loses its evidence base.

## Required elements of a test report

What must a test report contain to survive scrutiny? The ISO/IEC 17025 baseline is the same for accredited laboratories. Drafting rules apply to testing centres of any profile — chemical to construction.

### Laboratory details

Organisation name, legal address, accreditation certificate number and validity, contacts, phone, legal-entity tax ID. Without these the document cannot be checked in the accreditation register, so it is unfit for conformity assessment. Optionally: scope of accreditation and approval date.

### Client information

Who ordered the tests: company name, details, contacts. A report without the client’s stated purpose cannot support conformity assessment against Customs Union technical regulations. Where needed, also the client’s application for work.

### Object of testing

Full sample information: product, batch or unit, marking, sampling date, condition on receipt. For submitted samples — delivery method and conditions. The more precise the sample description, the more reliable the results.

### Reference to the test method

The report must identify the normative documents used. “By the standard method” is not enough — exact number and year are required. ISO/IEC 17025 demands unambiguous method identification.

### Test conditions

Temperature, humidity, pressure, specific measuring instruments — everything that affects results. A report without this block will not survive expert review.

### Measurement results

The core. Results in the units required by the method, with appropriate precision. A conformity statement is included only when the client or the normative document requires it.

### Measurement uncertainty

ISO/IEC 17025 requires an uncertainty evaluation — or a justification why it does not apply. Uncertainty is required for conformity decisions and certification in most cases.

### Dates and signatures

Start and end dates, unique report number, signatures of the performer and laboratory head. Without signatures nobody bears responsibility, and the document has no legal force.

## What auditors check: data and sources

Full traceability — where a value in the report came from, who entered it, when, from which record — is an ISO/IEC 17025 requirement. The laboratory must produce primary records for any issued report. In practice that is not always possible.

The assessor’s path is simple: take the finished report, look at results, then ask for records. They check values, date, sample number, method name. If any link is broken — a nonconformity is logged.

### Where problems appear

Typical case: a technician records results, and two days later an engineer copies them into a report template — and writes 0.034 instead of 0.043. The assessor treats the mismatch as a serious finding, up to suspension of accreditation.

Another case: the template was updated, but staff used an old blank. Worse — changes were made to a finished report with no history kept.

If the lab runs an electronic system where results are pulled from a database and actions are logged, assessors have far fewer questions. If everything rests on manual entry, the audit becomes unpredictable.

## Typical mistakes when drafting reports

These mistakes show up often — and can delay assessment or call a whole sample series into question.

**Values in the report do not match records.** Copying into a template introduces typos; the assessor finds the mismatch.

**Outdated document template.** The method was revised; drafting still uses the old blank with a withdrawn normative reference or a missing new field.

**Missing required fields.** No method name, no lab conditions, no sample number, empty instrument fields — ready-made findings.

**Unit confusion.** The method requires one unit; the report shows another. Conformity assessment becomes impossible.

**No change history.** Someone edited a finished report; when, why, and on what basis is unknown. For an accredited lab that is a serious nonconformity.

What unites these errors is manual data entry. At a flow of dozens of documents a month, manual checking consumes hours needed for testing itself.

## Why manual result entry is a systemic problem

The engineer runs tests and records results. Opens a template, enters data. Uses a calculator. Enters values again. Formats the document. Sends it for signature. Six stages; at each one information passes through human hands.

Drafting one report often takes two to four hours. At dozens of reports a month, drafting consumes a noticeable share of a specialist’s time — time that could go to testing and analysis.

The problem is not people. With manual transfer, errors are statistically inevitable. Double-checking raises labour without removing them. Data live in one place; the report is built in another — with manual copying in between.

## How automatic report generation works

Replacing the manual process is what a laboratory information management system (LIMS) is for. Data enter the database, the system calculates by configured methods, and the finished document is assembled automatically.

### Where data come from

It starts with a [LIMS](/en/solutions/chem-lab/lims). Results arrive directly: from instruments via integration, or from electronic sample registration. Each record is tied to a sample, method, date, and responsible person.

### Calculations without human transfer

Method formulas live in the system. The LIMS recalculates units, evaluates uncertainty, and forms a conformity statement when that is in scope. People do not re-key formulas. Mistakes are possible mainly at configuration — and can be checked once.

### Template chosen by method

Each method has its own layout. The system picks the template and builds the document. When a method updates, the template updates. Old reports stay tied to the previous version; new tests use the current one.

### Action logging without extra effort

Who entered data, when, which results entered the calculation — all logged. You can raise the full history of any report from primary data to the finished document. That approach is how [WAPP](/en/solutions/chem-lab) builds laboratory systems, for example.

## Before and after: how lab work changes

**Drafting time.** Manual work often stretches to tens of minutes or hours. After automation the system pulls data, calculates, and builds the document in minutes.

**Error count.** Data enter the document from the electronic record. Errors do not vanish, but they drop substantially.

**Audit readiness.** Reports formed in a LIMS are structured and searchable. Prep takes days, not weeks.

**Engineer load.** Automation removes routine that does not need deep skill but eats hours. Engineers spend time on tests and analysis.

For a live example, see the [Spektrokhim project](/en/project/spektrokhim). If you are considering similar changes, the [lab automation starting guide](/en/blog/lab-automation-where-to-start) walks from process audit to module choice.

## Frequently asked questions about test reports

### Is there a single approved report form?

No. Content and layout depend on accreditation scope and the method used. ISO/IEC 17025 sets the required elements: unique number, date, laboratory name, sample details, methods, results, responsible persons. The application rules are shared across Russia’s national accreditation system.

### Can you correct an issued report?

Yes. The laboratory issues an amendment stating what changed, why, and who decided. The old report is not destroyed — it stays for traceability. With an electronic system, change history is logged automatically.

### Must measurement uncertainty be stated?

For an accredited laboratory — yes. It is a direct ISO/IEC 17025 requirement when uncertainty affects conformity assessment. In practice that is almost always.

### Can the report be issued electronically?

Yes. An electronic test report has legal force with a qualified electronic signature. Many testing centres already issue a signed PDF; paper is printed only on request. Electronic form is regulated at federal level under the established procedure.

## Conclusions

A test report is a document where every value, date, and method reference matters. Three takeaways.

First. Report content is tightly defined by ISO/IEC 17025 and national accreditation rules. Laboratory, client, samples, methods, conditions, results with uncertainty, signatures — all required. Missing a block is an audit finding.

Second. Main errors — typos on entry, mismatch with primary records, outdated blanks, no change history — are a systemic problem of manual drafting, not specialist competence.

Third. Automating report generation removes manual re-entry, cuts labour, and logs the full chain from primary measurement to finished document. See WAPP’s [where to start with lab automation](/en/blog/lab-automation-where-to-start) and the [LIMS section](/en/solutions/chem-lab/lims) for how report workflows look in practice.

---

## Blog: Запуск MVP: как проверить бизнес-идею и сэкономить бюджет на разработке

- **Slug:** `razrabotka-mvp-kak-sozdat-minimalno-zhiznesposobnyy-produkt-dlya-startapa`
- **Locale:** `ru`

Разработка полноценного приложения может занять годы, но в условиях меняющегося рынка такая медлительность ведет к потере актуальности продукта. MVP (Minimum Viable Product) позволяет запустить проект быстрее, чтобы проверить гипотезы на реальных пользователях и избежать лишних трат.

## Проверить ценность продукта с минимальными вложениями

MVP — это версия продукта с набором функций, достаточным для запуска и оценки потребительской ценности. Основная задача подхода — быстро получить обратную связь и понять, решает ли продукт проблему целевой аудитории.

Если данные показывают, что курс выбран неверно, MVP позволяет оперативно скорректировать стратегию без потери значительных средств.

## Этапы создания жизнеспособного продукта

Процесс разработки MVP требует строгой последовательности действий, чтобы не превратить проект в бесконечный процесс доработок.

* **Определить цели.** Четкое понимание того, чего нужно достичь с помощью MVP, помогает выделить только критически важные функции.
* **Оценить функции.** Необходимо выбрать элементы, которые напрямую удовлетворяют потребности аудитории и решают её основные боли.
* **Разработать и протестировать.** Создание прототипа или минимальной версии приложения позволяет продемонстрировать возможности продукта потенциальным клиентам.
* **Собрать обратную связь.** Активный сбор мнений после запуска помогает выявить слабые места и определить вектор развития.
* **Улучшать итерациями.** На основе данных вносятся изменения, что постепенно делает продукт совершенным и востребованным.

## Преимущества для стартапа и бизнеса

Запуск MVP снижает финансовые и временные затраты на старте. Наличие работающего продукта, даже с минимальным функционалом, повышает шансы на получение инвестиций, так как демонстрирует жизнеспособность идеи.

Главное преимущество MVP — возможность корректировать курс развития до того, как в разработку полноценной версии будут вложены большие бюджеты.

## Примеры мировых гигантов и локальных кейсов

Многие успешные компании начинали с простых решений, чтобы убедиться в наличии спроса:

* **Airbnb:** Основатели начали с сайта для аренды надувных матрасов в собственном доме, чтобы подтвердить интерес к услуге.
* **Dropbox:** Первым шагом стала простая программа для синхронизации файлов, собравшая отзывы пользователей до расширения функционала.
* **Uber:** Проект стартовал как приложение для вызова такси нажатием одной кнопки, что помогло определить оптимальную стратегию роста.
* **Fiftyfour:** В практике WAPP экосистема для коворкинга также начиналась с MVP — личного кабинета резидента без модуля оплаты, что позволило запустить систему всего за три месяца.

Другие примеры, такие как **Instagram**, **Spotify** и **Slack**, подтверждают: даже масштабные платформы начинались с тестирования одной ключевой функции. **Zappos** проверял спрос на обувь через простой сайт с несколькими моделями, а **Twitter** тестировал интерес к коротким сообщениям в формате микроблога.

## Заключение

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

---

## Blog: Запуск идеи стоит 5 млн, и это дорого. Как сэкономить на проекте? Спойлер: откажитесь от React

- **Slug:** `react-vs-ssr-cost`
- **Locale:** `ru`

К нам часто приходят от других разработчиков. Когда начинаем разбираться, понимаем: заказчику предлагали совершенно ненужные фичи. Эти самые фичи не только растягивают проект по времени, но и повышают его стоимость, а ощутимой пользы не приносят. Пример — рендеринг на сервере в браузере или на стороне клиента. Что это такое?

Рендеринг — это преобразование кода в визуализированную страницу. Самые распространённые типы — на сервере (server side rendering, или SSR) и в браузере клиента (client side rendering, или CSR). В последнее время мы чаще используем серверный рендеринг с помощью технологии HTMX и советуем его заказчикам. В статье расскажем, почему.

> Мы не отказались от React или Vue. js полностью, просто применяем его именно там, где эти технологии действительно требуются.

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

Клиентский рендеринг — более новый способ, который использует JavaScript. Данные преобразуются не на сервере, а прямо в браузере. Сервер передаёт в браузер не готовый к отображению HTML-файл, а лишь его каркас. Вместе с ним передаются файлы JavaScript: они содержат информацию о том, что именно должен увидеть пользователь. Сначала браузер загружает HTML, а потом в файл встраиваются данные из JavaScript — как только данные загружены, пользователь видит страницу и может с ней взаимодействовать.

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

### Первый плюс SSR — скорость разработки
Серверный рендеринг — маст-хэв для бизнесов, которые хотят запуститься быстро. Секрет высокой скорости — более простой код и меньшее количество багов.

С клиентским рендерингом работать сложнее: кода больше. Чтобы хоть как-то ускорить процесс, разработчики используют ресурсозатратные библиотеки или фреймворки, самые популярные из которых — React и Vue. Вычисления происходят не только на сервере, но ещё и в браузере клиента. Усложнённая логика влечёт за собой ошибки, вызванные, в том числе, использованием JavaScipt. На исправление ошибок уходят драгоценные часы.

Мы уже рассказывали историю о том, как выбрали CSR — а потом утонули в багах: файлы оказались слишком тяжёлыми для видеокарт клиента. Мы с нуля переписывали приложение на SSR за свой счёт, а заказчик потерял время.

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

### Второй плюс SSR — экономия денег
Одна из причин, по которой агентства предлагают заказчикам CSR, — высокий чек. Хотя стоимость часа работы при серверном и клиентском рендерингах примерно одинакова, SSR выигрывает за счёт меньшего количества часов. Это влияет на стоимость не только разработки, но и запуска стартапов в целом.

Например, мы делаем зоосправочник ZooBiZoo. Разработка такого сервиса в месяц с применением серверного рендеринга стоила около 700 тысяч рублей. Если бы использовали клиентский рендеринг — вышло бы в районе 800–900 тысяч. Кажется, разница небольшая. Но если посчитать затраты на развитие проекта, экономия может достигать до 1 млн рублей в год. Эти деньги можно спокойно вложить в рекламу.

## Когда React уместен — а когда нет
Всё же бывают случаи, когда CSR нужен. Мы советуем его там, где важны интерактивность и моментальный отклик: в графических и текстовых редакторах типа Canva или Google Docs, проектах гемблинг-индустрии, стриминговых сервисах. SSR прост и удобен — но не создан для того, чтобы «делать красиво». С ним невозможно воплотить задумку со сложной анимацией, которая воспроизводится мгновенно при открытии страницы.

<video src="./videos/14fb91c740a54a178efd87e1084e5a33.webm" muted loop playsInline autoPlay controls={false} className="w-full rounded-2xl my-8" />

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

В целом, рендеринг на сервере — идеальный вариант для проектов со статичным контентом. Как правило, на подобных сайтах возможности React и Vue не используют на полную мощность. Получается, заказчик переплачивает за CSR там, где можно сэкономить.

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

---

## Blog: Launching an idea costs 5M — it's expensive. How to save on your project? Spoiler: say no to React (sometimes)

- **Slug:** `react-vs-ssr-cost`
- **Locale:** `en`

## Introduction

Teams often come to us after another vendor proposed heavy stacks and expensive client rendering where server templates and simple forms would do. Launches are already costly — architecture and JS surface area are a fair place to save.

Below is a practical take on SSR (including HTMX) versus CSR (React/Vue): where you gain speed, where you pay twice, and how to avoid billing for the wrong tool.

## Two rendering models

**SSR** builds HTML on the server; the browser receives a ready page. **CSR** ships a shell and a large bundle that constructs the UI in the browser.

For content- and form-heavy products SSR is usually cheaper to build and easier to maintain. CSR shines when you need deep, frame-critical interactivity on first paint.

## When React is right — and when it is not

Document-class editors, rich visual experiences, streaming — client territory. Typical marketing sites, portals, reporting — often win with server rendering and targeted JS.

The full article with comparison tables and a case study is being migrated into MDX; this file anchors SEO and the blog index.

---

## Blog: SDLC Methodologies Compared: Waterfall, Agile and DevOps in Practice

- **Slug:** `sdlc-methodologies-compared`
- **Locale:** `en`

The Software Development Life Cycle (SDLC), also known as the systems development life cycle, is not a suggestion; it is a manufacturing pipeline and software development process for digital assets. In the business world, code is liability until it is deployed. How you manage that transition from liability to asset determines your ROI, your speed to market, and your technical debt.

Choosing a methodology is a capital allocation and project management decision. Whether you opt for the rigid discipline of Waterfall, the iterative speed of an iterative model like Agile, the risk-focused spiral model, or other software development models like the continuous flow of DevOps, you are making a bet on how your organization handles uncertainty and change. This article deconstructs the SDLC to provide a pragmatic roadmap for that decision.

## The Business Case for Choosing the Right SDLC

Efficiency in software development is measured by the reduction of waste. Waste manifests as unused features, extensive bug fixing, or missed market windows. If you choose the wrong methodology, you are essentially subsidizing inefficiency.

A startup building a disruptive app cannot afford the long lead time of a traditional Waterfall process. Conversely, a bank upgrading its core ledger cannot risk the "move fast and break things" ethos of pure Agile. Your choice of SDLC dictates your cost of failure. By aligning your methodology with your business goals, you minimize the "pivot cost" — the price you pay when reality disagrees with your initial project plan.

## The 7 Standard Stages of the SDLC

The SDLC is often drawn as a straight line. In practice it is a loop, and the methodology you pick decides how tight that loop is.

![Seven SDLC stages arranged as a continuous cycle: Planning, Requirements, Design, Development, Testing, Deployment, Maintenance](./images/sdlc-seven-stages-cycle.webp)

Regardless of the methodology, every software project moves through these seven fundamental stages of the SDLC. The difference lies in how often you repeat them and how much time you spend in each.

### 1. Planning and Requirement Analysis

This is the most critical phase, encompassing comprehensive requirements gathering. You define the "Why." You assess feasibility, allocate resources, identify risks, and may engage in early prototyping. If your planning is flawed, your code is irrelevant. Business leaders, stakeholders and business analysts must define the problem before software engineering teams define the solution.

### 2. Defining Requirements (SRS)

Here, you translate business goals into a Software Requirement Specification (SRS). This document bridges the gap between stakeholders and developers. It defines what the system must do, excluding any ambiguity. In Waterfall, this document is a contract; in Agile, it is a living backlog.

### 3. Product Architecture and Design

Design is not about aesthetics; it's about structure. Architects create the Design Document Specification (DDS), outlining the system design and system architecture, data flow, third-party integrations via APIs, and modularity. Good design, including a robust database design, ensures that a change in one module doesn't collapse the entire stack.

### 4. Building and Developing the Product

This is the execution phase. Developers write the code based on the DDS. If the previous stages were handled correctly, this stage is a mechanical translation of design into logic. If they were skipped, this stage becomes an expensive exercise in improvisation.

### 5. Testing and Quality Assurance

Testing, including rigorous integration testing, system testing, and user acceptance testing, is the gatekeeper of your reputation. You verify that the code meets the SRS requirements and is free of critical bugs. Modern systems prioritize automated unit testing, documented test cases, and peer code reviews to ensure that new code doesn't break old functionality (regression).

### 6. Deployment in the Market

The code moves to the production environment. This can be a release following the big bang model where everything goes live at once, or a "Canary" release where the software is rolled out to a small subset of users to monitor performance.

### 7. Operations and Maintenance

The software development life cycle doesn't end at launch, as it requires a commitment to continuous improvement and robust application lifecycle management. Software is organic; maintenance means updates, patches, security fixes and scaling. A significant share of the total cost of ownership accumulates here rather than during the initial build. Ignore maintenance, and your product will suffer from "bit rot."

## Waterfall: The Linear Path to Predictability

### Structural Logic: The Sequential Flow

The waterfall model is the "measure twice, cut once" approach, often grouped with the V-model and contrasting sharply with the iterative agile model. It is a linear, non-overlapping sequence: Requirements → Design → Implementation → Verification → Maintenance. You cannot move to the next step until the previous one is signed off. It assumes that the requirements are known and will not change.

### When Waterfall Makes Financial Sense

Waterfall is the most efficient choice for fixed-price contracts with static requirements. If you are building a regulated medical device interface or a system with a certified specification, you need the predictability Waterfall provides. It allows for precise budgeting and clear milestones.

### The Hidden Costs of Rigidity

The cost of change in Waterfall grows sharply the later it arrives. A requirement discovered during testing is dramatically more expensive than the same requirement caught during planning, because it invalidates design decisions already implemented. Because testing happens at the very end, you may discover a fundamental flaw only after most of your budget is spent.

### Efficiency Metrics: Predictability vs. Adaptability

Waterfall remains the reference point every other software development life cycle model is measured against.

**Strength:** highly predictable timelines and budget variance.

**Weakness:** near-zero adaptability. If the market shifts mid-project, you are left with a perfectly executed, useless product.

## Agile: Optimizing for Change and Iteration

### The Shift from Projects to Products

Agile treats software as a living product rather than a one-off project. It breaks development into small, time-boxed increments called sprints (usually 2–4 weeks). Each sprint results in a working piece of software. This allows you to pivot based on real-world feedback rather than theoretical assumptions.

### Common Agile Frameworks in Practice

**Scrum:** focused on roles (Scrum Master, Product Owner) and ceremonies (daily standups, sprint retrospectives).

**Kanban:** focused on flow and work-in-progress limits. It visualizes the pipeline to identify bottlenecks.

### Velocity vs. Scope: Managing Client Expectations

In Agile, you don't fix the scope; you fix the time and the resources. You measure velocity — how much work the team completes in a sprint. This requires a shift in mindset: the client must accept that they won't know exactly what the final product looks like on day one, but they will have a working version much sooner.

### The Downside: The "Forever Project" Risk

Without a disciplined Product Owner, Agile can lead to scope creep and never-ending development cycles. Because there is no fixed end date, costs can spiral if the team keeps adding features without ever achieving a definitive version 1.0.

## DevOps: Merging Development and Operations

### Beyond Methodology: A Culture of Continuous Delivery

DevOps is not just a way to write code; it's a way to run a business. It removes the silos between the people who write the software and the people who maintain the infrastructure. The goal is continuous delivery — the ability to push code to production at any time with high confidence.

### The CI/CD Pipeline: Automating the SDLC

The heart of DevOps is the CI/CD pipeline. Continuous integration means every commit is automatically built and tested. Continuous deployment means that if the tests pass, the code moves to staging or production without manual steps. This reduces the human error factor in deployment close to zero.

![CI/CD pipeline: Commit to Build to Tests to Staging to Production](./images/sdlc-cicd-pipeline.webp)

### What the DevOps Advantage Actually Buys You

Teams with mature CI/CD deploy far more frequently than teams relying on manual releases, and they recover from failures faster because each change is small enough to isolate. In business terms: you can respond to a competitor's feature or a critical security bug in hours instead of weeks. Industry benchmarks on deployment frequency and change failure rate are published annually in the DORA State of DevOps reports, and they are worth reading before you commit budget to a transformation.

### Prerequisites for DevOps Implementation

You cannot buy DevOps. It requires investment in automation tooling (Docker, Kubernetes, CI runners), an understanding of microservices, security testing and penetration testing built into the pipeline (DevSecOps), and a cultural shift where developers take responsibility for how their code behaves in the real world.

## Side-by-Side Comparison

![Waterfall, Agile, and DevOps plotted by delivery speed versus predictability](./images/sdlc-approaches-comparison.webp)

| Metric | Waterfall | Agile | DevOps |
|---|---|---|---|
| Timeline | Long (months/years) | Iterative (weeks) | Continuous (hours/days) |
| Delivery speed | Slow | Moderate | Very fast |
| Budgeting | Fixed / predictable | Variable / per sprint | Variable / operationalized |
| Risk management | High, back-ended | Moderate, sprint-level | Low, automated and constant |
| Client involvement | Start and end only | Frequent | Continuous feedback |

### Cost Structure and Budgeting

Each SDLC model distributes spend differently across the timeline.

Waterfall favours capital expenditure with a large upfront investment. Agile and DevOps shift toward operating expenditure, requiring a steady monthly burn rate to maintain a dedicated team.

### Risk Mitigation Strategies

Waterfall mitigates risk through documentation. Agile mitigates risk through frequent demos. DevOps mitigates risk through automation and failing fast on a small scale before issues become systemic.

### Client Involvement and Feedback Loops

Waterfall assumes the client knows what they want. Agile assumes the client thinks they know what they want but will change their mind. DevOps assumes the data will tell everyone what the client actually needs.

## How We Apply This in Practice

Methodology debates are cheap. What matters is which constraints you are actually operating under, and how project management adapts to them. Here is how the choice plays out on real projects at [WAPP](/en/services/mobile-development).

**Fixed scope and a hard deadline → structured delivery.** For [SWAPPZ](/en/project/swappz), a fleet management platform for electric vehicle rental in the UAE, the client needed a working MVP with five user roles inside 90 days. That constraint made the plan non-negotiable: scope was frozen early, architecture decided upfront, and the sprints existed to sequence delivery rather than to renegotiate requirements. Pure Agile would have invited scope creep the deadline could not absorb.

**A live product that cannot go dark → incremental migration.** The corporate site we built for [LIFE PAY](/en/project/life-pay), a payments company, went through several design generations while continuing to generate leads every day. Four template layers coexisted in one codebase, and routes were switched over page by page. Legacy URLs kept working, analytics stayed intact, and the lead funnel was never rewritten from scratch. A big bang release would have cost the client search rankings and attribution data.

**A long-lived system with many editors → maintenance as a first-class phase.** For [Skoltech](/en/project/skoltech), a research university, the platform is operated by more than fifty administrators publishing thousands of pages. Here the interesting work is not the initial build; it is the modular admin, the role model and the release process that let non-developers ship content safely for years after launch.

The pattern across all three: the software development life cycle follows the constraint, not the other way round. Deadline-driven work needs structure. Living products need incremental delivery. Long-horizon systems need maintenance designed in from stage one.

## Common Pitfalls in SDLC Transitions

### The "Agile-in-Name-Only" Trap

Most failed SDLC transitions fall into one of three patterns.

Many companies claim to be Agile but still require fifty-page requirement documents and three months of approvals. This is Waterfall with standups. It offers none of the speed of Agile and all of the confusion of missing documentation.

### Over-Engineering the Pipeline

For a small team, setting up a complex DevOps pipeline can be a waste of time. If you spend forty hours automating a task that takes five minutes once a month, you have failed the business logic test. Automation must have a clear return.

### Ignoring the Human Element

DevOps fails when it's treated as a purely technical problem. If your operations team is incentivized to keep the system stable by saying no to changes, and your development team is incentivized to ship features by saying yes, no amount of automation will fix that conflict of interest.

## The Future of SDLC: AI and Low-Code Integration

The next evolution of the SDLC is the integration of generative AI. We are moving toward a synthetic SDLC where AI handles boilerplate coding and parts of automated testing, allowing humans to focus on planning, requirements analysis and architecture.

Simultaneously, low-code platforms are compressing the life cycle for simple business applications. This doesn't replace the developer; it elevates them. The developer becomes an orchestrator of systems rather than a writer of syntax in a specific programming language. Efficiency will no longer be measured by lines of code, but by the speed of the concept-to-cash cycle.

## Final Assessment: Efficiency is the Only Metric That Matters

There is no best methodology — there is only the methodology that fits your constraints.

Use Waterfall when the cost of an error is physical, regulated or contractual. Use Agile when the market is uncertain and you are still looking for product-market fit. Use DevOps when your software is your business and downtime or slow updates are unacceptable.

The goal of any SDLC is a repeatable, predictable pipeline that delivers value, and sound project management is what keeps it repeatable. If your current process feels like a hurdle rather than a highway, you aren't just using the wrong methodology — you're losing money.

If you are weighing these trade-offs on a specific project, [talk to our team](/en/services/mobile-development). We will map your constraints to a delivery model and give you a realistic scope, timeline and budget before any code is written. For what studios leave out of app quotes — APIs, cloud, AI tokens, compliance — see [Mobile app development cost: the hidden line items](/en/blog/app-development-cost-hidden).

---

## Blog: 30 страниц вместо одного абзаца: почему услуга написания ТЗ на разработку окупается

- **Slug:** `specs-we-write-ourselves`
- **Locale:** `ru`

Почему мы не просим ТЗ от клиента, а составляем его сами. Когда клиент приходит с задачей, можно скинуть ему табличку с брифом и попросить заполнить. Это самый простой путь для разработчиков, но мы так не делаем. Кажется, что это означало бы перекладывать на клиента часть наших задач. В статье расскажем, как общаемся с заказчиками, вникаем в их потребности, составляем для них ТЗ и считаем смету.

## Бриф на разработку приложения: как мы превращаем идеи в структуру

### Словарь: о чем мы вообще говорим на созвонах

Мы не любим грузить терминами, но эти четыре слова — база, на которой строится смета. Если мы понимаем их по-разному, проект улетит в трубу:

* ТЗ — ваша страховка. Это подробная карта проекта, без которой разработка превращается в прогулку по минному полю.
* Функционал — список того, что приложение реально делает. «Хочу, чтобы было красиво» — это не функционал. «Нажать кнопку — получить PDF-отчет» — вот это он.
* Интеграции — «дружба» вашего сервиса с другими (банками, CRM, картами). Это самое дорогое и сложное место, которое нужно прописать сразу, а не в середине разработки.
* Бизнес-процессы — то, как работает ваша компания. Мы их просто перекладываем в код, чтобы менеджеры не делали лишних движений.

### Основные понятия: что важно знать заказчику

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

* Техническое задание (ТЗ) на разработку ПО — это основной документ проекта, который детально описывает бизнес-логику, структуру данных, интерфейсы и технические ограничения будущего продукта.
* Функциональные требования — это описание конкретных действий и задач, которые должна выполнять система в ответ на действия пользователя (например, «регистрация через Telegram» или «выгрузка отчета в PDF»).
* Интеграции — это программные интерфейсы (API), через которые ваш продукт обменивается данными со сторонними сервисами: платежными шлюзами, CRM-системами или службами доставки.
* Бизнес-процессы — это последовательность действий внутри компании, которую мы автоматизируем с помощью программного обеспечения для повышения эффективности.

### Ключевые показатели ТЗ: цифры и факты

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

Мы работаем по прозрачной модели: предварительная оценка и бриф проводятся бесплатно, а итоговая стоимость написания ТЗ фиксируется в договоре и не меняется в процессе проектирования. Это позволяет вам точно планировать бюджет еще до начала основной фазы разработки.

Чтобы лучше понимать масштаб работы, вот несколько усредненных данных из практики WAPP. Эти цифры не просто статистика, а база для оценки окупаемости разработки:

* Средний объем документации: 25–40 страниц (включая BPMN-схемы и описание API). Это уровень детализации, который сводит к минимуму риск ошибки при реализации.
* Экономия бюджета: наличие ТЗ сокращает расходы на непредвиденные правки на 30%. Вы платите за проектирование сейчас, чтобы не переплачивать за переделки потом.
* Глубина проработки: в ТЗ мы описываем минимум 12 ключевых разделов — от ролей пользователей до нефункциональных требований к нагрузке и безопасности.

## Как у нас организовано общение с клиентом перед началом проекта

Со всеми клиентами мы общаемся по одной и той же схеме, независимо от их сферы деятельности.

В первую очередь проводим созвон на полчаса-час, где клиент в свободной форме рассказывает о своем видении продукта и требованиях к нему. Наш сотрудник заполняет бриф по единой форме, то есть мы сразу задаем все самые важные вопросы.

Вот как могут выглядеть ответы:

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

Составляем смету и презентацию, где показываем клиенту важность технического задания как первого этапа работы по проекту. В смете отражаем цену предстоящих работ в диапазоне «от и до», фиксирована только стоимость ТЗ.

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

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

Наша цель — по максимуму раскрыть клиента. Получить от него намного больше информации, чем он мог бы сам рассказать по электронной почте. Ниже примеры того, как это у нас получается.

Клиент пришел с непродуманной идеей предложения, в которой не уточнил ни функционал, ни ЦА, — зато сказал, что хочет ИИ:

Вот как мы ответили:

Иногда бывает, что идея продумана лишь частично. Из предложенной информации нам понятно, что хочет клиент, — но непонятно зачем. Запросы этого типа часто формулируют таким образом: «Сделайте такой же сайт/сервис, как у Х (ЦА и нагрузка не определены)», «Вот ТЗ, функционала на 3–5 месяцев работы, гипотезу не тестировали», «Хотим вот такую штуку, способов монетизации не придумали».

Идею можно считать продуманной, когда у клиента есть бизнес, запрос и ресурсы. Тогда он излагает информацию примерно так:

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

Редко, но случается такое, что на этапе брифования мы видим — клиенту не особо нужен продукт, который он собирался у нас заказать. Не все пожелания можно «докрутить» так, чтобы получилось сначала четкое ТЗ, потом рабочая система или приложение.

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

Очень деликатный момент — как понять, насколько серьезны намерения клиента и до какой степени он готов вовлекаться в проект. Мы полагаемся на свою насмотренность, задаем клиенту вопросы и мониторим спрос, то есть изучаем, какие похожие решения уже есть на рынке и как они сделаны.

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

На пресейлах мы тратим на первый подробный бриф от часа до трех, чтобы точнее просчитать смету. Если это уже не первое касание с клиентом, достаточно еще 1–2 встреч, чтобы прояснить детали, которые не были понятны сначала. Если мы уже работаем над проектом, собрать дополнительную информацию можем без брифа, в процессе.

## Как мы работаем: специализация и стандарты WAPP

Эти 30 страниц ТЗ — не «вода», а фундамент. Мы не просто описываем кнопки, а выстраиваем логику по стандартам (IEEE, BPMN 2.0), чтобы разработка была предсказуемой. Вот на чем держится наша специализация:

* Никакой двусмысленности: мы рисуем схемы бизнес-процессов так, чтобы их понял и заказчик, и разработчик. Это исключает ситуацию, когда программист понял задачу «по-своему» и сделал не то.
* Безопасность и право: сначала подписываем NDA, потом обсуждаем детали. Все наработки хранятся в защищенном контуре, а права на них юридически закреплены за вами.
* Техническая квалификация: каждое ТЗ проверяет техлид. Мы заранее закладываем возможность масштабирования, чтобы при росте нагрузки приложение не пришлось переписывать с нуля.
* Проверка на прочность: мы ориентируемся на стандарты OWASP. Это значит, что защита от взломов и утечек данных прописывается еще на этапе проектирования, а не «когда-нибудь потом».

Вам не нужно быть технарем, чтобы с нами работать. Достаточно рассказать о бизнесе, а мы переведем это на язык системных требований.

Эти 30 страниц — не «вода», а фундамент будущего продукта. Чтобы разработка шла предсказуемо, в состав профессионального ТЗ мы обязательно включаем четыре критических блока:

* Функциональные требования: подробное описание того, что именно должна делать система и как она реагирует на действия пользователя.
* Нефункциональные требования: описание параметров надежности — безопасности данных, скорости отклика интерфейса и возможности масштабирования при росте нагрузки.
* Use Cases (сценарии использования): пошаговое описание путей пользователя, которое позволяет исключить логические ошибки еще на этапе проектирования.
* Интеграционную схему: техническое описание того, как продукт будет обмениваться данными с внешними сервисами (CRM, платежными шлюзами или службами доставки).

## Почему мы пишем ТЗ сами

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

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

Например, однажды мы составили ТЗ на 30 страниц и подробные схемы процессов, отталкиваясь только от созвона с заказчиком и полученной от него картинки:

Хорошо, если клиент может добавить к описанию скриншоты. Это поможет нам составить первичную схему продукта и посмотреть, что в него можно добавить. Мы соберём скриншоты в мудборд и передадим техническому писателю вместе с текстовым описанием. Вот как может выглядеть мудборд:

Вот финальная схема:

Иногда клиенты думают, что приходят к нам с ТЗ. На самом деле они приносят список первоначальных требований к продукту. Рассказывают, какие функции должно выполнять приложение, которое они хотят заказать, и какие фичи нужно в него встроить. Так тоже можно: мы сами разовьем полученную информацию в формат ТЗ.

Бывает, что клиент приходит совсем с минимумом конкретики, даже без требований. Например, просит сделать «как в Авито». И это, поверьте, очень частый запрос! Однако если что-то выглядит как Авито, дышит как Авито и передвигается как Авито — еще не факт, что это Авито.

Площадка, которую клиенты так любят приводить в пример, представляет собой маркетплейс с огромным количеством функций. Мы выясняем, какие именно функции сайта-референса нужны заказчику. К примеру, это может быть платформа для управления театром, которая выглядит как карточки на Авито.

Случается и другая крайность: клиент приносит ТЗ на 70 страниц. Мы его тщательно изучаем, готовим список вопросов и проясняем их на созвоне. Уходим считать смету, встречаемся на втором созвоне-презентации.

## Прозрачная смета на разработку ПО: как ТЗ защищает бюджет

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

К процессу первичного общения с заказчиком мы обычно подключаем программиста. Он нужен, чтобы расчеты с самого начала были точными.

Когда все исходные данные становятся понятны, мы рассчитываем не ориентировочную стоимость продукта, а диапазон. Сообщаем клиенту: «Результат будет стоить не меньше, чем столько-то, и не больше, чем столько-то».

Чтобы сократить расходы клиенту, мы можем предложить более бюджетную версию продукта. Составим отдельную смету для каждой версии. Объясним, чем отличается функционал более простой версии и как можно его апгрейдить в будущем.

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

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

### Прозрачная смета и коэффициент рисков

Диапазон цен в нашей смете — это не неопределенность, а обоснованная математическая модель. Обычно разница между «от» и «до» составляет 15–20%.

Это стандартный коэффициент рисков для ИТ-проектов, который учитывает:

* Отсутствие жесткой фиксации API сторонних сервисов на старте.
* Возможные уточнения бизнес-логики в процессе проектирования.
* Технические нюансы интеграций с CRM или платежными системами.

Наличие подробного ТЗ позволяет сузить этот диапазон до минимума и зафиксировать финальную стоимость разработки.

## Почему нам доверяют: стандарты и практика WAPP

Проектирование в WAPP — это не просто творческий процесс, а работа по строгим отраслевым стандартам, которые дают предсказуемый результат:

* Методология: мы опираемся на международные стандарты (такие как IEEE 29148-2018), что обеспечивает полноту, непротиворечивость и проверяемость каждого требования в ТЗ.
* Визуализация процессов: схемы бизнес-логики разрабатываются в профессиональной нотации BPMN 2.0. Это исключает двоякую трактовку задач разработчиками и позволяет клиенту наглядно увидеть «путь пользователя» до начала кодинга.
* Безопасность и конфиденциальность: работа над проектом начинается только после подписания NDA. Все данные и технические решения хранятся в защищенном корпоративном пространстве с разграничением прав доступа.
* Профессиональная команда: каждое ТЗ проходит внутренний аудит техлида. Мы проектируем решения с учетом будущих нагрузок (scalability) и стандартов безопасности (OWASP), чтобы архитектуру продукта не пришлось переделывать при росте базы пользователей.

---

## Blog: Why we don't ask clients for a spec — we write it ourselves

- **Slug:** `specs-we-write-ourselves`
- **Locale:** `en`

## Introduction

A blunt “send us a spec” request often produces a document that does not match how the business really works. We deliberately own discovery and requirements: interviews, scenario prototypes, acceptance criteria — so team and client share one picture.

That cuts rework cost and speeds up production release.

## Why not “the client writes it alone”

- A spec is a co-created artefact, not homework for the client.
- Without engineering and product input it is easy to bake in the impossible or the wasteful.
- Business language and system language must meet in one document.

## How the process looks

Workshops, user-flow capture, MVP prioritisation, then a scope doc with risks and timelines. A detailed checklist and sample outline will ship in the long-form article.

---

## Blog: Тренды в мобильной разработке 2024 года

- **Slug:** `triendy-v-mobil-noi-razrabotkie-2024-ghoda`
- **Locale:** `ru`

Технологии часто воспринимают как способ пустить пыль в глаза, но в 2024 году ошибка в выборе стека стоит миллионы. Когда приложение для коворкинга или лаборатории падает из-за перегрузки, бизнес теряет не просто лояльность, а реальные контракты и время сотрудников. Технологии должны приносить прибыль, а не становиться статьей расходов, которая бесконечно ест бюджет на поддержку.

## Внедрять ИИ ради сокращения операционных расходов

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

Допустим, Виталий решил внедрить нейросеть в приложение коворкинга только ради того, чтобы профили пользователей выглядели современно. Деньги потрачены, но менеджеры всё так же тратят по 4 часа в день на сверку бронирований. Это пример внедрения ради тренда, которое не несет пользы.

В кейсе Fiftyfour алгоритмы помогают диспетчерам управлять логистикой. Программа сама анализирует данные и строит маршруты, что позволяет:
* Сокращать пробег транспорта за счет точного прогнозирования пробок.
* Уменьшать фонд оплаты труда, так как один диспетчер теперь справляется с объемом задач троих сотрудников.
* Исключать простои оборудования благодаря автоматическим уведомлениям.

## Выбирать кроссплатформенность для снижения стоимости владения

Фреймворки Flutter и React Native в 2024 году окончательно доказали жизнеспособность для крупного бизнеса. Вместо разработки двух отдельных приложений можно создать один продукт, который работает везде.

Такой подход позволяет бизнесу не раздувать штат разработчиков и быстрее выпускать обновления. Использование единого кода дает следующие результаты:

## Использовать дополненную реальность в промышленности

Дополненная реальность (AR) в 2024 году ушла из гейминга в сектор обучения и контроля качества. Для лабораторий это способ застраховать дорогое оборудование от ошибок персонала.

Когда аналитики WAPP работали над проектом SpectroChem, они изучали, как лаборанты взаимодействуют с приборами в сложных условиях. AR-интерфейс помогает сотруднику не отвлекаться на бумажные инструкции:
* Приложение накладывает пошаговый алгоритм действий прямо на изображение прибора через камеру планшета.
* Система блокирует следующий шаг, если лаборант нарушает последовательность анализа.
* Программа автоматически фиксирует время начала и окончания операции для журнала Audit Trail.

## Защищать данные по стандартам финтеха

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

Квалификация команды в создании финтех-решений помогает строить надежную архитектуру. При разработке платформы Xstreet мы внедряли алгоритмы, которые обеспечивают безопасность на каждом уровне:
* Многофакторная аутентификация защищает аккаунты от несанкционированного доступа.
* Сквозное шифрование гарантирует, что данные переписки или транзакций не перехватят в процессе передачи.
* Регулярные автоматические тесты ищут уязвимости в коде до того, как их найдут хакеры.

В проекте Maller мы сами когда-то допустили ошибку в вычислениях на стороне фронтенда. Этот опыт научил WAPP проверять критические узлы системы с десятикратной тщательностью, особенно в вопросах безопасности.

## Управлять физическими активами через IoT

Интернет вещей (IoT) в 2024 году связывает софт с реальными объектами. Приложение превращается в инструмент контроля, который собирает данные без участия человека.

Это особенно важно для управления инфраструктурой:
* Датчики в коворкингах помогают оптимизировать расходы на электроэнергию и отопление.
* Умные замки позволяют гостям заходить в здание по QR-коду без участия администратора.
* Системы мониторинга в лабораториях следят за температурой в холодильниках с реактивами 24/7.

## Обеспечивать доступность через PWA

Прогрессивные веб-приложения (PWA) позволяют пользователю получить доступ к сервису без скачивания из магазинов. В 2024 году это лучший способ сократить путь клиента от первого клика до целевого действия.

PWA работает в браузере, но по функционалу не уступает нативным приложениям. Это идеальный формат для сервисов, где важна скорость и отсутствие лишних барьеров.

## Заключение

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

---

## Blog: Почему лаборанты саботируют LIMS и как этого избежать

- **Slug:** `why-lab-staff-bypass-lims`
- **Locale:** `ru`

Сайт или система лежат. Или, что еще хуже, работают, но сотрудники их игнорируют. Компания внедряет лабораторную информационную систему (LIMS), чтобы оцифровать процессы и уверенно проходить аудит по ГОСТ ISO/IEC 17025. Но спустя месяц руководитель приходит в лабораторию и видит прежнюю картину: лаборанты записывают показатели в тетрадях и Excel-таблицах, а в программу вбивают только итоговые цифры перед уходом домой. И, казалось бы, всё работает — не трогай. Но в голове предпринимателя ситуация выглядит иначе. Инвестиции в автоматизацию не окупаются — программа вызывает глухое сопротивление команды. В этой статье мы затронем тему, как починить вовлеченность сотрудников в LIMS.

## Как дорогие программы становятся подставками для кофе

Решение о цифровизации лаборатории редко принимается спонтанно. Как правило, этому предшествуют проигранные тендеры из-за медленной выдачи протоколов или болезненные предписания проверяющих инстанций. Руководство выделяет бюджет, выбирает поставщика с дашбордами в презентации и издает приказ: «С понедельника работаем по-новому».

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

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

## Почему лаборанты фиксируют показатели на листочках

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

Виталий подходит к компьютеру, на котором открыта LIMS. Чтобы внести одну цифру, лаборант вынужден:
1. Снять перчатки, потому что тачпад или сенсорный экран на них не реагирует.
2. Ввести пароль, так как сессия истекла ради безопасности.
3. Найти нужную пробу в реестре из тысячи строк.
4. Открыть форму, состоящую из двадцати полей, половина из которых обязательна для заполнения.

Виталий не глупый и не ленивый сотрудник. Он поставлен в условия, где интерфейс противоречит физической реальности. Чтобы не сорвать ход химической реакции, лаборант берет ручку и пишет массу на бумажной салфетке или на тыльной стороне ладони. Внедрение неудобной программы провоцирует саботаж на местах.
![Пример реальной рабочей LIMS клиента](./images/2f48aabb0b4245a5a7447f0ae92d058c.webp)

## Цена опечатки при переносе данных в Excel

Когда первичные данные временно живут на салфетках, они неизбежно перетекают в Excel. Это выглядит компромиссом для персонала, пока не срабатывает человеческий фактор.

Представьте компанию «Икс», которая занимается контролем качества входящего сырья на производстве. Из-за неудобной LIMS их сотрудники вели черновые расчеты в электронных таблицах. В один из дней уставший лаборант ошибся ячейкой при копировании поправочного коэффициента. Неверный результат пошел в официальный протокол, и компания «Икс» забраковала партию сырья стоимостью в десятки миллионов рублей. Когда поставщик провел независимую проверку и вскрыл ошибку в расчетах, компании «Икс» пришлось не только возмещать убытки, но и защищать свою аккредитацию в суде. 

Электронные таблицы создают иллюзию контроля. В них легко сломать формулы случайным нажатием, невозможно достоверно отследить историю изменений и нельзя гарантировать защиту от подтасовки результатов. Использование Excel в аккредитованной лаборатории — это мина замедленного действия под репутацией.

## Почему аналитикам нужно стоять за спиной у лаборанта

Команда WAPP придерживается правила: система подстраивается под человека, а не ломает привычки. Об этом пишут в книгах по дизайну интерфейсов, но на практике аналитики редко отрываются от офисных кресел.

При разработке системы для проекта [СпектроХим](/ru/project/spektrokhim) первой задачей было не писать код, а погрузиться в процессы лаборатории. Аналитики созванивались по видеосвязи и смотрели, как работают люди. Приехать лично возможности не было, так как лаборатория проводит межлабораторные сличительные испытания (МСИ), и туда ограничен доступ. 

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

Решение, которое устранит саботаж команды — интеграция LIMS с аналитическими весами и титраторами. Команда WAPP может внедрить такую технологию. Лаборанту больше не нужно ничего вводить руками: он ставит бюкс на весы, нажимает кнопку на самом приборе, и цифра мгновенно улетает в базу данных протокола.

![LIMS разработанная WAPP](./images/74710fd2efb04c5db1c930b507ba15b6.png)

## Как автоматизировать ВЛК по ГОСТ ISO/IEC 17025

Главная боль аккредитованной лаборатории — это требования стандарта ГОСТ ISO/IEC 17025. Необходимость вести тотальный внутрилабораторный контроль (ВЛК), строить контрольные карты Шухарта и скрупулезно фиксировать Audit Trail (цифровой след изменений) часто парализует основную работу.

Вспомним ВЛК по методам органолептического анализа. Аудиторы регулярно запрашивают подтверждение ежедневного медосмотра сотрудников — например, фиксацию отсутствия насморка или аллергии перед допуском к пробам. В бумажном виде это превращается в бесконечную кипу формальных журналов, которые заполняются задним числом. В правильной LIMS этот процесс вшит в утреннюю авторизацию: система может при входе на работу автоматически измерять температуру, подтверждая самочувствие, и алгоритм сразу формирует электронный журнал здоровья. То же самое касается микробиологии: контроль качества питательных сред можно оцифровать, навсегда избавив персонал от ручных записей.

В коробочных решениях сбор данных обычно реализован «в лоб»: программа заставляет лаборанта на каждый чих писать объяснительную записку и подтверждать каждое мелкое действие электронной подписью. Это вызывает обоснованное раздражение.

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

Еще один барьер — обязательная выгрузка данных в государственные реестры. Многие лаборатории (особенно пищевого и ветеринарного профиля) вынуждены дублировать результаты из таблиц в федеральные информационные системы, такие как ФГИС «ВЕСТА» или ЕИАС. Это двойная работа и риск опечаток. Если у системы есть открытый API, можно настроить интеграцию с государственными порталами и отправлять валидированные протоколы в один клик.

Когда придет комиссия из контролирующих органов, сотрудникам не придется ночами переписывать бумажные журналы. Администратор выгрузит лог аудита за требуемый период и покажет инспектору прозрачность процессов. Цифровой контур защищает лабораторию от претензий при проверках.

## Скрытая стоимость владения коробочными LIMS

Выбирая программу, руководство часто смотрит только на стоимость первичной лицензии. Готовая LIMS кажется выгодной сделкой. Но дьявол кроется в стоимости владения (TCO).

Дешевая «коробка» предлагает закрытый код и жестко зашитые бизнес-процессы. Как только лаборатории понадобится добавить нестандартную формулу расчета для новой ГОСТ-методики или интегрировать программу с корпоративной 1С, выяснится, что каждый час доработок стоит сотни тысяч рублей, а ожидание в очереди на техническую поддержку занимает месяцы.

Бизнес-процессы компаний часто уникальны. Например, для сети коворкингов Fiftyfour мы настраивали сложную кастомную систему бронирования и учета, а маркетплейс Xstreet рассчитывает сложное сплитование платежей. Коробочные решения не справятся с такими задачами без тотальной переделки.

Разработка кастомной LIMS обходится дороже на старте, но окупается тем, что инструмент работает точно по процессам лаборатории. Лаборатория не переплачивает за сотни функций, которые ей не нужны, и получает открытый API для будущих интеграций.

## Бесплатная LIMS для небольших лабораторий

Для маленьких лабораторий со штатом до 10 человек мы готовы бесплатно предоставить нередактируемую базовую LIMS (которую мы показывали на вебинаре) и сделать небольшие доработки в обмен на подробную обратную связь. 

Чтобы получить доступ к системе, оставьте заявку на нашем сайте и напишите в сообщении: «Бесплатная LIMS для маленьких лабораторий». *Предложение ограничено, мы можем отказать в предоставлении доступа без объяснения причин.*

## Как архитектура серверов влияет на скорость LIMS

В IT-разработке не бывает безгрешных команд. В 2021 году команда WAPP разрабатывала сложный цифровой продукт Maller — сервис для подготовки и просчета стоимости рекламы, а также сбора ключевых слов в Яндекс Директ. В погоне за визуальной скоростью разработчики приняли архитектурное решение: перенесли вычислительные процессы на сторону фронтенда (в браузер пользователя). На тестовых стендах с компьютерами разработчиков всё летало. Но когда продукт ушел в «поле», где пользователи открывали его с дешевых планшетов и офисных ноутбуков, интерфейс начал тормозить. 

Разработчики переписали архитектуру: вычисления унесли на бэкенд, а фронтенду оставили задачу по отображению данных. Этот опыт изменил подход к проектированию. Теперь при создании LIMS закладывается условие, что программа должна моментально работать даже на слабом железе с нестабильным Wi-Fi в подвальном помещении лаборатории. Вся математика по обработке хроматограмм и расчету неопределенности происходит на серверах, а пользователь получает быстрый интерфейс без зависаний.

## Как оцифрованные данные помогают масштабировать лабораторию

Допустим, внедрение LIMS завершилось. Сотрудники привыкли к интерфейсу, лаборанты перестали ошибаться при вводе, а протоколы выдаются клиентам вдвое быстрее. Что делать с высвободившимся ресурсом команды?

Автоматизация превращает накопленные данные в актив. Программа больше не работает как простое хранилище цифр — она выполняет роль бизнес-аналитика. Руководитель видит себестоимость каждого анализа с учетом потраченных реактивов, амортизации и времени работы приборов. 

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

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

## Как сделать так, чтобы всё получилось

Главная ошибка перед разработкой LIMS — прийти к подрядчику с желанием «сделать как в той программе, только удобнее». 

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

Если пока трудно разобраться в тонкостях собственных бизнес-процессов и сформировать задание на сотню страниц, мы рекомендуем начать с простого: нарисуйте схему процессов (интеллект-карту). Разложите путь образца от момента въезда курьера на территорию центра до отправки закрывающих актов в ЭДО. Опишите, кто конкретно и что именно делает на каждом этапе. 

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

<a href="https://docs.google.com/spreadsheets/d/1bJ1-oCf_W9CQ-iI4ZfBdrF5zDY5dXVH_AiFNlVxrCko/edit" rel="nofollow">*Таблица для анализа LIMS*</a>

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

Подробнее о подходе WAPP к лабораторному софту — на странице [решений для лабораторий](/ru/solutions/chem-lab), в разделе [LIMS](/ru/solutions/chem-lab/lims) и в [кейсе СпектроХим](/ru/project/spektrokhim).

## Частые вопросы о внедрении LIMS

### Почему сотрудники обходят новую LIMS?

Чаще всего интерфейс спорит с реальной работой у прибора: мелкие кнопки, вложенные меню, лишние поля. Лаборант в перчатках выбирает Excel или бумагу — это быстрее и привычнее. Пока система не упрощает смену, саботаж остаётся рациональным выбором.

### С чего начать, если Excel уже «держит» лабораторию?

С карты процессов: путь образца от приёмки до протокола, где ручной ввод и дублирование. Без схемы любая LIMS внедряется вслепую. Разбор порядка работ — в статье [«Автоматизация лаборатории: с чего начать»](/ru/blog/lab-automation-where-to-start).

### LIMS и платформа СпектроХим — это одно и то же?

Нет. LIMS ведёт жизненный цикл пробы внутри лаборатории. [СпектроХим](/ru/project/spektrokhim) — платформа межлабораторных проверок квалификации. Оба продукта лабораторные, но задачи разные.

### Можно ли начать с бесплатной базовой LIMS?

Для небольших лабораторий (ориентир до 10 человек) WAPP предлагает базовый контур без лицензии: очередь и готовность к публичному кейсу. Срочно или под NDA — коммерческий трек. Условия — на странице [LIMS](/ru/solutions/chem-lab/lims).

---

## Blog: Why lab staff bypass LIMS — and how to stop it

- **Slug:** `why-lab-staff-bypass-lims`
- **Locale:** `en`

The site or the system is down. Or worse — it works, and the team ignores it. A company rolls out a laboratory information management system (LIMS) to digitize processes and pass ISO/IEC 17025 assessments with confidence. A month later the manager walks into the lab and sees the old picture: analysts write readings in notebooks and spreadsheets, and type final numbers into the program only before going home. On the surface everything “works — don’t touch it.” In the founder’s head it looks different: automation spend does not pay back, and the software meets quiet resistance. This article is about how to repair engagement with LIMS.

## How expensive software becomes a coffee coaster

Lab digitalization is rarely a whim. It usually follows lost tenders because protocols ship too slowly, or painful findings from assessors. Leadership allocates a budget, picks a vendor with shiny dashboards in the pitch deck, and issues an order: “From Monday we work the new way.”

The first weeks look promising. The vendor trains staff; an admin creates accounts. Then the system meets daily load in the middle of a shift — and the process breaks.

First, chemists complain that the app is slow. Then it turns out registering an urgent sample requires a full client card even though the contract is not signed yet. Tasks that used to take five minutes stretch to half an hour. Quiet rebellion grows in break rooms, and the interface becomes a storefront for auditors — disconnected from what happens on the benches.

## Why analysts write numbers on sticky notes

Say Vitaly works a lab shift. He stands at a fume hood. Thick nitrile gloves on his hands, safety goggles on his face. Sample prep is running, a hot plate is heating, a centrifuge is spinning. He needs to capture an exact weight now.

Vitaly walks to the PC with LIMS open. To enter one number he must:
1. Remove gloves — the trackpad or touchscreen does not respond through them.
2. Enter a password because the session timed out for security.
3. Find the sample in a registry of a thousand rows.
4. Open a form with twenty fields, half of them required.

Vitaly is not stupid or lazy. He is stuck in a UI that contradicts physical reality. To keep the reaction on track, he grabs a pen and writes the mass on a paper napkin or the back of his hand. An awkward system invites floor-level sabotage.
![Example of a real client LIMS in daily use](./images/simple-lims-en.png)

## The cost of a typo when copying into Excel

When primary data lives on napkins for a while, it inevitably moves into Excel. That feels like a compromise for staff — until human error hits.

Imagine company X that QC-checks incoming raw materials. Because LIMS was awkward, people kept draft calculations in spreadsheets. One day a tired analyst copied a correction factor into the wrong cell. The wrong result entered the official protocol, and company X rejected a raw-material batch worth tens of millions. When the supplier ran an independent check and exposed the calculation error, company X had to cover losses and defend its accreditation in court.

Spreadsheets create an illusion of control. Formulas break with one accidental keystroke, change history is unreliable, and results can be altered without a trustworthy trail. Excel in an accredited lab is a slow fuse under reputation.

## Why analysts need to stand behind the chemist

WAPP’s rule: the system adapts to people — it does not break habits. Interface books say that; in practice analysts rarely leave office chairs.

On the [Spektrokhim](/en/project/spektrokhim) project the first job was not code — it was immersing in lab processes. Analysts joined video calls and watched how people worked. Visiting on site was not possible: the lab runs interlaboratory comparisons (proficiency testing), and access is restricted.

Standard desktop web patterns failed in this niche. The team dropped deep nested menus and overloaded screens. Instead they used one screen — one primary action. Font contrast went up so text stays readable through fogged goggles, and hit targets grew large enough that thick gloves on a tablet cannot miss.

The change that kills sabotage is instrument capture: LIMS talking to analytical balances and titrators. WAPP can ship that integration. The analyst no longer types: they place the vessel on the balance, press the instrument button, and the value lands in the protocol record.

![LIMS designed by WAPP](./images/lab-cabinet-en.png)

## How to automate internal quality control under ISO/IEC 17025

The hard part for accredited labs is ISO/IEC 17025: internal quality control, control charts, and a scrupulous Audit Trail that often paralyzes core work.

Take internal QC for organoleptic methods. Assessors regularly ask for proof of daily staff fitness checks — for example, confirming no cold or allergy before tasting. On paper that becomes endless formal logs filled after the fact. In a well-designed LIMS the step sits in morning sign-in: the system can capture temperature or a health confirmation and build an electronic fitness log. The same idea applies in microbiology: media QC can be digitized so staff stop writing it by hand.

Boxed products often implement logging “head-on”: the app forces an explanation and an e-signature for every tiny action. That irritation is earned.

Good architecture makes the trail a background process. If an analyst corrects a parallel determination after a technical error, the system stores in a protected table who changed what, when, from which IP, and which value.

Another barrier is mandatory export into national registries. Many food and veterinary labs still duplicate results from tables into government information systems. That is double work and typo risk. With an open API you can send validated protocols to those portals in one click.

When inspectors arrive, staff should not rewrite paper journals overnight. An admin exports the audit log for the period and shows a clear process trail. A digital contour protects the lab during assessments.

## The hidden cost of owning a boxed LIMS

When picking software, leadership often looks only at the license price. A ready LIMS looks like a bargain. The devil is total cost of ownership (TCO).

A cheap “box” means closed code and hard-wired processes. The moment the lab needs a non-standard formula for a new method, or an integration with corporate ERP, each customization hour costs heavily — and support queues stretch for months.

Business processes are often unique. For the Fiftyfour coworking network we built custom booking and accounting; the Xstreet marketplace needs complex payment splitting. Boxed tools do not absorb that without a full rewrite.

Custom LIMS costs more upfront and pays back because it follows lab processes. The lab does not pay for hundreds of unused features and gets an open API for future integrations.

## Free LIMS for small labs

For small labs of roughly up to 10 people we can provide a base, non-editable LIMS free (the version we showed on a webinar) and do light adaptations in exchange for detailed feedback.

To request access, submit a form on the site and write in the message: “Free LIMS for small labs.” *The offer is limited; we may decline access without explaining the reason.*

## How server architecture affects LIMS speed

IT teams are not flawless. In 2021 WAPP built Maller — a service for ad cost planning and keyword collection. Chasing perceived UI speed, engineers moved heavy computation into the browser. On developer machines it flew. In the field — cheap tablets and office laptops — the UI stalled.

The team rewrote the architecture: computation moved to the backend; the frontend only rendered data. That experience changed how we design. For LIMS we now assume the app must feel instant even on weak hardware and unstable Wi‑Fi in a basement lab. Chromatography math and uncertainty calculations run on servers; the user gets a UI without freezes.

## How digitized data helps the lab scale

Suppose LIMS is live. Staff know the UI, typing errors drop, protocols reach clients twice as fast. What do you do with the freed capacity?

Automation turns stored data into an asset. The system is no longer a number warehouse — it acts as a business analyst. Leadership sees cost per test including reagents, depreciation, and instrument time.

Hiring and onboarding get clearer too. Algorithms for analyst work live in the system, so a newcomer can follow a digitized procedure step by step from day one.

A lab director opens a dashboard and sees an equipment heat map. They notice a gas chromatograph sits idle on Tuesdays and Thursdays and run a targeted offer for those analyses. The lab can scale and take twice as many commercial orders without hiring more people.

## How to make the rollout succeed

The main mistake before building LIMS is asking a vendor to “make it like that product, but nicer.”

Whether you buy a box or commission a custom build, you need a process map first. WAPP writes the specification: we interview lab staff, collect pain points, and document the workflow for every role.

If a hundred-page brief feels impossible, start simple: draw a process map (mind map). Trace the sample from courier arrival to closing documents in e-workflow. Say who does what at each step.

To simplify vendor choice, WAPP prepared a comparison table of popular market options.

<a href="https://docs.google.com/spreadsheets/d/1bJ1-oCf_W9CQ-iI4ZfBdrF5zDY5dXVH_AiFNlVxrCko/edit" rel="nofollow">*LIMS analysis spreadsheet*</a>

It includes hidden criteria: seamless database export if you leave a vendor, and validation documentation for external assessors.

More on WAPP’s approach to lab software — on the [chemical labs solutions](/en/solutions/chem-lab) page, the [LIMS](/en/solutions/chem-lab/lims) page, and the [Spektrokhim case](/en/project/spektrokhim).

## Frequently asked questions about LIMS rollout

### Why do staff bypass a new LIMS?

Usually the UI fights real bench work: tiny controls, nested menus, extra fields. With gloves on, Excel or paper is faster. Until the system shortens the shift, bypass is a rational choice.

### Where should we start if Excel already runs the lab?

With a process map: the sample path from intake to certificate, and where dual entry happens. Without that map, any LIMS ships blind. Walkthrough — in [Lab automation: where to start](/en/blog/lab-automation-where-to-start).

### Is LIMS the same as Spektrokhim?

No. LIMS runs the sample lifecycle inside your lab. [Spektrokhim](/en/project/spektrokhim) is a proficiency testing / ILC platform. Same industry, different jobs.

### Can we start with a free base LIMS?

For small labs (roughly up to 10 people) WAPP offers a base contour without a license fee: a queue and willingness to publish a case. Urgent or NDA work — commercial track. Terms — on the [LIMS](/en/solutions/chem-lab/lims) page.

---

## Blog: Как мы помогли запустить приложение для маркета кроссовок Xstreet

- **Slug:** `xstreet-marketplace-app`
- **Locale:** `ru`

## Введение

Xstreet — маркет кроссовок, где важны доверие к сделке, скорость публикации лотов и понятный путь покупателя. Мы сфокусировались на MVP: минимальный набор сценариев, который можно запустить и измерить, без «вечного» фронтенд-монолита.

## Что вошло в первую волну

- Роли и базовый онбординг продавца.
- Каталог, карточка товара, коммуникация по сделке.
- Админские и модерационные точки — настолько, насколько нужно для запуска.

## Технический акцент

Там, где критичны данные и скорость вывода фич, опирались на серверный рендеринг и ясные формы; интерактив — точечно. Развёрнутый кейс с архитектурой и метриками — в полной статье.

---

## Blog: How we helped launch the Xstreet sneaker marketplace app

- **Slug:** `xstreet-marketplace-app`
- **Locale:** `en`

## Introduction

Xstreet is a sneaker marketplace where transaction trust, fast listing, and a clear buyer journey matter. We focused the MVP on the smallest scenario set you can ship and measure — without an endless frontend monolith.

## What shipped first

- Roles and lightweight seller onboarding.
- Catalogue, product detail, and deal communication.
- Just enough admin and moderation to go live.

## Technical emphasis

Where data and feature throughput dominated, we leaned on server rendering and explicit forms; interactivity stayed targeted. Architecture notes and metrics will appear in the long-form case study.

---

## Portfolio: ALLO Messenger

- **Slug:** `allo-messenger`
- **Locale:** `ru`

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

[ALLO](https://allo.love/) — мессенджер, который WAPP собирает как рабочую альтернативу. Шифрование включено сразу. Чаты и звонки живут в одном приложении. Канал остаётся доступным, когда основной стек приложений ведёт себя непредсказуемо.

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

## Какую задачу ставил заказчик

Мессенджером должны пользоваться в быту и на работе. Без рекламной ленты, без лишних каналов поверх переписки и без квеста «где включить защиту».

Параллельно — устойчивость, когда часть сети режется или остаются только «одобренные» сервисы. У человека должен оставаться отдельный контур общения, а не единственный государственный мессенджер по умолчанию.

С первого дня важно было закрыть четыре вещи. Без них продукт не имеет смысла как ежедневный инструмент:

- переписка и звонки с защитой сразу, без ручной настройки;
- привычный набор: чаты, группы, медиа, истории — чтобы не уговаривать людей терпеть урезанный MVP;
- приватность под контролем пользователя: номер, время захода, устройства, чёрный список;
- живая поддержка: продукт молодой, идеи из обратной связи попадают в дорожную карту.

Публичное описание продукта — на [allo.love](https://allo.love/). Ниже — как это выглядит в интерфейсах, которые уже собраны.

## Как человек попадает в чаты

Онбординг ведёт сразу к переписке: язык, welcome, номер, код — и приложение. Не десять экранов настроек перед первым сообщением.

## Как устроены чаты и группы

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

## Как устроены контакты и профиль

Поиск и добавление контактов, карточка с номером и статусом, экран профиля. Что видят другие — решает пользователь на понятных экранах, а не в скрытом меню из десяти пунктов.

## Как устроены безопасность и приватность

Сквозное шифрование переписки включается автоматически. Аудио- и видеозвонки защищены сразу. Можно скрыть номер, время захода, фото и статус. Список устройств и активных сеансов — в одном месте: проще понять, кто ещё вошёл в аккаунт.

## Что делает WAPP на проекте

WAPP ведёт продуктовую разработку: клиентские приложения, сервер, звонки, сценарии приватности и релизы. Задача студии — держать связку «приложение работает → человек может писать и звонить», в том числе после публичного запуска.

На сайте ALLO команда прямо пишет, что путь только начался, но поддержка уже отвечает. Идеи из обратной связи попадают в развитие. Функции и стабильность наращиваем релизами.

## На чём держится устойчивость канала

Мессенджер — не только экраны чата. Критичны доставка сообщений, медиа, сессии устройств, звонки и правила доступа к данным профиля. Контур собран так, чтобы:

1. защита и приватность были состоянием по умолчанию, а не опцией «для параноиков»;
2. звонки и чаты жили в одном продукте — без перехода в сторонние приложения;
3. продукт можно наращивать итерациями (истории, группы, демонстрация экрана), не ломая сценарий «написал → дошло → позвонил».

Точный стек и внутренние схемы в открытый кейс не выносим. Для заказчика важнее результат на стороне пользователя и устойчивость канала.

## Что уже есть

- Публичный продукт и сайт: [allo.love](https://allo.love/).
- В приложении и макетах: онбординг, чаты и группы, контакты, профиль, приватность.
- Дальше — функции и стабильность под нагрузку и обратную связь из поддержки.

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

---

## Portfolio: ALLO Messenger

- **Slug:** `allo-messenger`
- **Locale:** `en`

A familiar messenger stops opening: filtering, an allowlist, or pressure to “just use the one official channel.” The question left is where to write and call — without ads and without hunting for security settings.

[ALLO](https://allo.love/) is the messenger WAPP is building as a working alternative. Encryption is on from the start. Chats and calls live in one app. The channel stays usable when the usual app stack becomes unpredictable.

The brief was not a checkbox clone. It was a fallback communication contour: protection by default, familiar flows, and control over what others see.

## What the client needed

People should use the messenger in daily life and at work. No ad feed, no extra channels on top of chat, and no scavenger hunt for where to turn protection on.

In parallel — resilience when parts of the network are cut or only “approved” services remain. Users need a separate communication contour, not only a single state messenger by default.

Four things had to work from day one. Without them the product fails as an everyday tool:

- messaging and calls with protection on immediately, no manual setup;
- a familiar set: chats, groups, media, stories — so people are not asked to endure a stripped MVP;
- privacy under user control: number, last seen, devices, blocklist;
- human support: the product is young, and feedback feeds the roadmap.

The public product description is on [allo.love](https://allo.love/). Below — how that looks in the interfaces already built.

## How people reach chats

Onboarding goes straight to messaging: language, welcome, phone, code — then the app. Not ten settings screens before the first message.

## How chats and groups work

Personal and group threads include files, reactions, replies, and search. A group is more than a message feed: members, settings, and admin rights sit next to the conversation. No jump to another app to add someone or change permissions.

## How contacts and profile work

Search and add contacts, a card with number and status, a profile screen. What others see is decided on clear screens — not in a buried menu of ten items.

## How security and privacy work

End-to-end encryption for chats turns on automatically. Audio and video calls are protected from the start. Users can hide number, last seen, photo, and status. Device list and active sessions live in one place — easier to see who else is signed in.

## What WAPP does on the project

WAPP runs product development: client apps, backend, calls, privacy flows, and releases. The studio’s job is to keep the loop “app works → people can write and call,” including after the public launch.

On the ALLO site the team says the path has only started, but support already replies. Ideas from feedback go into the roadmap. Features and stability grow release by release.

## What keeps the channel resilient

A messenger is more than chat screens. Message delivery, media, device sessions, calls, and profile access rules all matter. The contour is built so that:

1. protection and privacy are the default state, not an option “for paranoids”;
2. calls and chats live in one product — no jump to third-party apps;
3. the product can grow in iterations (stories, groups, screen share) without breaking “wrote → delivered → called.”

We do not publish the exact stack and internal diagrams in the open case. For the client, what matters is the user-side result and channel resilience.

## What is already live

- Public product and site: [allo.love](https://allo.love/).
- In the app and layouts: onboarding, chats and groups, contacts, profile, privacy.
- Next — features and stability under load and support feedback.

If you need a full messenger with encryption, calls, and privacy controls — especially as a fallback channel outside a single imposed app — the conversation starts with the user scenario and channel risks, not a slideshow of pretty screens.

---

## Portfolio: Интеграция и автоматизация сети коворкингов

- **Slug:** `coworking-spb`
- **Locale:** `ru`

Развитие этого проекта — работа с высоконагруженной системой в реальном времени. Наша задача состояла в том, чтобы устранить технические барьеры, мешавшие росту продаж, и автоматизировать взаимодействие с резидентами. [cite_start]Благодаря точечным архитектурным улучшениям мы стабилизировали финансовый контур и упростили ежедневную работу персонала.

## Проблема: финансовые разрывы и избыточная рутина

В процессе эксплуатации выявились критические узкие места:

- **Ошибки оплаты:** Платежный виджет работал нестабильно, а неоплаченные заказы искажали аналитику доступности мест.
- **Непрозрачность ресурсов:** Резиденты с длительными тарифами не видели детализацию остатка часов на текущий месяц.
- [cite_start]**Ручной контроль:** Администраторам приходилось вручную отслеживать сроки окончания контрактов и напоминать о продлении.

## Что мы сделали: от багов к автоматизации

[cite_start]Мы провели серию спринтов, сфокусированных на стабильности и пользовательском опыте, соблюдая строгие стандарты безопасности данных.

**1. Финансовый контур и фискализация:**

- **Авто-отмена заказов:** Реализован скрипт, аннулирующий неоплаченные брони через 15 минут. Это освободило дефицитные ресурсы для других клиентов.
- **Гибридные платежи:** Разработана логика разделения заказов. Если клиент совмещает оплату «часами» из пакета и деньгами, система формирует два отдельных запроса, при этом в официальный фискальный чек попадает только денежная транзакция.
- [cite_start]**Умные возвраты:** Внедрена система мгновенных уведомлений о причинах отказа в возврате средств (например, недостаток баланса на стороне шлюза).

**2. Управление ресурсами:**

- **Детализация лимитов:** Переработано отображение остатков. Теперь резидент видит лимит именно на текущий расчетный период и дату его обновления.
- [cite_start]**Трекинг изменений:** Внедрена система логирования действий сотрудников: кто активировал «заморозку», когда и на какой срок.

## Технологии и безопасность

Мы использовали **Laravel** для доработки бэкенда и **Telegram API** для автоматизации уведомлений. [cite_start]Система автоматически информирует администраторов о завершении тарифов и отправляет клиентам персональные ссылки на оплату в мессенджеры, синхронизируя историю с CRM-системой.

## Функциональные модули

### 01. Контроль бронирования и доступ

Мы стабилизировали интерфейс календаря и устранили ошибки выбора времени. Восстановлена работа модулей генерации цифровых ключей доступа (QR-кодов) из панели администратора. Стабильный интерфейс снижает число ошибок бронирования и нагрузку на техподдержку.

### 02. Биллинг и коммуникации

Система стала точнее в расчётах: убрано излишнее округление сумм, обновлены шаблоны автоматических писем. Каждый этап взаимодействия с клиентом подкреплён корректным юридическим и финансовым уведомлением.

### 03. Продвинутое администрирование

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

## Команда проекта

**Настя** — Project Manager. [cite_start]Координировала реализацию более чем 10 критических задач, обеспечивая бесперебойную работу системы в процессе обновлений.

**Дима** — Fullstack Developer. [cite_start]Отвечал за исправление багов интерфейса, настройку серверных задач и логику отображения ресурсов.

**Андрей** — Backend Developer. [cite_start]Реализовал интеграцию с платежными шлюзами, логику гибридных платежей и Telegram-ботов для уведомлений.

**Евгения** — QA Engineer. [cite_start]Провела полное тестирование финансовых сценариев и процессов автоматической отмены заказов.

**Максим** — Founder / CTO. [cite_start]Технический аудит архитектуры, настройка серверной инфраструктуры и контроль безопасности данных.

## Что дальше

Контур автоматизации коворкинга — бронь, платежи, доступ — на странице [решений для коворкингов](/ru/solutions/coworking). Публичный соседний кейс запуска пространства — [Fiftyfour](/ru/project/fiftyfour).

---

## Portfolio: PropTech: Coworking network integration and automation

- **Slug:** `coworking-spb`
- **Locale:** `en`

Delivery meant operating a high-load, real-time system. We removed technical friction that blocked sales growth and automated resident-facing workflows. [cite_start]Targeted architectural work stabilised the financial stack and simplified day-to-day operations for staff.

## Problem: payment gaps and manual overhead

Operations surfaced several bottlenecks:

- **Unstable checkout:** The payment widget failed intermittently, and unpaid holds skewed availability analytics.
- **Opaque allowances:** Long-term members could not see a clear breakdown of remaining hours for the current cycle.
- [cite_start]**Manual follow-ups:** Staff tracked contract renewals and reminders by hand.

## What we shipped: from bugfixes to automation

[cite_start]We ran focused sprints on reliability and UX while keeping strict data-security practices.

**1. Payments and fiscal compliance**

- **Auto-cancel holds:** Unpaid reservations are released after 15 minutes, freeing scarce resources for other customers.
- **Hybrid payments:** When a booking mixes package hours and card money, the system issues two requests while only the cash leg hits the fiscal receipt.
- [cite_start]**Return transparency:** Instant messaging explains gateway declines (for example insufficient balance).

**2. Resource management**

- **Allowance clarity:** Balances now reflect the current billing window with a clear renewal date.
- [cite_start]**Audit trail:** Staff actions such as “freezes” are logged with actor, time window, and duration.

## Technology and security

We extended the **Laravel** backend and used the **Telegram API** for notifications. [cite_start]The stack warns admins before tariffs lapse and sends residents personalised payment links, keeping history aligned with the CRM.

## Product modules

### 01. Booking and access

We stabilised the calendar UI and fixed time-selection bugs. Digital access keys (QR) can again be generated from the admin panel, reducing support load from bad bookings.

### 02. Billing and communications

Rounding rules were tightened and transactional email templates refreshed so each step ships the right legal and financial context.

### 03. Advanced administration

Organisation profiles became more flexible, and marketing automation for reminders can be toggled from a single control.

## Team

**Nastya** — Project Manager. [cite_start]Coordinated delivery across ten-plus critical workstreams while keeping production stable during releases.

**Dima** — Fullstack Developer. [cite_start]Owned UI defects, scheduled jobs, and how resource limits render in the product.

**Andrey** — Backend Developer. [cite_start]Implemented gateway integrations, hybrid payment flows, and Telegram notification bots.

**Evgeniya** — QA Engineer. [cite_start]Exercised financial scenarios end-to-end, including auto-cancel paths.

**Maxim** — Founder / CTO. [cite_start]Architecture review, infrastructure, and data-security oversight.

---

## Portfolio: Fiftyfour: Цифровая экосистема коворкинга

- **Slug:** `fiftyfour`
- **Locale:** `ru`

Кейс Fiftyfour начался в 2020 году. Клиент планировал запуск большого пространства для ИТ-команд, но понимал: вести учет резидентов, переговорных и залов в таблицах — путь к операционному провалу. Мы получили запрос на создание экосистемы, которая объединит бронирование, биллинг и маркетинговые инструменты.

## Проблема: Хаос ручного бронирования

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

**Что мы предложили:**
- **Личный кабинет резидента:** полная автономность клиента — от выбора места до оплаты.
- **Интерактивная карта:** визуальное отображение локаций и их текущего статуса.
- **Модуль администратора:** мощная панель управления на базе Laravel Nova для контроля всех бизнес-процессов.

## Как это работает: Технологии и UX

Мы выбрали стек **Laravel + Vue.js** для гибкости и скорости работы. Использование **Laravel Nova** позволило быстро развернуть административную панель с глубокими правами доступа и отчетностью.

**Ключевые фичи:**
- **Сложные заказы:** Резидент может собрать корзину: рабочее место на месяц + переговорная на четверг + зал для митапа в субботу.
- **Умные статусы:** Система автоматически аннулирует бронирования, если они не были оплачены в течение 24 часов (для предварительных записей).
- **Автоматизация договоров:** Шаблоны формируются онлайн, резиденту остается только зайти и подписать бумажную версию в офисе.

## Результат: Бизнес на автопилоте

За 3 месяца мы запустили MVP, а затем еще полгода планомерно расширяли функционал. 

Клиент получил инструмент, который не просто фиксирует брони, а помогает зарабатывать: маркетологи Fiftyfour теперь сами создают акции (например, скидки на переговорки для постоянных резидентов), а руководство видит эффективность каждого менеджера через детальные отчеты.

## Функциональные модули

### 01. Личный кабинет резидента

### 02. Кабинет администратора (ERP)

### 03. Интеграции и фискализация

## Команда проекта

**Максим** — CTO. Выбор архитектурного стека и контроль за масштабируемостью системы для возможности подключения новых филиалов.

**Виктор Павловский** — Fullstack-разработка. Реализовал весь функционал проекта: от бэкенда и интеграций до клиентской части и админ-панели.

## Что дальше

Подход к бронированию, биллингу и доступу для коворкингов — на странице [решений для коворкингов](/ru/solutions/coworking). Разбор запуска системы бронирования — в [статье о Fiftyfour](/ru/blog/kak-zapustit-sistemu-bronirovaniya-dlya-kovorkinga-opyt-fiftyfour).

---

## Portfolio: FiftyFour

- **Slug:** `fiftyfour`
- **Locale:** `en`

Краткий итог проекта.

## 01. Задача
Описание...

## 02. Решение

---

## Portfolio: Glinka Digital

- **Slug:** `glinka-digital`
- **Locale:** `ru`

---

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

## Как мы запускались: два года и три попытки

История Глинки началась для нас два года назад. Мы считали смету, обсуждали архитектуру, но клиент уходил пробовать другие команды. Один подрядчик не вытянул звук, второй — стабильность мобильного приложения.

Только на третий раз, когда цена ошибки стала критической, мы пожали руки и начали работать всерьез. Наша задача была не просто «написать код», а выпустить продукт, который наконец-то полетит.

## Проблема: почему Zoom убивает музыку

Стандартные сервисы видеосвязи (Zoom, Skype, Meet) созданы для голоса. Их алгоритмы безжалостно обрезают всё, что кажется «шумом»: обертоны скрипки, затухание фортепиано, высокие ноты вокала. Для профессионального обучения это профнепригодно.

## Технологии против «костылей»

Мы не стали собирать «франкенштейна». В основе — **Matrix** для чатов и кастомный **WebRTC** для связи. Бэкенд на **Laravel** ведёт логику, **React Native** — чтобы ученик мог заниматься с iPad или телефона из любой точки мира.

## Результат

## Функциональные модули

## Команда проекта

## Что дальше

---

## Portfolio: Glinka Digital

- **Slug:** `glinka-digital`
- **Locale:** `en`

Glinka is a long trust cycle: the client came to us three times, left twice for cheaper bids, and came back each time when "faster and cheaper" meant a product that did not work.

## How we started: two years and three attempts

For us, the Glinka story began two years ago. We scoped the work and debated architecture; the client still went to other shops. One vendor could not deliver acceptable audio; another could not stabilize the mobile app.

Only on the third pass, when the cost of another failure became too high, we shook hands and went all in. The job was not "write some code" but ship something that would finally fly.

The negotiation and vendor churn phase ran for roughly two years, but the **active build** on our side took **just four months** — from fall through spring. That let the client move into testing instead of another endless "almost there" prototype.

## The problem: why Zoom breaks music

Mainstream video stacks (Zoom, Skype, Meet) are tuned for speech. Their DSP happily kills anything that looks like "noise": violin partials, piano decay, high vocal notes. For professional teaching that is a hard no.

**What we did:**

- **Audio without the censorship layer:** we dug into WebRTC and turned off the stock noise suppression. The teacher hears the instrument, not a digital caricature.
- **Native modules:** off-the-shelf React Native tooling did not give the camera control we needed. We rewrote part of the stack so we could switch to a true wide-angle view — essential to see a pianist's hand technique.

## Stack instead of duct tape

We did not stitch a monster. **Matrix** handles messaging; a custom **WebRTC** path carries the lesson. **Laravel** runs business logic on the server; **React Native** puts the classroom on an iPad or phone anywhere with a network.

## Outcome

The product is live. Right now the first **200** teachers are on a controlled rollout. The blunt lesson: with the right engineering culture, even a "cursed" startup can turn into a business that actually runs.

## Product modules

### 01. Dashboards: one learning ecosystem

### 02. Calls without clutter

### 03. Metronome in the lesson screen

## Project team

**Nastya** — Project Manager. She is the person who kept the project with the studio. For two years she steered negotiations, estimate rounds, and client advice while the client tried other vendors. Once engineering started in earnest, she held communication together and kept delivery on schedule.

**Andrey** — Mobile Developer. He implemented the demanding WebRTC layer on React Native. His main wins were native module work for lens switching and streaming video without noticeable lag.

**Dima** — Backend Developer. He built the Laravel architecture, integrated Matrix for messaging, and wired S3 so lesson recordings are available without friction.

**Evgeniya** — QA Engineer. She walked every usage path that mattered: call stability when jumping from Wi‑Fi to 4G, and audio fidelity across tablet and phone models.

**Maksim** — Founder / CTO. Technical oversight, stack choice (WebRTC + Matrix), and final product quality control.

## What’s next

WAPP’s EdTech approach — lessons, portals, and content protection — is on the [education solutions](/en/solutions/edtech) page. A related multi-branch school case — [Future Volleyball School](/en/project/future-volleyball-school).

---

## Portfolio: Jordan Peterson: Глобальное продвижение

- **Slug:** `jordan-peterson`
- **Locale:** `ru`

Кейс доктора Питерсона — это не про сложную архитектуру, а про **высокую цену ошибки**. Нам доверили развернуть 12 лендингов — от сербского и арабского до китайского и японского. Работа шла в режиме «нужно вчера», когда правки вносились глубокой ночью, чтобы утром сайт в другом полушарии открылся уже обновленным.

## Задача: Конвейер для мирового бренда

Цель была простой на бумаге, но сложной в логистике: создать и обслуживать сеть сайтов для продвижения книг, сбора пожертвований и публикации лекций. 

**География проекта:**
Арабский (ОАЭ), китайский, французский, корейский, португальский (Бразилия), немецкий, испанский, индонезийский, малайский, русский, суахили (Танзания), сербский и японский.

## Что мы сделали: Инфраструктура под ключ

Мы взяли на себя полный цикл обслуживания — от покупки доменов в экзотических зонах до настройки почтовых серверов.

- **Локализация без границ:** 12 лендингов с уникальным контентом на 5 экранов: биография, презентация книг, знаменитые «правила жизни», видео-лекции и блок донатов.
- **Финансовый контур:** Интегрировали систему пожертвований с возможностью разовых взносов и автоматических ежемесячных платежей. Эти средства напрямую шли на оплату работы огромной переводческой команды.
- **Безопасность данных:** Пользователи оставляют личные данные и платежную информацию. Мы настроили серверы с повышенными требованиями к защите и автоматическим резервным копированием.

## Технологии: Простота для администратора

Для управления контентом мы выбрали **October CMS**. Это позволило менеджерам Sapient самостоятельно править тексты или менять ссылки на видео без риска «сломать» верстку или архитектуру сайта. 

Для автоматизации сборки и ускорения тестирования использовали **Gulp**, что помогло выпускать обновления сразу для всей сети сайтов в считанные минуты.

## Результат

Клиент получил полностью автономную сеть сайтов, которая помогла расширить аудиторию проекта далеко за пределы англоязычного мира. Мы доказали свою компетентность в работе с крупными международными клиентами, где надежность и соблюдение дедлайнов важнее любых архитектурных изысков.

---

### Функциональные блоки

### 01. География присутствия

### 02. Контент и Видео

### 03. Система пожертвований

## Команда проекта

**Дима** — Frontend Developer. Реализовал адаптивную верстку на October CMS, обеспечив идеальное отображение лендингов на любых устройствах.

**Максим** — CTO. Технический надзор и выбор стека, гарантирующего простоту управления контентом для клиента.

---

## Portfolio: Jordan Peterson

- **Slug:** `jordan-peterson`
- **Locale:** `en`

Краткий итог проекта.

## 01. Задача
Описание...

## 02. Решение

---

## Portfolio: LIFE PAY: корпоративный сайт платёжной компании с воронкой заявок

- **Slug:** `life-pay`
- **Locale:** `ru`

Маркетинговый сайт life-pay.ru, CMS для блога и маркетплейса, административная панель и лид-хаб с интеграциями. Проект прошёл несколько поколений редизайна без остановки лидогенерации.

**Отрасль:** FinTech  
**Период:** 2017–2019  
**Стек:** Laravel 5.4, Vue 2, MySQL, Docker

## Задача

LIFE PAY продаёт онлайн-кассы, эквайринг и фискальные решения. Сайт для такой компании работает не как витрина, а как основной канал заявок: посетитель приходит по рекламе, выбирает решение, оставляет контакты, и заявка должна дойти до отдела продаж без потерь.

Требовалось закрыть четыре задачи одновременно:

- собрать публичный сайт с продуктовыми страницами, блогом, новостями и маркетплейсом;
- построить воронку заявок с нескольких источников: формы сайта, лендинги на Tilda, партнёрский API, Telegram-бот;
- дать маркетингу инструмент управления контентом без участия разработчиков;
- не сломать существующие URL и сквозную аналитику при обновлении дизайна.

## Дизайн

Главная страница пришла от стороннего подрядчика. Остальной сайт спроектирован в WAPP: 18 макетов в Figma — продуктовые лендинги касс, партнёрская страница, пульт для партнёров, служба поддержки, страницы оплаты, отзывы, новости, блог, контакты, страница 404.

Отдельно собран UI-kit: типографика, кнопки, поля форм, иконки и цветовые переменные. Дальше все новые страницы собирались из этих элементов, а не рисовались с нуля.

## Четыре поколения интерфейса в одной кодовой базе

Самая нетривиальная часть проекта. За время работы сайт пережил несколько редизайнов, и в кодовой базе одновременно жили четыре слоя шаблонов: `old`, `site`, `new` и `reboot`.

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

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

К моменту завершения работ флагманским был слой `reboot` — на нём главная, кассы, эквайринг, розница, услуги, новости, отзывы. Часть юридических и продуктовых страниц продолжала работать на старых шаблонах, потому что переписывать их не было смысла.

**Масштаб:** около 150 Blade-шаблонов и 20 Vue-компонентов, ~80 маршрутов, 24 миграции базы данных.

## Административная панель

Панель управления сделана как SPA на Vue с авторизацией через JWT — около 14 экранов. Формы строятся из схем моделей на бэкенде, поэтому добавление новой сущности не требует отдельной вёрстки.

Что получила команда контента:

- **Блог** — полное управление записями, отложенная публикация, загрузка изображений через редактор;
- **Маркетплейс** — карточки партнёрских решений с управлением публикацией;
- **Заявки** — список с фильтрами по дате, источнику, статусу в CRM и партнёру, выгрузка в XLS;
- **Клиенты** — поиск по телефону, имени и email.

Удаление везде мягкое: записи помечаются неактивными, а не стираются.

## Воронка заявок

Заявки приходили из четырёх источников, и каждый требовал своей обработки: формы на сайте, лендинги на Tilda, партнёрский API с проверкой ключа, Telegram-бот с деревом диалога.

Путь заявки:

1. Валидация и нормализация данных, определение источника, партнёра и UTM-меток
2. Сохранение в базу, создание карточки клиента при новом номере
3. Подписка на рассылку, если посетитель её выбрал
4. Передача во внешнее ядро обработки заявок
5. Уведомление в рабочий чат отдела продаж с полным контекстом: имя, контакты, источник, партнёр, метки

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

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

**За период 2017–2018 через воронку прошло около 5900 заявок и 3500 клиентов.**

## Что осталось за границами проекта

Личный кабинет, интернет-магазин, платёжный и фискальный контур — отдельные системы компании на своих поддоменах. Сайт с ними не пересекался: заявка передавалась во внешнее ядро через API, дальше её обрабатывала CRM.

Логика распределения заявок между менеджерами тоже жила во внешнем ядре. Задача сайта — собрать заявку, обогатить её данными об источнике и доставить без потерь.

## Стек

**Бэкенд:** PHP, Laravel 5.4, MySQL  
**Фронтенд:** Vue 2, Webpack, Gulp  
**Инфраструктура:** Docker, GitLab CI  
**Интеграции:** amoCRM, Telegram Bot API, Mailchimp, Google Analytics, Яндекс.Метрика, GTM, Adspire, CityAds, DaData

Похожий контур — продуктовые страницы, CMS и воронка заявок — закрываем на услуге [разработки веб-приложений](/ru/services/web-applications).

---

## Portfolio: LIFE PAY: corporate website for a payments company with a lead funnel

- **Slug:** `life-pay`
- **Locale:** `en`

Marketing site for life-pay.ru, a CMS for the blog and marketplace, an admin panel and a lead hub with integrations. The project went through several redesign generations without stopping lead generation.

**Industry:** FinTech  
**Period:** 2017–2019  
**Stack:** Laravel 5.4, Vue 2, MySQL, Docker

## Challenge

LIFE PAY sells online cash registers, acquiring and fiscal solutions. For a company like this the website is not a brochure — it is the main lead channel: a visitor arrives from ads, picks a product, leaves contacts, and the lead must reach sales without loss.

We had to close four jobs at once:

- ship a public site with product pages, blog, news and a marketplace;
- build a lead funnel from several sources: site forms, Tilda landings, partner API, Telegram bot;
- give marketing a way to manage content without developers;
- keep existing URLs and end-to-end analytics intact while updating the design.

## Design

The homepage came from an external contractor. The rest of the site was designed at WAPP: 18 Figma frames — cash-register product landings, partner page, partner console, support service, payment pages, reviews, news, blog, contacts, 404.

A UI kit was assembled separately: typography, buttons, form fields, icons and colour variables. New pages were composed from these elements instead of being drawn from scratch.

## Four UI generations in one codebase

The hardest part of the project. Over time the site went through several redesigns, and four template layers lived in the codebase at once: `old`, `site`, `new` and `reboot`.

That was not negligence — it was necessity. Switching a large site to a new design overnight means losing rankings on old URLs and breaking end-to-end analytics. So the migration was gradual:

- a new layer was added next to the existing ones, with its own templates and asset build;
- routes were flipped page by page;
- legacy pages kept serving from the old layer, so links and bookmarks stayed intact;
- the lead funnel stayed unified: forms from every generation posted to one handler.

By the end of the engagement the flagship layer was `reboot` — homepage, cash registers, acquiring, retail, services, news, reviews. Some legal and product pages stayed on older templates because rewriting them was not worth it.

**Scale:** about 150 Blade templates and 20 Vue components, ~80 routes, 24 database migrations.

## Admin panel

The control panel is a Vue SPA with JWT auth — about 14 screens. Forms are built from backend model schemas, so adding a new entity does not need a separate layout.

What the content team got:

- **Blog** — full post management, scheduled publishing, image upload in the editor;
- **Marketplace** — partner solution cards with publish controls;
- **Leads** — list with filters by date, source, CRM status and partner, XLS export;
- **Clients** — search by phone, name and email.

Deletes are soft everywhere: records are marked inactive instead of being wiped.

## Lead funnel

Leads arrived from four sources, each with its own handling: site forms, Tilda landings, partner API with key checks, Telegram bot with a dialogue tree.

Lead path:

1. Validate and normalise data, detect source, partner and UTM tags
2. Save to the database, create a client card for a new phone number
3. Subscribe to the newsletter if the visitor opted in
4. Hand off to the external lead-processing core
5. Notify the sales chat with full context: name, contacts, source, partner, tags

The reverse loop ran through an amoCRM webhook: when a manager changed deal status, the site received the event, matched it to the original lead and passed the conversion into analytics. That made it possible to count closed deals by ad source — not just form submits.

Attribution was built separately: source tags were stored in cookies and session on the first visit and still reached the lead even if the visitor returned later from another page.

**In 2017–2018 the funnel processed about 5,900 leads and 3,500 clients.**

## Outside the project scope

The client portal, online store, payment and fiscal stack were separate company systems on their own subdomains. The site did not overlap with them: a lead was sent to the external core via API, then handled in CRM.

Lead distribution among managers also lived in the external core. The site’s job was to collect the lead, enrich it with source data and deliver it without loss.

## Stack

**Backend:** PHP, Laravel 5.4, MySQL  
**Frontend:** Vue 2, Webpack, Gulp  
**Infrastructure:** Docker, GitLab CI  
**Integrations:** amoCRM, Telegram Bot API, Mailchimp, Google Analytics, Yandex Metrica, GTM, Adspire, CityAds, DaData

A similar scope — product pages, CMS and a lead funnel — is covered on our [web application development](/en/services/web-applications) page.

---

## Portfolio: Pokepok: приложение для концентрации при СДВГ

- **Slug:** `pokepok`
- **Locale:** `ru`

Борьба с СДВГ — это не просто забывчивость, это постоянный поиск стимулов. Проект **Pokepok** начинался как попытка создать «цифровой костыль», который за счёт дофаминовых петель и геймификации поможет мозгу удерживать фокус. Но в процессе разработки мы поняли: никакое приложение не станет «волшебной таблеткой».

## Эволюция стека: от веба к нативному приложению

Первоначальный прототип мы собрали на **Laravel и HTMX**. Это позволило быстро проверить механику в вебе. Однако внимание человека с СДВГ — ресурс мобильный. Помощь нужна здесь и сейчас, поэтому мы перешли к разработке полноценного приложения на **React Native**.

**Выбранная архитектура «Local-first»:**
* **Локальное хранилище:** Все данные живут на устройстве. Это позволяет работать без интернета, не давая пользователю повода зайти в сеть и случайно «провалиться» в ленту соцсетей.
* **Редкая синхронизация:** Сервер используется только как бэкап, чтобы данные не терялись при смене устройства. Это обеспечило максимальную приватность и мгновенный отклик интерфейса.

## Почему мы решили не выпускать продукт

В процессе разработки мы осознали, что рынок перенасыщен качественными решениями (например, **Habitica**), которые проработаны гораздо глубже. Но была и более важная, внутренняя причина.

С появлением тренда на **вайб-кодинг (vibe coding)** стало понятно: сегодня каждый может собрать инструмент «под себя», под свои уникальные триггеры и привычки. Массовое, жестко структурированное приложение — это компромисс, который не всегда оправдан. 

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

## Функционал и дизайн

### 01. Экраны приложения: тишина и порядок

### 02. Компоненты и элементы системы

## Основные вызовы

* **Алгоритмы внимания:** Мы проектировали дофаминовые петли, которые поддерживают мотивацию, но не вызывают привыкания к самому приложению.
* **Секретность данных:** Личная информация о привычках и здоровье резидентов зашифрована. Мы понимаем, что это «слишком» личные данные, которые не должны покидать устройство пользователя.

## Команда проекта

**Сергей** — Product Design. Искал баланс между простотой и функциональностью, чтобы интерфейс не отпугивал, а помогал формировать привычки.

**Андрей** — Fullstack Developer. Реализовал переход от HTMX к React Native и выстроил оффлайн-архитектуру с локальным хранилищем.

**Максим** — Management. Отвечал за стратегию и принял решение о смене курса проекта в пользу более честного и рационального подхода к проблеме концентрации.

---

## Portfolio: Pokepok: ADHD focus app on React Native

- **Slug:** `pokepok`
- **Locale:** `en`

Краткий итог проекта.

## 01. Задача
Описание...

## 02. Решение

---

## Portfolio: RailMarket: маркетплейс заявок на железнодорожные перевозки

- **Slug:** `railmarket`
- **Locale:** `ru`

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

Клиенту нужна была площадка, где грузоотправители и операторы подвижного состава находят друг друга онлайн, договариваются о цене и доводят сделку до подписанных документов. На старте проект шёл под рабочим именем eVagon; в релиз и в дизайн вышел как **RailMarket** — веб-сервис под рынок железнодорожных перевозок в России и СНГ.

## 01. Задача

Собрать приложение для логистики ж/д грузоперевозок, в котором:

* отправитель публикует заявку на перевозку и ищет подходящие вагоны;
* оператор публикует подвижной состав и ищет груз;
* стороны ведут переписку, согласуют цену и сроки;
* система ведёт отраслевой документооборот: договор, счёт, форма ГУ-12;
* служба поддержки и администраторы видят компании, заявки и переписки в отдельной панели.

Срок — шесть месяцев. В работе участвовали четыре специалиста WAPP: аналитика, дизайн, фронтенд и бэкенд.

## 02. Три кабинета — три роли

В продукте не один «общий» личный кабинет, а три контура с разными задачами в цепочке грузоперевозок.

### Кабинет грузоотправителя

Регистрация компании, профиль, список заявок на перевозку. Сценарий «Отправить груз»: станции отправления и назначения, тип груза, тип вагонов, даты подачи. В результатах — подходящий подвижной состав; дальше заявка уходит оператору на расчёт. Есть поиск на карте (Яндекс.Карты) и переговоры по статусам заявки.

### Кабинет оператора подвижного состава

Управление парком вагонов, сценарий «Найти груз», фильтры по станциям, датам, типу груза и статусу. Из карточки заявки оператор отправляет предложение: даты подачи, стоимость без НДС, сообщение отправителю. Статусы сделки: новая → оформление → выполняется → выполнена (плюс отмена).

### Администрирование в продукте

Помимо кабинетов отправителя и оператора, в сервисе есть контур управления сотрудниками компании (роли, активация, доступы). Отдельно была платформенная админ-панель на React Admin: компании, заявки, переписки, вагоны и технические перевозки — для поддержки и супервизоров площадки.

## 03. Что сделали в продукте

### Регистрация, профиль и заявки на перевозку

Форма регистрации разделяет роли sender и operator. В кабинете видны заявки и предложения, смена статуса и история переписки. Уведомления — в интерфейсе и по почте.

### Поиск с фильтрами и картой

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

### Переговоры и предложение цены

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

### Документооборот: ГУ-12, договоры, комиссия и НДС

Это сердце кейса с точки зрения отраслевой компетенции — сильнее списка фреймворков.

После взаимного согласия RailMarket не «забывает» сделку в чате:

1. **Договор** собирается автоматически в PDF из данных заявки на перевозку и реквизитов сторон (шаблоны под нормы работы с ОАО «РЖД»).
2. **Счёт на оплату** считается с учётом комиссии площадки и НДС — формулы зафиксированы в API, а не в Excel у менеджера.
3. Стороны скачивают документы, подписывают и **загружают сканы обратно** в сервис.
4. Отправитель указывает **номер формы ГУ-12** — заявка на перевозку грузов железнодорожным транспортом; номер виден контрагенту в карточке сделки.
5. Оба кабинета видят этап документооборота онлайн: кто подписал, что загружено, на каком статусе перевозка.

Так площадка закрывает не только matching «вагон ↔ груз», но и финальный контур, без которого ж/д логистика в России не считается закрытой сделкой.

### Наблюдаемость

На клиенте — Google Tag Manager (воронка и действия пользователей). Бэкенд: Express и MongoDB, почта через Yandex SMTP; для сопровождения — Telegram-бот. Деплой через PM2.

## 04. Технологии

Стек по репозиториям 2019–2020 (клиент на React/Next, не на Vue).

**Клиент (кабинеты отправителя и оператора):** Next.js 9, React 16.9, Material-UI 4, Redux / Redux-Saga, Яндекс.Карты, GTM.

**Админ-панель:** React Admin 2.x, Material-UI, русская локализация.

**API:** Node.js, Express 4, MongoDB / Mongoose 5, JWT, генерация PDF (html-pdf + EJS), Nodemailer, node-schedule, Telegram Bot API, Swagger.

## 05. Результат

Клиент получил рабочий маркетплейс логистики ж/д грузоперевозок: заявки на перевозку, поиск вагонов и груза, переговоры, отраслевой документооборот (ГУ-12, договоры, комиссия и НДС) и прозрачный статус сделки. Три кабинета закрывают отправителя, оператора и команду площадки.

Для WAPP кейс — якорь рядом с [управлением флотом SWAPPZ](/ru/project/swappz) и хабом [автоматизации логистики](/ru/solutions/logistics). Если смотрите на электронный документооборот перевозок сейчас — см. разбор [электронных путевых листов и ЭТрН с сентября 2026](/ru/blog/electronic-waybills-and-etn-from-september-2026).

Шесть месяцев: маркетплейс железнодорожных грузоперевозок с заявками, ГУ-12 и автоматическими договорами.

## Нужна площадка или кабинет под перевозки?

Собираете маркетплейс, TMS или кабинет для отправителей и перевозчиков — разберём процесс документооборота и matching и скажем, что автоматизировать первым.

[Обсудить проект](#contact) — также [решения для логистики](/ru/solutions/logistics), [кейс SWAPPZ](/ru/project/swappz) и [статья об ЭПЛ и ЭТрН](/ru/blog/electronic-waybills-and-etn-from-september-2026).

---

## Portfolio: RailMarket: marketplace for rail freight requests

- **Slug:** `railmarket`
- **Locale:** `en`

In rail freight logistics, matching wagons and cargo long meant phone calls, spreadsheets, and personal networks. Shippers could not see available rolling stock in one place. Operators could not browse freight requests by station and dates. Document flow — price, contract, and form GU-12 — was done by hand.

The client needed a marketplace where shippers and rolling-stock operators find each other online, agree on price, and close with signed documents. Early working name was eVagon; the product shipped and was designed as **RailMarket** — a web service for railway freight in Russia and the CIS.

## 01. Brief

Build a logistics product for rail cargo where:

* a shipper posts a freight request and searches for wagons;
* an operator manages rolling stock and searches for cargo;
* both sides chat, agree on price and loading windows;
* the system runs industry document flow: contract, invoice, GU-12;
* platform admins see companies, proposals, and conversations in a separate panel.

Timeline: six months. Four WAPP specialists covered discovery, design, frontend, and backend.

## 02. Three cabinets

### Shipper cabinet

Company registration, profile, and freight request list. “Send cargo”: origin/destination stations, cargo type, wagon types, loading dates. Results show matching stock; the shipper can request a quote. Map search (Yandex Maps) and status-based negotiation sit in the same flow.

### Operator cabinet

Fleet management, “Find cargo”, filters by stations, dates, cargo type, and status. From a request card the operator sends an offer: loading dates, price ex-VAT, and a message. Deal statuses: new → formalizing → in progress → done (plus canceled).

### Admin and company staff

Besides shipper and operator cabinets, the product includes company staff management (roles, activation, access). Separately, a platform React Admin app covered companies, proposals, conversations, and wagons for support staff.

## 03. Product scope

### Profile, search, negotiation

Registration splits `sender` and `operator`. Search uses cargo/wagon types, dates, stations, and radius. After mutual agreement the parties chat with price and loading windows; admins can join when needed.

### Document flow: GU-12, contracts, commission and VAT

1. **Contract** PDF from the freight request and counterparty details.
2. **Invoice** with platform commission and VAT calculated in the API.
3. Parties download, sign, and **upload signed files**.
4. Shipper enters the **GU-12** number on the deal card.
5. Both cabinets see document progress online.

### Stack (2019 repos)

**Client:** Next.js 9, React 16.9, Material-UI 4, Redux/Saga, Yandex Maps, GTM  
**Admin:** React Admin 2.x  
**API:** Node.js, Express 4, MongoDB/Mongoose 5, JWT, HTML-to-PDF, Nodemailer, Telegram bot, Swagger  

## 04. Outcome

A working logistics marketplace for railway freight: freight requests, search, negotiation, industry document flow (GU-12, contracts, commission, VAT), and clear deal status across three cabinets.

See also [SWAPPZ fleet management](/en/project/swappz), the [logistics solutions hub](/en/solutions/logistics), and [electronic waybills / e-TN](/ru/blog/electronic-waybills-and-etn-from-september-2026).

Six months: a rail freight marketplace with requests, GU-12, and auto-generated contracts.

## Need a freight marketplace or cabin?

Building a marketplace, TMS, or shipper/carrier portal — we map document flow and matching first.

[Discuss the project](#contact) — also [logistics solutions](/en/solutions/logistics) and [SWAPPZ](/en/project/swappz).

---

## Portfolio: Skoltech

- **Slug:** `skoltech`
- **Locale:** `ru`

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

Сайт: [skoltech.ru](https://www.skoltech.ru/).

Собрали платформу для университета: фронтенд и админка с модульной системой блоков, ролевым доступом и версиями для слабовидящих.

## Задача

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

**Что требовалось закрыть:**

- независимые модули компонентов, чтобы администраторы собирали страницы по дизайн-системе;
- ролевую модель: разные люди ведут контент, доступ к сущностям — разноуровневый;
- логику брендбука: цвета, отступы, начертания — без поломки схем;
- соответствие ГОСТ для сайтов образовательных учреждений;
- динамические фильтры для программ, курсов, учреждений и всего, что фильтруется;
- кастомный календарь расписания учебных семестров;
- мультиязычность с разным контентом для языковых версий.

## Модульная система компонентов

На страницу можно добавлять блоки и менять их местами. Для каждого типа блоков заложена система отступов — дизайн не разъезжается.

Блоки разделены по объёму функционала:

- компактные — для сквозных модулей: баннеры, формы, выпадающие списки;
- крупные — принимают входящие данные и показывают категории: лаборатории, профессора, образовательные программы, новости центра.

Разобраться со структурой связей и доступно организовать панель управления для такой иерархии — отдельная инженерная задача, не «ещё один WordPress с темой».

## Система цветовых пресетов

Каждый цвет брендбука записан в переменную. Из переменных собираются наборы, из наборов — готовые пресеты для основных разделов сайта. Для одного из разделов предусмотрен случайный выбор цветового набора при каждой загрузке страницы.

## Доступность: 4 альтернативные версии

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

## Результаты

По данным Яндекс.Метрики за июнь–август 2026:

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

## Отзыв клиента

## Стек

Vue, Laravel, MySQL. Контур — публичный сайт университета и админка контента, а не онлайн‑уроки в реальном времени. Соседние EdTech-кейсы с другим фокусом: [Glinka Digital](/ru/project/glinka-digital) и [Future Volleyball School](/ru/project/future-volleyball-school). Общий подход — на странице [решений для образования](/ru/solutions/edtech).

---

## Portfolio: Skoltech

- **Slug:** `skoltech`
- **Locale:** `en`

Skoltech is an international university that trains technology, science, and business leaders, runs frontier research, and helps bring technologies to market. WAPP built the public site and admin panel: editors assemble pages from modules themselves, without constant designer or developer tickets.

Site: [skoltech.ru](https://www.skoltech.ru/).

A university platform: frontend and admin with modular blocks, role-based access, and accessibility themes for low-vision users.

## Challenge

Skoltech is a large organization with a complex internal hierarchy. The site had to reflect the institute’s directions, and the content team needed to manage entities without tangled relationships.

**What had to ship:**

- independent component modules so admins can assemble pages within the design system;
- a role model: different people own content, with multi-level access to entities;
- brand-book logic: colors, spacing, type — without breaking schemes;
- GOST compliance for educational institution websites;
- dynamic filters for programs, courses, institutions, and anything else filterable;
- a custom calendar for academic semester schedules;
- multilingual publishing with different content per locale.

## Modular component system

Editors can add blocks to a page and reorder them. Each block type has a spacing system so the layout stays intact.

Blocks are split by functional depth:

- compact ones for shared modules: banners, forms, dropdowns;
- larger ones that accept incoming data and render categories: labs, professors, degree programs, center news.

Mapping the relationship graph and making the admin panel understandable for that hierarchy was an engineering problem — not “another WordPress theme.”

## Color preset system

Every brand-book color is a variable. Variables form sets; sets become presets for the main site sections. One section picks a color set at random on each page load.

## Accessibility: four alternate themes

Beyond GOST for education sites, we shipped low-vision themes. Four color palettes with different contrast levels recolor every element and change how images render. The choice persists across navigation until the user resets it.

## Results

Yandex Metrika data for June–August 2026:

A flexible platform: admins manage blocks and pages without pulling designers or engineers into every edit. After launch, collaboration continues — feature work and technical support run continuously.

## Client testimonial

## Stack

Vue, Laravel, MySQL. The contour is a university public site and content admin — not live online lessons. Related EdTech cases with a different focus: [Glinka Digital](/en/project/glinka-digital) and [Future Volleyball School](/en/project/future-volleyball-school). Broader approach: [education solutions](/en/solutions/edtech).

---

## Portfolio: Разработка LIMS для МСИ: кейс СпектроХим — 250 лабораторий без Excel

- **Slug:** `spektrokhim`
- **Locale:** `ru`

Раз в несколько месяцев администратор «СпектроХим» открывала почту и начинала копировать цифры.

250 лабораторий. Каждая присылала результаты в своём формате. Одни писали 0,00412 — другие 0.00412. Одни слали один файл — другие три, и не всегда понятно, какой актуальный. Один неправильно перенесённый знак в сводной таблице — и результаты раунда теряют доверие аккредитационных органов. Исправить постфактум нельзя.

Немецкая платформа, на которой работал «СпектроХим», за это не отвечала. Она была построена для внутренней лаборатории — одна команда, один процесс, предсказуемый поток данных. Координировать внешнюю сеть из 250 независимых участников она не умела. Этот пробел закрывали Excel и почта — как всегда, когда корпоративная система не справляется.

К 2022 году обходные пути стали основным процессом. Платформа стоила дорого, поддерживалась сложно и была чужой — зарубежные лицензии, зарубежные обновления, зарубежная зависимость.

Задача была чёткая: не адаптировать старое. Заменить. Этот кейс — как мы делаем разработку LIMS, когда коробка не закрывает реальный процесс.

## Как «СпектроХим» работал раньше

«СпектроХим» проводит межлабораторные сличительные испытания — МСИ. Одну и ту же пробу нефти, битума или пищевого продукта анализируют десятки независимых лабораторий. Каждая измеряет, присылает результат, получает оценку относительно всей выборки. Так лаборатория подтверждает компетентность перед аккредитационным органом.

Это не внутренний процесс. Это координация внешней сети с разными людьми, разным оборудованием, разными привычками работы с данными.

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

Мы пришли с одной целью: убрать человека из критического пути там, где его присутствие создаёт риск, а не ценность.

## Что мы построили

### Кабинет организатора: раунд без таблицы

Кабинет организатора мы проектировали от одного вопроса: что администратор реально делает во время раунда испытаний?

Ответ: создаёт раунд, следит кто сдал и кто нет, закрывает сбор, формирует отчёт. Всё остальное — операционные накладные расходы.

Кабинет убирает накладные расходы.

Раунды создаются из структурированной базы — объекты (нефть, мазут, битум), показатели (зольность, массовая доля воды, содержание серы), тысячи ГОСТов. Администратор выбирает из библиотеки, а не вводит методику каждый цикл заново. Настройка раунда, которая раньше занимала часы, занимает минуты.

Участие лабораторий видно в реальном времени. Кто сдал, кто нет, у кого аномалия требует уточнения — без звонков, без писем, без ручной проверки по списку.

Когда раунд закрывается, отчёт выгружается в Excel со строгими типами данных: числа остаются числами, разделители остаются разделителями. Это не удобство — это требование аккредитационного аудита. Следовой журнал встроен в выгрузку, а не собирается отдельно потом.

### Кабинет лаборатории: точность на входе, не на выходе

Кабинет участника строился под одно ограничение: лаборант должен сдать результаты без инструкции.

После входа аналитик видит только своё: назначенные программы, открытые окна сдачи, нужные показатели. Ничего лишнего.

Ввод результатов работает с точностью до пятого знака после запятой. Отправить неполную форму нельзя — система не предупреждает, она блокирует. Каждое поле должно быть заполнено, каждый протокол — прикреплён в виде скана. В выборку попадают только подтверждённые данные.

Это звучит жёстко. Так и задумано.

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

### Почему кастом, а не коробка

Этот вопрос возникает на каждом проекте. Здесь ответ был очевидным.

Коробочные LIMS-решения строятся под внутреннюю лабораторию: один коллектив, один поток образцов, предсказуемый процесс. Они с этим справляются хорошо. Задача «СпектроХим» — координировать 250 независимых внешних участников против единой статистической методики. Это другая система: программное обеспечение для МСИ и оркестрация межлабораторных сравнений, а не классический внутрилабораторный поток проб.

В регулируемых отраслях у коробки ещё и структурные пределы. Аккредитация ждёт прослеживаемый путь от измерения до отчёта. Если процесс тянется через десятки внешних организаций со своими форматами и привычками, продукт должен кодировать ваши правила — точность знаков, обязательные сканы протоколов, заморозку данных после закрытия раунда — а не чужую generic-модель статусов образца. Кастомизация на чужой архитектуре часто означает ожидание чужого roadmap, пока Excel остаётся настоящей системой учёта.

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

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

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

## Стек и команда

Нам нужен был стек, который держит нагрузку при одновременной сдаче сотен участников и не тормозит при выгрузке отчётов с тысячами строк.

* Backend: Laravel — чисто обрабатывает сложный реляционный граф между объектами, показателями, методиками и ГОСТами
* Frontend: Vue.js — мгновенная реакция интерфейса при работе с большими таблицами, где администраторы проводят большую часть времени
* База данных: MySQL
* Команда: PM, фронтенд-разработчик, бэкенд-разработчик, тестировщик, дизайнер

Про внедрение стоит сказать отдельно: выкатить LIMS — это не только инженерная задача. Это работа с людьми. У лаборантов есть мышечная память на старые процессы — даже на плохие. Почему они саботируют новые системы и как этого не допустить — мы разобрали в статье [Почему лаборанты саботируют LIMS](/ru/blog/why-lab-staff-bypass-lims). Эта работа здесь тоже происходила.

## Результат

Сегодня через платформу работают более 250 лабораторий. Подготовка отчётов, которая раньше занимала недели ручного сведения, теперь заканчивается в момент, когда организатор закрывает раунд — примерно в три раза быстрее.

Число исправлений сократилось вдвое. Не потому что лаборанты стали аккуратнее — потому что кабинет не принимает данные, которые нужно исправлять.

«СпектроХим» получил независимую систему под собственную методику. Без зарубежного вендора. Без Excel в критическом пути. Без администратора, которая копирует цифры из 250 писем.

Кастомная LIMS в проде: 250+ лабораторий, отчёты в 3 раза быстрее и вдвое меньше исправлений — без Excel в критическом пути.

## Похожий лабораторный процесс?

Если ваша команда всё ещё ведёт МСИ, межлабораторные сравнения или другие регулируемые лабораторные процессы через таблицы и почту, потому что ничто «из коробки» не подходит достаточно точно — это именно тот пробел, в котором мы работаем.

Мы делаем разработку LIMS и смежных лабораторных платформ, когда реальный процесс не ложится в коробочный продукт. Сначала — как у вас реально идут раунды; потом — инженерия вокруг этого.

[Обсудить проект](#contact) — больше о лабораторных решениях WAPP: [химические лаборатории](/ru/solutions/chem-lab) и [LIMS](/ru/solutions/chem-lab/lims).

---

## Portfolio: Custom LIMS Development for SPEKTROKHIM: Automating Interlaboratory Proficiency Testing for 250+ Laboratories

- **Slug:** `spektrokhim`
- **Locale:** `en`

Every quarter, one administrator at SPEKTROKHIM opened her inbox and started copying numbers.

250 laboratories. Each one emailed results in its own format. Some used commas as decimal separators. Some used dots. Some sent three files where one was expected. The administrator opened each one, found the right column, and pasted the value into the master spreadsheet.

One typo in that spreadsheet — one transposed digit — and the proficiency testing round loses credibility. Accreditation bodies don't accept "we fixed it later."

SPEKTROKHIM had been running this process on a legacy German LIMS platform for years. The platform was expensive, hard to support, and hadn't solved the core problem: results still came in by email, collation was still manual, and report preparation still took weeks.

They came to us with a clear brief: remove the manual layer entirely. Build something that's theirs. This case is how we approach custom LIMS development when a boxed product cannot cover the real workflow.

## How SPEKTROKHIM worked before

SPEKTROKHIM runs interlaboratory comparisons across Russia — petroleum products, food, water, industrial chemicals. The same sample goes to dozens of independent labs. Each lab measures it, submits results, gets evaluated against the cohort. That's how a laboratory proves measurement competence to accreditation bodies.

The German platform handled some of this. But "handled" is generous — it handled the parts it was designed for: internal lab workflows. Coordinating an external network of 250 independent participants was never what it was built for. That gap got filled with Excel and email, the same way every gap in every enterprise system gets filled.

By 2022, the workarounds had become the process. The platform was a liability, not an asset. And it was a foreign liability — licence renewals, vendor dependency, no control over the roadmap.

The brief was to replace it. Not adapt it. Replace it.

## What we built

### Organizer portal: running a round without the spreadsheet

The organizer portal is where SPEKTROKHIM's administrators live. We built it around one question: what does an administrator actually do during a proficiency testing round?

The answer: they set up the round, track who's submitted and who hasn't, chase the stragglers, close the round, and generate the report. Everything in between is coordination overhead.

The portal eliminates the overhead.

Rounds are created from a structured library of objects — crude oil, fuel oil, bitumen — and analytes: ash content, water mass fraction, sulphur content. Administrators pick from the library rather than re-entering methodology data every cycle. What used to take hours of setup takes minutes.

Participant management is live. The administrator sees, in real time, which labs have submitted, which are pending, which have flagged anomalies. No more emailing labs to ask if they're done. No more manually checking against a list.

When the round closes, the report exports to Excel with strict data types enforced — numbers stay numbers, decimal separators stay consistent. The audit trail is built into the export, not assembled from notes afterwards. Accreditation auditors get what they need without anyone preparing a separate document.

### Lab portal: precision in, noise out

The participant-facing portal was designed around a single constraint: an analyst should be able to submit results without reading a manual.

Analysts log in and see exactly what they need to do — no more, no less. Their assigned programs, their open submission windows, their required analytes. Nothing else.

Result entry enforces precision at the field level. Values are accepted to five decimal places. An analyst cannot submit an incomplete form — every required field must be filled, every protocol scan must be attached. The system doesn't warn, it blocks. Only verified data enters the round.

This sounds strict. It is. That's the point.

Before this portal existed, the administrator's job included chasing labs for missing attachments, correcting format errors, and manually verifying completeness. The portal does that automatically. The administrator receives clean data or nothing at all.

### Why custom, not off-the-shelf

This question comes up on every project. Here it had a clear answer.

Off-the-shelf LIMS products are built for internal laboratory workflows: a single lab, a single team, samples moving through a known pipeline. They're good at that. SPEKTROKHIM's problem isn't that — it's coordinating 250 independent external participants against a unified statistical framework. That's a different system: proficiency testing software and interlaboratory comparison orchestration, not a classic in-lab sample pipeline.

In regulated industries, a boxed LIMS also carries structural limits. Accreditation expects an auditable path from measurement to report. If your process spans dozens of external organisations, each with their own formats and habits, the product has to encode *your* rules — decimal precision, mandatory protocol scans, frozen data after round close — not a vendor's generic sample status model. Paying for configuration on someone else's architecture often means waiting on their roadmap while you still keep Excel as the real system of record.

The closest packaged products would have covered perhaps a third of the actual requirement. The rest would have been customisation: paying a vendor to build what you need, on their timeline, on their architecture, with their constraints. And then paying again when requirements change.

Custom lab software development costs more upfront. It costs less every year after. SPEKTROKHIM owns the system. No licence renewals. No foreign vendor dependency. When they need a new measurement method added, they add it — without filing a feature request. That independence is why custom LIMS development was the right call here, not another year of workarounds on a legacy platform.

## Development process

Discovery. We mapped every step of a proficiency-testing round with SPEKTROKHIM: objects and analytes, participant onboarding, submission windows, corrections, export for audit. The output was a scope that reflected how rounds actually run — not a generic LIMS checklist.

Architecture. We designed the relational graph between objects, methods, national standards, and roles so organizers and labs could share one source of truth without leaking data across participants. Tables and exports had to stay correct under concurrent submissions.

Development. Backend, organizer UI, and lab portal moved in parallel with weekly demos. Edge cases from real rounds — incomplete files, mixed decimal formats, late submissions — were closed in the product, not left as "train the admin to fix it."

Rollout. Deploying a LIMS isn't just a code problem. It's a change management problem. Laboratory staff have muscle memory around their existing workflows — even bad ones. Training, phased go-live, and feedback from analysts on the bench mattered as much as the release build. We've written about why lab staff bypass new systems and how to prevent it in [Why lab staff bypass LIMS](/en/blog/why-lab-staff-bypass-lims). That work happened here too.

## Stack and team

We needed a stack that stays stable under concurrent round submissions and doesn't buckle when administrators open reports with thousands of rows.

* Backend: Laravel — handles the complex relational graph between objects, analytes, methods, and national standards cleanly
* Frontend: Vue.js — responsive under heavy table operations, where administrators spend most of their time
* Database: MySQL
* Team: PM, frontend engineer, backend engineer, QA, designer

## Result

More than 250 laboratories work through the platform today. Report preparation that used to take weeks of manual collation now finishes when the organizer closes the round — about three times faster.

The corrections rate dropped by half. Not because analysts got more careful — because the portal won't accept input that needs correcting.

SPEKTROKHIM owns an independent system built around their methodology. No legacy vendor. No Excel in the critical path. No administrator copying numbers from 250 email attachments.

Custom LIMS in production: 250+ labs, 3× faster reporting, and half as many corrections — without Excel in the critical path.

## Running a similar lab process?

If your team still moves proficiency testing, interlaboratory comparisons, or other regulated lab workflows through spreadsheets and email because nothing off the shelf quite fits — that's the gap we work in.

We develop custom LIMS and related lab platforms when the real process won't fit a boxed product. Start with how your rounds actually run; then engineer the system around that.

[Discuss your project](#contact) — more on WAPP lab solutions: [chemical labs](/en/solutions/chem-lab) and [LIMS](/en/solutions/chem-lab/lims).

---

## Portfolio: Как мы разработали систему управления флотом для SWAPPZ и обеспечили 100% контроль транспорта в Дубае

- **Slug:** `swappz`
- **Locale:** `ru`

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

Мы разработали единую цифровую экосистему SWAPPZ — кастомную систему управления флотом, которая связала владельцев, курьеров и сервисные команды в один прозрачный контур. Это кейс разработки ПО для логистики и автоматизации управления транспортом в условиях микромобильности ОАЭ.

## 01. Проблема

Владельцы флота видели картину кусками, курьеры искали свободные юниты вручную, техники узнавали о поломках слишком поздно.

SWAPPZ управляет флотом электробайков и самокатов по всему Дубаю. По мере роста флота операционные пробелы стали критическими.

У владельцев не было единого источника данных. Учёт транспорта велся в таблицах и через звонки — схема, которая ломается при масштабировании. Об угоне узнавали через несколько часов после того, как байк покидал зону. Когда самокат ломался, техник приезжал без истории неисправностей и терял время на диагностику того, что можно было определить удалённо заранее.

На уровне курьеров была своя проблема. В начале смены они тратили 15–20 минут на поиск свободных юнитов вручную — без приложения, без карты, без статусов.

Бизнес рос, но операционная модель не была рассчитана на рост. SWAPPZ нужна была кастомная система управления флотом, которая отражала реальную сложность процессов — не типовой SaaS, подогнанный под задачу.

Ключевые требования:

* Видимость каждого юнита флота в реальном времени
* Строгое разделение ролей — владельцы, администраторы, техники и курьеры с разными интерфейсами
* Мобильные инструменты для полевых сотрудников — фактически разработка мобильного приложения под логистику смены
* B2B-дашборд для инвесторов с чистой KPI-отчётностью
* Архитектура, которая масштабируется без полной переработки

## 02. Решение

### Ролевая модель и права доступа

Чтобы система работала эффективно, мы спроектировали многоролевую архитектуру с жёстким разделением прав. Каждый участник видит только данные, нужные для своей задачи.

Проектирование ролевой модели — первое и самое критичное архитектурное решение. Ошибка здесь ведёт либо к дыре в безопасности (курьер видит данные владельца), либо к провалу UX (техник тонет в лишних меню).

Перед первой строкой кода мы прошли каждый рабочий сценарий вместе с командой SWAPPZ. Пять ролей — у каждой своя задача и свой интерфейс:

* Суперадмин — полный доступ, управляет всеми операторами и локациями
* Администратор — флот одного оператора, пользователи и отчёты
* Владелец — read-only B2B-дашборд, KPI флота и финансовые метрики
* Техник — мобильное приложение с очередью задач, историей юнитов и навигацией
* Курьер — поиск юнитов, старт аренды и репортинг проблем

Права реализованы на уровне API — не только скрыты в интерфейсе. Токен курьера не может запросить данные уровня владельца, как бы ни был собран клиент.

### B2B-дашборд для владельца

Дашборд владельца создавался с одной целью: полная картина состояния флота за 30 секунд.

Интерфейс показывает три слоя данных одновременно:

* Статус флота — сколько юнитов активны, свободны, на обслуживании или под флагом. Карта с цветовой индикацией и провалом до конкретного юнита. Владелец видит, где каждый актив прямо сейчас.
* Сервисные KPI — среднее время реакции техника, открытые заявки, юниты, закрытые за последние 24 часа. Раньше у SWAPPZ не было способа измерить эффективность техников.
* Отслеживание угонов и инцидентов — юнит, покинувший геозону, сразу даёт алерт. В логе — метка времени и последнее местоположение. Вместе с GPS в реальном времени это меняет экономику угона.

Дашборд стал инструментом и для ежедневной работы, и для отчётности перед инвесторами. Чистые экспортируемые данные заменили ручные месячные сводки.

### Требования и сценарии

До разработки зафиксировали сценарии по ролям: маршруты, статусы юнитов, сервисные передачи, старт и завершение аренды. Эта карта стала ТЗ — и не «плыла» в середине спринта.

### Управление юнитами

Каждый актив флота получает цифровую карточку — она сопровождает юнит весь операционный цикл. По сути это система учёта транспорта на уровне единицы парка, а не только «точка на карте».

Карточка юнита содержит:

* Текущий статус (доступен, арендован, на обслуживании, под флагом)
* Полную историю аренд с метками времени и ID курьеров
* Лог сервисных событий с заметками техника
* Зафиксированные неисправности с фото
* Историю GPS-позиций

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

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

### Приложение техника

Полевые техники — операционный хребет флота. Инструмент должен быть быстрым, работать офлайн и быть сфокусированным — не урезанной админкой.

Приложение техника включает:

* Очередь задач — заявки от администратора, сортировка по приоритету и расстоянию. Без звонков диспетчеру: открыл приложение — видишь, что делать и в каком порядке.
* Навигация — один тап ведёт к последней GPS-позиции сломанного юнита. Без копирования координат в стороннюю карту.
* Логирование ремонта — тип неисправности, выполненный ремонт, детали и время. Данные сразу в карточке юнита и в KPI-дашборде.
* Офлайн-режим — очередь и данные юнитов кэшируются локально. Связь пропала — работа продолжается, синхронизация при восстановлении сети.

### Приложение курьера

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

Шесть экранов — у каждого одна функция:

* Поиск свободного флота — карта ближайших доступных юнитов, фильтр по типу
* Карточка юнита — состояние, дата последнего ТО, зафиксированные проблемы до принятия
* Начало аренды — QR или ручной ввод ID
* Маршрут и навигация — активная аренда с пунктом назначения
* Завершение смены — возврат с подтверждением состояния и актом передачи
* Репортинг проблемы в один тап — неисправность с опциональным фото сразу в очередь техника

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

### Технический стек

Backend:

* Node.js + NestJS — модульная архитектура под расширение
* PostgreSQL — транзакции: аренды, сервисные события, действия пользователей
* WebSocket — статусы юнитов в реальном времени для подключённых клиентов
* MQTT — IoT-телеметрия с GPS-трекеров

Мобильные приложения (курьер + техник):

* React Native — одна кодовая база для iOS и Android
* Офлайн-архитектура с локальным кэшем SQLite

Web (B2B-дашборд + админ-панель):

* React + TypeScript
* Mapbox GL — интерактивная карта флота с позициями в реальном времени

Инфраструктура:

* AWS (EC2, RDS, S3)
* CI/CD через GitHub Actions — автотесты и деплой

### Процесс разработки: 90 дней до MVP

Недели 1–2 — Discovery. Воркшопы с командой SWAPPZ: каждый операционный сценарий, роли, матрица прав, приоритеты. Результат — ТЗ, которое не менялось в процессе разработки.

Недели 3–4 — дизайн и архитектура. UX-прототипы для пяти ролевых интерфейсов, схема БД, инфраструктура и CI/CD.

Недели 5–10 — разработка. Параллельно backend, мобильные приложения и web-дашборд. Еженедельные демо с клиентом. Обратная связь в том же спринте — без накопления бэклога.

Недели 11–12 — QA и запуск. Полевые тесты с пилотной группой техников и курьеров в Дубае. Нагрузка на real-time компоненты. Поэтапный запуск на весь флот.

## 03. Результат

Проект показал: глубокое проектирование требований и сценариев на старте позволяет запустить сложный продукт в сжатые сроки. Мы обеспечили 100% контроль за юнитами и прозрачность процессов — от учёта транспорта до сервисного контура.

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

Что изменилось операционно:

* Владельцы перешли от звонков и таблиц к дашборду реального времени — полная картина за 30 секунд
* Время реакции техников сократилось — приезжают с историей юнита, а не вслепую
* Начало смены курьера сократилось с 15–20 минут ручного поиска до менее 2 минут
* Реакция на угоны стала возможной — алерты геозоны впервые дали быстрый ответ
* Отчётность для инвесторов — экспорт из дашборда вместо ручных месячных сводок

Что даёт архитектура дальше:

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

Запуск за 90 дней: прозрачный контроль транспорта, пять ролей и заметное снижение простоев и инцидентов с угонами.

## Нужна похожая система?

Управляете флотом или активами — и текущие инструменты не дают нужного контроля? Обсудим вашу задачу.

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

[Обсудить проект](#contact) — также [решения для логистики](/ru/solutions/logistics) и [управление автопарком](/ru/solutions/logistics/fleet).

---

## Portfolio: Fleet Management Software Development for SWAPPZ: From Zero to Full Fleet Control in 90 Days

- **Slug:** `swappz`
- **Locale:** `en`

When a rental fleet is scattered across Dubai and operations run on calls and guesswork, money leaks every minute. SWAPPZ rents electric bikes and scooters to delivery fleets in the UAE. As the fleet grew, the gaps became impossible to ignore.

WAPP built one operational layer for fleet owners, couriers, and service teams — a custom fleet management system matched to real Dubai field work, not a generic SaaS adapted to fit.

## 01. Problem

Fleet owners had limited visibility, couriers spent time searching for available units, and technicians were informed about failures too late.

SWAPPZ operates a rental fleet of electric bikes and scooters across Dubai. As the fleet grew, the operational gaps became impossible to ignore.

Fleet owners had no single source of truth. They relied on phone calls and manual spreadsheets to track unit availability — a system that broke down under scale. When a bike was reported stolen, they often found out hours after it left the designated zone. When a scooter broke down, the technician arrived without knowing the fault history, wasting time on-site diagnosing what could have been pre-diagnosed remotely.

The courier layer had its own problems. Riders spent the beginning of each shift physically searching for available units. No app, no map, no status feed — just walking and calling.

The business was growing, but the operations were not built for growth. SWAPPZ needed a custom fleet management system that matched the complexity of their real-world processes — not a generic SaaS tool adapted to fit.

The core requirements were clear:

* Real-time visibility of every unit in the fleet
* Strict role separation — owners, admins, technicians, and couriers each needed a different interface
* Mobile-first tools for field staff
* A B2B dashboard for investors and company owners with clean KPI reporting
* The ability to scale without rebuilding the architecture

## 02. Solution

### Role model and permissions

Designing the role model was the first and most critical architectural decision. Get it wrong, and you end up with either a security gap (couriers seeing owner data) or a usability failure (technicians buried in irrelevant menus).

We mapped every workflow before writing a single line of code. Five roles, each with a distinct job and a distinct interface:

* Super-admin — full system access, manages all operators and locations
* Admin — manages a single operator’s fleet, users, and reports
* Owner — read-only B2B dashboard, sees fleet KPIs and financial metrics
* Technician — mobile app with service queue, unit history, and navigation
* Courier — mobile app for finding units, starting rentals, and reporting issues

Permissions are enforced at the API level — not just hidden in the UI. A courier token cannot request owner-level data, regardless of how the client is built.

### B2B owner dashboard

The owner dashboard was designed for one purpose: give the business owner a complete picture of fleet health in under 30 seconds.

The interface surfaces three layers of data simultaneously:

* Fleet status — how many units are active, idle, in service, or flagged. Colour-coded map overlay with unit-level drill-down. Owners see where every asset is right now.
* Service KPIs — average response time per technician, open service tickets, units cleared in the last 24 hours. Before this system, SWAPPZ had no reliable way to measure technician efficiency.
* Theft and incident tracking — units that leave a defined geofence trigger an alert. The owner sees the event log, timestamp, and last known location. Combined with real-time GPS, rapid response became possible for the first time.

This dashboard became a tool not only for daily operations, but for investor reporting. Clean, exportable data replaced monthly manual summaries.

### Requirements and scenarios

Before development we locked workflows for every role: routes, unit statuses, service handoffs, and rental start/end. That map became the specification — and it did not thrash mid-build.

### Unit management

Every asset in the fleet gets its own digital record — an asset card that travels with the unit for its entire operational life.

The asset card contains:

* Current status (available, rented, in service, flagged)
* Full rental history with timestamps and courier IDs
* Maintenance event log with technician notes
* Reported issues with photo attachments
* GPS location history

When a technician is dispatched to repair a unit, they arrive already knowing what was reported, what was fixed last time, and what parts may be needed. That reduced average on-site repair time and removed the “I wasn’t told about this problem” loop between couriers and technicians.

Unit management also allows bulk operations — admins can update status for multiple units, flag a batch for scheduled maintenance, or temporarily remove units from the available pool without deleting them from the system.

### Technician app

Field technicians are the operational backbone of any fleet. Their tool needs to be fast, offline-capable, and focused — not a stripped-down admin panel.

The technician app delivers:

* Service queue — tasks assigned by the admin, sorted by priority and distance. No more dispatch calls. The technician opens the app and sees what needs doing and in what order.
* Navigation integration — one tap routes to the failed unit’s last GPS position. No copy-pasting coordinates into a maps app.
* Repair logging — fault type, repair performed, parts used, and time spent. Data feeds the unit’s asset card and the admin KPI dashboard in real time.
* Offline mode — the app caches the service queue and unit data locally. If connectivity drops in the field, tasks and repair logs still work. Data syncs when connection returns.

### Courier app

The courier app solves a deceptively simple problem: help riders find available units and start their shift in under two minutes.

Six screens, each with a single job:

* Available fleet search — map view of nearby available units, filterable by type
* Unit card — condition, last service date, and reported issues before accepting
* Rental start flow — QR scan or manual ID entry to claim a unit
* Route and navigation — active rental view with destination input
* End-of-shift flow — return with condition confirmation and handoff documentation
* One-tap issue reporting — flag a problem with an optional photo; the report lands in the technician queue

The last feature closed the most common operational breakdown: couriers knew about problems but had no easy way to report them. Issues went unreported, units stayed broken, customers complained. One-tap reporting closed that loop.

### Tech stack

Backend:

* Node.js + NestJS — modular architecture built for extension
* PostgreSQL — transactional data: rentals, service events, user actions
* WebSocket — real-time unit status updates across connected clients
* MQTT — IoT telemetry for GPS tracker data ingestion

Mobile (courier + technician apps):

* React Native — single codebase for iOS and Android
* Offline-first architecture with a local SQLite cache

Web (B2B dashboard + admin panel):

* React + TypeScript
* Mapbox GL — interactive fleet map with real-time unit positions

Infrastructure:

* AWS (EC2, RDS, S3)
* GitHub Actions CI/CD — automated testing and deployment

### Development process: 90 days to MVP

Week 1–2 — Discovery. Workshops with the SWAPPZ team to map every operational scenario. Role definitions, permission matrix, feature prioritisation. Output: a technical specification that stayed stable during development.

Week 3–4 — Design and architecture. UX prototypes for all five role interfaces. Database schema. Infrastructure setup and CI/CD pipeline.

Week 5–10 — Development. Parallel work on backend, mobile apps, and web dashboard. Weekly demos with the client. Feedback absorbed in the same sprint — no backlog pile-up.

Week 11–12 — QA and launch. Field testing with a pilot group of technicians and couriers in real Dubai conditions. Load testing on real-time components. Staged rollout to the full fleet.

## 03. Result

Released in 90 days with full fleet transparency and a measurable reduction in downtime and theft incidents.

The system launched on schedule, within scope, and without architectural rework. Three months from the first workshop to a live fleet management platform handling real operations across Dubai.

What changed operationally:

* Fleet owners moved from phone calls and spreadsheets to a real-time dashboard — complete visibility in under 30 seconds
* Technician response improved — dispatched with full unit history, not arriving blind
* Courier shift start dropped from 15–20 minutes of manual searching to under 2 minutes
* Theft response became possible — real-time geofencing alerts for the first time
* Investor reporting moved from monthly manual summaries to on-demand dashboard exports

What the architecture enables going forward:

The system was built to scale. Adding new cities, vehicle types, or operator accounts is a configuration change — not a rebuild. SWAPPZ can expand operations without growing the engineering team in lockstep.

From zero to full fleet control in 90 days: five roles, real-time GPS, and one source of truth for Dubai operations.

## Need a similar system?

If you manage a fleet of vehicles, equipment, or other physical assets — and current tools do not give the control you need — we are ready to discuss requirements.

WAPP builds custom fleet management software for logistics companies, mobility operators, and industrial businesses. Approach: deep process analysis first, then engineering.

Discuss your project — [logistics hub](/en/solutions/logistics), [fleet solutions](/en/solutions/logistics/fleet), or [submit a request](#contact).

---

## Portfolio: Вжух (VJUH / Tskapi)

- **Slug:** `tskapi`
- **Locale:** `ru`

[Вжух (VJUH)](https://vjuh.site/) — продукт WAPP для малого бизнеса, которому нужен рабочий сайт «вчера», а не смета студии на месяцы. Внутри проекта название **Tskapi** — «клик» по-грузински: короткий путь от пяти ответов в квизе до персонализированного лендинга с текстами, фото и заявками в WhatsApp.

Публичная витрина: [vjuh.site](https://vjuh.site/).

Собрали сервис, где сайт появляется за минуты: квиз → готовый лендинг под нишу → правки → один платёж 299 GEL → архив и выкладка. Без подписки и без обучения конструктору.

## Задача: сайт без студии, билдера и пропавших фрилансеров

Типичный клиент — небольшая компания без сайта или с устаревшей страницей 2010 года, которая не открывается на телефоне. В Google клиенты уже сравнивают конкурентов с нормальными сайтами. Студии называют от 5 000 GEL и сроки в месяцы. Конструкторы требуют времени на освоение. Фрилансеры исчезают после предоплаты.

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

**Что закрывали в продукте:**

- скорость: от квиза до рабочего сайта порядка 10 минут, а не недель разработки;
- цена входа: базовый план **299 GEL** разово вместо студийных бюджетов;
- нишевый смысл: копирайт и структура под тип бизнеса, а не пустой шаблон;
- лиды: заявки в WhatsApp, интеграция отзывов Google;
- спокойствие: без подписки, без платы за правки до оплаты, хостинг на старте бесплатный.

## Для кого сервис

Фокус — шесть типов малого бизнеса, где решение о визите или заказе часто принимается онлайн:

- стоматологические клиники;
- гостевые дома и мини-отели;
- химические лаборатории;
- логистические компании;
- частные детские сады;
- прочий малый бизнес, которому нужен ясный сайт «под ключ».

## Как это работает

Сценарий намеренно короткий — без обучения «как пользоваться билдером»:

1. Пройти квиз (~2 минуты, 5 вопросов).
2. Получить персонализированный сайт с текстами и медиа под нишу.
3. Внести правки до оплаты — без лимита на изменения на этом этапе.
4. Оплатить и скачать архив.
5. Выложить на хостинг (на старте — Netlify, бесплатный тариф).

## Что внутри готового сайта

В базовом пакете клиент получает не макет, а рабочий лендинг:

- адаптивная вёрстка (телефон, планшет, десктоп);
- конверсионный копирайт под нишу;
- блок отзывов Google;
- лиды в WhatsApp;
- мультиязычность для клиентов;
- выкладка на бесплатный хостинг Netlify;
- доступ к файлам и коду проекта;
- видеоинструкции по настройке;
- 7 дней технической поддержки.

## Модель денег: один платёж, без подписки

Базовый план — **299 GEL**. Один раз: архив, код, выкладка, без ежемесячной платы за сам сайт. Хостинг на Netlify в тарифе продукта — бесплатный; домен клиент оплачивает отдельно (~30–50 GEL/год). До оплаты правки безлимитные.

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

## Что делает WAPP

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

Честно фиксируем ограничения текущего этапа (как на самом [vjuh.site](https://vjuh.site/)): сейчас контент правится через файлы по видеоинструкциям, удобная CMS в планах. Задача кейса — показать живой сервис для малого бизнеса, а не идеальную админку будущего.

## Результат

- Публичный продукт: [vjuh.site](https://vjuh.site/).
- Понятный оффер для Грузии и малого бизнеса: сайт за минуты, 299 GEL, без подписки.
- Воронка «квиз → правки → оплата → deploy» без обучения конструктору.
- Шесть ниш с готовыми смыслами и визуалами на витрине.

Дальше — CMS, расширение ниш и сценарии «под ключ» для клиентов, которым нужна помощь на деплое.

## Для кого этот кейс в портфолио

Если нужен не дорогой кастом с нуля, а продуктовый сервис с квизом, генерацией лендингов и понятной ценой для SMB — разговор начинается с того же места, что и Вжух: сценарий клиента и скорость до первой заявки, а не толстый бриф на полгода.

---

## Portfolio: VJUH (Tskapi)

- **Slug:** `tskapi`
- **Locale:** `en`

[VJUH](https://vjuh.site/) is a WAPP product for small businesses that need a working website now — not a studio quote measured in months. Internally the project is **Tskapi** (“click” in Georgian): a short path from five quiz answers to a personalized landing page with copy, photos, and WhatsApp leads.

Public site: [vjuh.site](https://vjuh.site/).

We shipped a service where a site appears in minutes: quiz → niche landing → edits → one 299 GEL payment → archive and deploy. No subscription, no builder learning curve.

## Challenge: a site without agencies, builders, or vanished freelancers

The typical customer is a small company with no website — or a 2010-era page that fails on mobile. On Google, buyers already compare competitors with proper sites. Studios quote from 5,000 GEL and months of work. Builders take time to learn. Freelancers disappear after the prepayment.

The brief was not “another website builder”. It was a product for concrete niches: answer a few questions and get a site you can show customers and collect leads the same day.

**What the product had to cover:**

- speed: roughly 10 minutes from quiz to a usable site;
- entry price: **299 GEL** once, instead of studio budgets;
- niche meaning: copy and structure for the business type, not an empty shell;
- leads: WhatsApp messages and Google Reviews on the page;
- calm economics: no subscription, unlimited edits before payment, free hosting on day one.

## Who it is for

Focus is six SMB types where the visit or booking decision often happens online:

- dental clinics;
- guest houses and mini-hotels;
- chemical labs;
- logistics companies;
- private kindergartens;
- other small businesses that need a clear, ready website.

## How it works

The flow stays short — no “learn the builder” onboarding:

1. Take a ~2-minute quiz (5 questions).
2. Get a personalized website with niche copy and media.
3. Edit before payment — no change fees at this stage.
4. Pay and download the archive.
5. Deploy to hosting (Netlify free tier at launch).

## What is included

The base package is a working landing, not a mockup:

- responsive layout (phone, tablet, desktop);
- conversion copy for the niche;
- Google Reviews integration;
- WhatsApp leads;
- multilingual support;
- free Netlify hosting;
- full access to files and project code;
- step-by-step setup videos;
- 7-day technical support.

## Pricing: one payment, no subscription

Base plan — **299 GEL**. Once: archive, code, deploy, no monthly fee for the site itself. Netlify hosting in the product tier is free; the domain is paid separately (~30–50 GEL/year). Edits before payment are unlimited.

Paid add-ons cover people who want help: consultation, hands-on deploy help, extended support, domain purchase and setup, full hosting setup, and custom projects on request.

## What WAPP builds

VJUH is a studio product, not a one-off client landing. We built the public marketing site, quiz onboarding, niche landing generation, archive packaging, payment and deploy flow, reviews and messenger integrations, plus add-on services for customers who do not want to deploy alone.

We also state the current limits as on [vjuh.site](https://vjuh.site/): content is file-based with video guides for now; a proper CMS is on the roadmap. The case shows a live SMB service, not a future admin panel.

## Outcome

- Public product: [vjuh.site](https://vjuh.site/).
- Clear offer for Georgia SMBs: a site in minutes, 299 GEL, no subscription.
- Funnel “quiz → edits → pay → deploy” without builder training.
- Six niches with ready messaging and visuals on the homepage.

Next: CMS, more niches, and turnkey setup paths for customers who want full install help.

## Who this case is for

If you need a productized quiz-to-landing service with a clear SMB price — not a six-month custom build — the conversation starts where VJUH does: the customer journey and time to first lead.

---

## Portfolio: Xstreet: маркетплейс кроссовок по модели биржи

- **Slug:** `xstreet`
- **Locale:** `ru`

Xstreet — это площадка, где можно купить брендовые кроссовки, в том числе редкие модели. Она работает по принципу биржи. Селлеры регистрируются и выставляют обувь на продажу, а покупатели смотрят предложения и отслеживают динамику изменения цены.

  Исправили кодовую базу, подключили кассу и доставку, настроили удобную админку, сделали приложение быстрее.

## Цель

Доработать приложение по торговле кроссовками и вывести его на рынок.

## Как работает приложение

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

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

## Задача: разработать биржевой механизм

Перед нами стояла задача разработать большую систему с обработкой цен и построением графиков. С учётом ограничений React Native и Expo пришлось писать библиотеку построения графика почти с нуля.

График учитывает покупки внутри Xstreet и показывает изменения цены относительно мирового рынка — отдельно по рынку РФ и глобальным площадкам.

## Задача: подключить платёжную систему

Пока стандартно списываем деньги со счёта покупателя. В дальнейшем внедрим функционал, который сами предложили заказчику: возможность не списывать деньги сразу, а замораживать сумму на срок до 60 дней. Это поможет Xstreet экономить на комиссии в случае возврата.

## Задача: настроить онлайн-кассу и бух. отчётность

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

Теперь бухгалтерия может выгружать отчёты о финансовых операциях: Xstreet обязан отчитываться перед контролирующими органами как кассовый агент и формировать отчёты агента. Интеграция — через **Life Pay**.

## Задача: настроить систему логистики

Передача информации о заказе в службу доставки — последний шаг этапа покупки.

Интеграцию настроили со **СДЭК**; в следующем блоке работ запланирована **Яндекс.Доставка**. Покупатель выбирает способ доставки и видит итог с комиссией сервиса до оплаты.

## Задача: разработать механизм legit check

В компании работают специалисты по проверке товаров на оригинальность. Отдел, в котором они работают, — **legit check department**.

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

## Результаты работы на проекте

Приложение опубликовано в Google Play и App Store. Xstreet уже составили план работ на ближайший год — поддержку и развитие проекта мы тоже взяли на себя.

Нужен маркетплейс с нестандартной логикой сделки — оплата, касса, legit check, логистика? [Оставьте заявку](/ru#contact) — разберём процессы и предложим следующий шаг.

---

## Portfolio: Xstreet: a stock-exchange-style sneaker marketplace

- **Slug:** `xstreet`
- **Locale:** `en`

Xstreet is a platform where you can buy branded sneakers, including rare models. It works on exchange principles. Sellers register and list shoes for sale; buyers browse offers and track how prices move over time.

  We fixed the codebase, connected checkout and delivery, built a usable admin panel, and made the app faster.

## Goal

Refine the sneaker trading app and bring it to market.

## How the app works

All seller offers live on one platform. Buyers can purchase a model directly from a seller or propose their own price. Every pair goes through an authenticity check, so buyers know they are getting an original item.

The app makes trading easier for everyone — sellers and buyers alike. On a phone it is easy to watch how a price changes. When the moment is right, you place an order and the pair ships to you.

## Task: build the exchange mechanism

We needed a large system for price processing and chart rendering. Given React Native and Expo constraints, we wrote a charting library almost from scratch.

The chart reflects purchases inside Xstreet and shows price movement against the global market — separately for Russia and international platforms.

## Task: connect payments

For now we charge the buyer’s account in the standard way. Next we will add a feature we proposed ourselves: hold funds for up to 60 days instead of capturing immediately. That helps Xstreet save on fees when an order is returned.

## Task: online cash register and accounting

This had its own complexity: after payment we issue three receipts, not two. One goes to the agent — the reseller — and two to the buyer.

Accounting can now export financial operation reports: Xstreet must report to regulators as a cash agent and generate agent reports. Integration is via **Life Pay**.

## Task: logistics

Handing order data to a delivery service is the last step of the purchase flow.

We integrated **CDEK**; **Yandex Delivery** is planned next. The buyer picks a shipping method and sees the total with service fees before paying.

## Task: legit check mechanism

The company employs specialists who verify product authenticity. Their unit is the **legit check department**.

Following brand manufacturer protocols, specialists run checks and issue originality conclusions — required when a product is sold by a reseller. After verification the item receives a certificate of conformity.

## Project results

The app is live on Google Play and the App Store. Xstreet already has a roadmap for the coming year — we continue support and product development.

Need a marketplace with non-standard deal logic — payments, fiscal compliance, legit check, logistics? [Get in touch](/en#contact) and we will map your flows and suggest the next step.