Стоимость, сроки, права на код, NDA и безопасность данных, команда и технологический стек — прямые ответы без воды. Если вопроса нет в списке, просто напишите нам.
Стоимость формируется от объёма и сложности задачи, а не от количества строк кода:
Работаем по модели T&M — оплата по фактически затраченному времени, а не фиксированная смета «на глазок». Ставка начинается от 1 800 ₽/час.
Зависит от масштаба и определённости задачи:
Fixed Price даёт предсказуемость бюджета там, где задача понятна заранее; T&M — гибкость там, где по ходу проекта неизбежны уточнения и изменения.
Сроки сильно зависят от типа системы и её сложности. Ориентиры по проектам средней сложности:
Это сроки для типового проекта без нестандартных интеграций и специфичных требований — точная оценка формируется после уточнения объёма задач на старте.
Путь от заявки до старта разработки состоит из четырёх шагов:
На этом же этапе, до раскрытия деталей проекта, подписывается NDA — если задача требует обсуждения конфиденциальной информации.
Нет: обычно ТЗ формируется совместно на первой стадии — заказчик описывает бизнес-задачу, команда разработки задаёт уточняющие вопросы и фиксирует требования в рабочем формате.
Если у заказчика уже есть готовое ТЗ — это ускоряет старт, но не обязательное условие.
Изменение требований оформляется как change request — отдельный этап с чёткой процедурой:
Мы не закладываем «буфер на всё» в изначальную цену — это заставило бы клиента платить за гибкость, даже если она не понадобится. Вместо этого каждое изменение оценивается и согласовывается отдельно.
Да, тестирование — отдельный этап, а не «и так сойдёт»:
Для проектов с ограниченным бюджетом объём тестирования можно осознанно сократить — но только по явному согласованию с заказчиком, а не тихим решением команды. Это фиксируется на старте проекта, чтобы клиент понимал, на чём именно экономит.
Зависит от масштаба отклонения — и мы говорим об этом прямо, а не замалчиваем:
Такой подход держится на доверии, а не на попытке спрятать проблему до последнего момента: конечная цель — работающий продукт и партнёрство, которое продолжится и на следующих проектах.
Да, по желанию заказчика — процесс не закрыт «чёрным ящиком» до сдачи:
Отдельная опция для проектов, которым это важно, — вести трекинг задач прямо в «Портал», нашей собственной системе управления проектами. Это даёт заказчику не просто доступ к абстрактному стороннему таск-трекеру, а среду, которую мы полностью контролируем и можем гибко настроить под конкретный проект.
Передача — формализованный этап, а не разовая выгрузка архива:
Права на код передаются заказчику — это фиксируется в договоре, а не остаётся на словах:
Это не отдельная платная опция и не предмет отдельного торга после сдачи проекта — вопрос прав закрывается ещё на этапе подписания договора.
Нет, если лицензии контролируются осознанно:
Проверка не декларативная: весь стек нашего проекта «Портал», 300+ библиотек, прошёл такой аудит, и ни одной заражающей лицензии в нём нет.
Да, NDA — стандартный первый шаг перед обсуждением деталей проекта:
Конфиденциальность обеспечивается на нескольких уровнях, а не одним пунктом в договоре:
Такой подход снимает основной страх заказчика — что тестовые данные, бизнес-логика или доступы «утекут» за пределы команды, которая реально работает над проектом.
Напрямую. Клиент общается с разработчиками и дизайнерами, которые пишут код и рисуют интерфейсы — без посредника, пересказывающего задачу своими словами.
Это ускоряет решение вопросов: уточнить нюанс можно сразу с тем, кто его реализует, не дожидаясь возврата от менеджера. Тот же принцип действует и в нашем ПО «Портал», и в заказной разработке — сознательно не добавляем менеджерский слой между клиентом и командой.
Да, поддержка работает по SLA с чёткой матрицей критичности:
Аутсорс закрывает пиковую нагрузку и разовые продукты без содержания штата (аренда, ФОТ, соцпакет, простой между проектами, увольнения и их компенсации). Своя команда выгоднее для непрерывного долгосрочного развития одного или нескольких продуктов — с постоянной загрузкой штата и обязательным управлением.
Мы позиционируемся как «гибридный» партнёр: можем поднажать «в пике» и остаёмся командой, которая на связи после релиза.
Приоритет — штатная команда:
Всегда в проекте есть наш основной состав команды.
Да, если это не противоречит действующему законодательству РФ:
Проверка законности — не формальность для галочки: если по конкретной юрисдикции или отрасли есть действующие регуляторные препятствия, об этом сообщаем прямо на этапе брифа, а не после начала работ.
Готовое SaaS быстрее и дешевле на старте, но не подстраивается под нестандартные процессы; кастомная разработка — дороже и дольше, зато решение точно повторяет бизнес-логику заказчика, а права принадлежат ему, а не вендору.
Основной язык — Go: быстрый, простой в поддержке и хорошо ложится на сервисы, которые должны стабильно работать под нагрузкой.
Для ускорения прототипирования используем AI, финальная реализация — вручную: иначе это неконтролируемое ПО, на котором можно забыть о масштабировании и оперативной доработке.
Go компилируется в один бинарник без рантайм-зависимостей, даёт предсказуемую производительность под нагрузкой и низкое потребление памяти — в отличие от Node.js, где однопоточная модель упирается в CPU-bound задачи, и Java, где выше порог входа и тяжелее операционная модель (JVM, менее предсказуемая сборка мусора).
Для backend-сервисов, которые должны стабильно держать нагрузку годами без сюрпризов, это разумный компромисс между скоростью разработки и производительностью.
PostgreSQL — отличная база для транзакционной нагрузки (OLTP): создать заказ, обновить статус, проверить остаток. Но когда нужно агрегировать миллионы строк для аналитики или дашбордов, колоночная архитектура ClickHouse на порядки быстрее строковой PostgreSQL — она не читает лишние колонки и эффективнее сжимает данные.
Поэтому PostgreSQL у нас остаётся источником правды для операционных данных, а ClickHouse — отдельный слой для аналитики поверх них.
Не каждому интерфейсу нужен полноценный SPA-фреймворк с виртуальным DOM и клиентским роутингом — это лишний вес и сложность там, где страница по сути показывает данные с сервера с точечной интерактивностью.
HTMX позволяет обновлять части страницы без перезагрузки, оставляя логику на сервере, а Templ даёт типобезопасные шаблоны прямо на Go — меньше движущихся частей, меньше JS в браузере, проще поддерживать.
Там, где производительность критична (обработка больших потоков данных, задачи с жёсткими ограничениями по ресурсам), Rust даёт контроль на уровне C/C++ без ручного управления памятью и без гонок данных — компилятор ловит целый класс багов ещё до рантайма.
Это не замена Go на каждый день, а инструмент для конкретных узких мест, где нужна максимальная предсказуемость и скорость.
Для скриптов, интеграций, задач вокруг данных и всего, что не требует высокой производительности рантайма, Python быстрее написать и проще поддерживать — экосистема библиотек огромная, а Go в таких задачах был бы избыточной строгостью ради самой строгости.
Остались вопросы — обсудим ваш проект напрямую.