Термины для старта цифрового проекта

Стратегическая сессия это короткая платная рабочая встреча, на которой бизнес вместе с внешними экспертами разбирает цели, клиентов, процессы и цифровые системы и уходит с планом по приоритетам: что делать первым, что подождёт, а от чего отказаться. Она полезна до того, как тратить бюджет на редизайн, новую систему или рекламу. Наша сессия длится два часа по видеосвязи, письменные рекомендации приходят в течение 48 часов. Она стоит $500, и эта сумма засчитывается в проект, начатый в течение 30 дней.

Подробнее: Стратегическая сессия

CTO по подписке это опытный технический директор (CTO, chief technology officer), который работает на компанию неполное время: принимает решения о стеке, архитектуре, подрядчиках и найме и проверяет работу разработчиков, без затрат на штатного топ-менеджера. Формат подходит компаниям, которые зависят от технологий, но ещё не готовы к CTO на полный день. Наша базовая цена от $3 500 в месяц, это примерно один день в неделю, с оплатой помесячно.

Подробнее: CTO по подписке

Расширенная стратегическая сессия это углублённый формат стратегической сессии для крупных или запутанных вопросов: сначала команда несколько дней работает с данными, системами и рынком компании, затем проводит полный рабочий день с клиентом. Она подходит для решений с высокой ценой ошибки, например при выборе новой платформы, выходе на новый рынок или перестройке цифровых каналов. Наша расширенная сессия стоит от $5 000.

Подробнее: Как работает Peretz Agency: услуги, процесс и цены

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

Подробнее: Метод Коломбо: как найти настоящую проблему бизнеса

Формулировка проблемы (problem statement) это короткое описание проблемы, которую должен решить продукт или проект, словами самих клиентов и с подтверждением, что за её решение готовы платить. Проекты часто приходят с готовым решением, например «нам нужна CRM», хотя никто ещё не определил, что должно измениться в бизнесе. Без такой формулировки команда может сделать более быстрый и современный сайт, который ничего не изменит, потому что владельцу на самом деле нужно было больше записей на приём, а не красивая главная страница.

Подробнее: Архитектура MVP: что маркетинг должен продукту до запуска

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

Подробнее: Диджитализация бизнеса в Киркленде: что это значит на самом деле (и когда она нужна)

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

Подробнее: Софт должен подходить бизнесу

Анализ конкурентов это изучение других компаний в категории, чтобы понять, как она устроена: что предлагают клиентам, как построены сайты и магазины, где остаются пробелы. Он нужен для понимания, а не для копирования, и у него есть пределы: видно только то, что конкуренты сами решили показать, а картина может описывать компанию, которая уже изменилась. В одном из наших исследований мы разобрали 30 брендов и для 18 из них определили архитектуру платформы по техническим признакам: структуре URL, метаданным, путям CDN и способам оплаты.

Подробнее: Мы проектируем не для идеальных сценариев, а для реальности

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

Подробнее: Неправильный ход. Правильный ход. Слишком поздно.

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

Подробнее: Product Design против UX/UI: где реально начинается цифровой продукт?

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

Подробнее: Стратегическая сессия

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

Подробнее: Неправильный ход. Правильный ход. Слишком поздно.

Discovery-фаза это платный этап перед разработкой, на котором идея превращается в документы, на которые можно опереть цену и сроки: требования, пользовательские сценарии, кликабельный прототип, архитектура, интеграции, риски и бэклог с оценкой. Она нужна, когда оценки одной и той же идеи у разных подрядчиков сильно расходятся. Наша discovery-фаза занимает от двух до четырёх недель и стоит от $4 000, а её документы написаны так, чтобы по ним могла работать любая команда.

Подробнее: Discovery-фаза проекта

Product discovery это часть продуктового менеджмента, которая снимает самую опасную неопределённость о продукте, пока её ещё дёшево исправить: от вопроса к фактам, их интерпретации и решению. Это способ работы, а не воркшоп. Исследования достаточно, когда команда может сказать, какую проблему решает продукт, для кого, как её решают сегодня, какие есть ограничения и рискованные допущения и чего не будет в первой версии. Не путайте с product discovery в e-commerce, где так называют то, как покупатели находят товары через поиск и фильтры.

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

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

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

Техническое исследование (technical discovery) это часть discovery, в которой изучают существующий технический ландшафт: какие системы уже работают в компании, где лежат данные, какая система служит источником истины, какие API и ограничения действуют и что выгоднее: разработать, купить или интегрировать. Оно должно влиять на продуктовый дизайн с самого начала, а не добавляться после того, как нарисованы экраны. Наше архитектурное исследование проходит семь этапов, прежде чем рекомендовать технологию: бизнес-проблема, допущения, клиенты, существующая система, стоимость изменений, более точные вопросы к ИИ и только затем технология.

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

Карта допущений (assumption mapping) это техника discovery, при которой команда записывает свои убеждения о пользователях, рынке и решении и ранжирует каждое по важности, неопределённости и цене ошибки. Сначала исследуют фундаментальные и наименее подтверждённые допущения. Метод отделяет факты (наблюдаемое поведение или данные) от допущений (в них верят, но их не показали) и гипотез (их ещё нужно проверить), а простой вопрос «откуда мы это знаем?» не даёт мимолётной реплике стать требованием.

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

Интервью с клиентами (customer discovery) это разговоры с потенциальными пользователями о том, как они справляются с проблемой сегодня, которые проводят до проектирования продукта. Вопросы касаются последнего случая, когда проблема возникла, а не того, стали бы люди пользоваться продуктом или платить за него: прошлое поведение это факт, будущее намерение лишь гипотеза. Такие интервью часто показывают, что таблица, цепочка писем или чат в WhatsApp уже решают часть проблемы так, как предлагаемый продукт ещё не понял.

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

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

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

Проверка гипотез это проверка бизнес-допущения минимально возможным экспериментом до вложений в полноценный продукт. Перед разработкой команда решает, какую гипотезу проверять первой, какой минимальный продукт для этого нужен и какая метрика покажет, что она работает. Часто гипотезу можно проверить за $500 вместо $50 000: лендинг, небольшой рекламный бюджет и аналитика показывают, кто приходит и какие предложения приводят к заявкам, ещё до того, как система создана.

Подробнее: MVP, это не минимальный продукт. Это цена входа.

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

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

Тест спроса (предзаказ) это лендинг, который предлагает продукт до его появления и просит посетителя о действии, которое ему чего-то стоит: внести депозит, оформить предзаказ или указать данные карты. Порог успеха фиксируют до запуска, а проблему описывают словами самих клиентов. Так проверяют самую частую причину провала: по данным CB Insights, отсутствие рыночной потребности названо в 42% разборов закрывшихся стартапов.

Подробнее: Разработка Landing page под ключ

Тест «фальшивой двери» (fake door test) это эксперимент, в котором предлагают функцию или продукт, которых ещё нет, через кнопку, страницу или рекламу, чтобы измерить, сколько людей попробуют ими воспользоваться. Тем, кто нажал, сообщают, что это скоро появится, а доля кликов показывает реальный, а не заявленный интерес. Это один из самых дешёвых способов проверить допущение без прототипа, наряду с интервью, таблицами и разговорами о цене.

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

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

Подробнее: Product Discovery: что стоит знать, прежде чем начинать проектировать?

Соответствие продукта рынку (product-market fit) это момент, когда продукт встречает реальный повторяющийся спрос на рынке, достаточно большом, чтобы его поддерживать. Без него маркетинг не исправляет слабый продукт, а лишь усиливает его слабость. Анализ CB Insights по 385 закрывшимся стартапам назвал несоответствие продукта рынку главной причиной в 43% случаев, а нехватка денег обычно была уже следствием.

Подробнее: MVP, это не минимальный продукт. Это цена входа.

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

Подробнее: Почему большинство ИИ-пилотов не доходит до продакшена и как довести свой до живой работы

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

Подробнее: Как выбрать веб-студию

Объём работ (scope of work) это письменное описание работ проекта с этапами, результатами, сроками и ценой, согласованное до начала работы. Изменения в нём согласуют до того, как их делают, а не после. Объём работ должен следовать за бизнес-целью: проект можно выполнить точно по договору и всё равно не создать ценности, если в объёме был описан не тот результат.

Подробнее: Как работает Peretz Agency: услуги, процесс и цены

Расползание объёма работ (scope creep) это неконтролируемый рост объёма проекта после начала работы, обычно за счёт мелких добавлений, каждое из которых кажется разумным. Одна функция открывает интеграцию, интеграция проблему с данными, а та структурную проблему, и при почасовой оплате эти расходы несёт клиент. Расползание из-за нерешительности отличается от разумной адаптации к новой информации. В перерасходе часто винят именно его, хотя обычная причина скрытый технический долг.

Подробнее: Сколько стоит кастомный сайт в 2026 году?

Запрос на изменение (change request) это формальный запрос на изменение согласованного объёма проекта, который оценивают и утверждают до выполнения работы. Он отделяет новые решения от дефектов: «кнопка оформления заказа не работает» это ошибка, которую исправляют, а «переделать оформление заказа до запуска» это новое решение со своей стоимостью и сроками. Такой порядок сохраняет предсказуемость бюджета и даты запуска.

Подробнее: Сколько на самом деле занимает разработка e-commerce и что должен делать клиент

Оценка проекта это прогноз стоимости и сроков проекта на основе того, что известно о его объёме на данный момент. Два агентства могут назвать $40 000 и $100 000 за один и тот же бриф, потому что оценивают разные проекты; цифра, названная без вопросов о процессах клиента, отражает допущения, а не требования. Сложный проект невозможно честно оценить после часового звонка или по PDF. Этап веб-приложения готов к оценке, когда описаны его пользователи, роли и связанные системы.

Подробнее: Сколько стоит кастомный сайт в 2026 году?

Сравнение коммерческих предложений это приведение предложений разных агентств к одному объёму работ перед сравнением цен. Предложения на $18 000, $65 000 и $190 000 по одному проекту обычно описывают три разных проекта. Проверяют, что входит в каждое: discovery, UX/UI, информационная архитектура, миграция, интеграции, платежи, налоги, доставка, SEO-миграция, аналитика, тестирование, документация, обучение и поддержка после запуска; если команда большая, стоит спросить, чем займётся каждый.

Подробнее: Почему сметы на e-commerce разработку в Сиэтле варьируются от $25 до $300 в час

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

Подробнее: Разработка веб-приложений и SaaS

Сроки проекта это график его этапов от старта до запуска, включая работы и решения на стороне клиента. Для ориентира: магазин на готовой теме у облачной платформы делается за недели, собственная витрина с интеграциями и миграцией за несколько месяцев, профессиональный сайт на заказ обычно за 6-10 недель. Задержки копятся до разработки (объём, контент) и прямо перед запуском (тестирование, согласования), поэтому реалистичный график показывает и дорожку клиента: решения, данные о товарах, доступы, обратную связь и приёмку.

Подробнее: Сколько на самом деле занимает разработка e-commerce и что должен делать клиент

MVP, или минимально жизнеспособный продукт (minimum viable product), это первая версия продукта с набором функций, достаточным, чтобы реальные пользователи могли его попробовать и заплатить за него. Так спрос проверяет рынок, а не чьи-то мнения. Хороший MVP урезан по объёму, но не по качеству: его модель данных и код должны выдержать рост. Наши проекты MVP стоят от $20 000, разработка обычно занимает от двух до четырёх месяцев.

Подробнее: Разработка MVP

Оценка MVP (MVP review) это независимая проверка первой версии продукта, которой уже пользуются люди, часто собранной быстро или с помощью ИИ: её кода, безопасности, продуктовой логики и рынка. Итог это письменный вердикт: оставить, доработать или переписать. Узкий внутренний инструмент без платежей и чувствительных данных обычно можно оставить, работающий продукт с растущей аудиторией и понятной структурой доработать, а платежи или персональные данные на основе без контроля доступа требуют переписывания. Наша оценка стоит от $3 000, чаще всего $3 000-5 000, и цена фиксируется до начала работы.

Подробнее: Оценка MVP

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

Подробнее: Разработка веб-приложений и SaaS

Go-to-market стратегия (стратегия выхода на рынок) это план того, как продукт дойдёт до клиентов: через какие каналы, с каким сообщением, с каким бюджетом и в каком порядке. Её проверяют параллельно с разработкой: где целевой клиент тратит внимание и можно ли достучаться до него через этот канал по разумной цене. Отличный продукт без жизнеспособного пути к клиенту это не MVP, а дорогой проект с немногими пользователями, а новый сайт без маркетингового бюджета и плана трафика дорогой объект, который никто не видит.

Подробнее: Архитектура MVP: что маркетинг должен продукту до запуска

Build vs buy это решение, разрабатывать собственное программное обеспечение или пользоваться готовым продуктом, чаще всего SaaS (software as a service, программа как услуга). Изменились обе стороны: платформы умеют гораздо больше, чем раньше, а заказная разработка ускорилась благодаря современным фреймворкам и ИИ. Решение часто не окончательное: компания может сначала купить и настроить готовое, понять, как на самом деле работает её процесс, а потом расширить его или написать своё.

Подробнее: Уравнение Build vs. Buy изменилось. Большинство компаний его ещё не пересчитали

Разрастание подписок (SaaS sprawl) это неконтролируемый рост числа подписок компании на программные сервисы: инструменты добавляют разные отделы, функции пересекаются, а часть лицензий никто не использует. Подписка за $500 редко остаётся системой за $500: вокруг неё накапливаются коннекторы, дополнительные модули и более дорогие тарифы. По индексу Zylo за 2026 год расходы на SaaS выросли на 8% за год, а 36% лицензий не использовались.

Подробнее: Уравнение Build vs. Buy изменилось. Большинство компаний его ещё не пересчитали

Совокупная стоимость владения, или TCO (total cost of ownership), это полная стоимость системы за весь срок её работы, а не только цена разработки или покупки: подписки, приложения и комиссии, хостинг, поддержка, обновления, тестирование, доработки и цена обходных решений. Частая ошибка: сравнивать разовую смету на разработку с ежемесячной подпиской без учёта TCO. В наших сравнениях платформ мы смотрим на пять лет вперёд.

Подробнее: Уходить ли с Magento в 2026 году: обновление, Shopify Plus или Laravel?

Расходы после запуска это то, во что обходится работа сайта или приложения после релиза: хостинг, безопасность, обновления, мониторинг и исправления. Распространённый ориентир для планирования составляет 10-20% от первоначальной стоимости разработки в год. Для профессионально поддерживаемого сайта небольшого бизнеса хостинг, поддержка и обновления обходятся примерно в $1 200-3 600 в год, из них на домен и хостинг приходится $200-500.

Подробнее: Что на самом деле делает разработку e-commerce дорогой

Лицензирование за пользователя (per seat) это модель цены, при которой за программу платят за каждого пользователя в месяц; она распространена в CRM, ERP и инструментах для совместной работы. На старте это выглядит дёшево, но расходы растут вместе с командой: по прейскурантам 2026 года 20 пользователей за пять лет обойдутся в $120 000-234 000 в Salesforce Sales Cloud и $109 500 в HubSpot Professional, тогда как собственная CRM стоит от $90 000. При 10 пользователях дешевле выходит HubSpot ($55 500), а CRM за $30 на пользователя становится дорогой, если её внедрение стоит $50 000.

Подробнее: Разработка CRM

Ценовые уровни сайтов это типичные диапазоны цен на сайт в зависимости от того, кто и как его делает. На рынке США в 2026 году конструкторы стоят $20-80 в месяц, фрилансеры $1 500-6 000, небольшие агентства $5 000-15 000, сайты на заказ от $15 000 до $50 000 и выше, корпоративные проекты от $50 000 до $150 000 и выше. За $5 000 клиент платит за исполнение, а за $20 000 за стратегию, собственный дизайн, работу над конверсией, SEO-архитектуру и опытную команду.

Подробнее: Сколько стоит сайт в Сиэтле в 2026 году?

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

Подробнее: Почему растущий бизнес в Беллевью рано или поздно вырастает из своего сайта

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

Подробнее: Софт должен подходить бизнесу

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

Подробнее: Чем ты реально владеешь, а что арендуешь: Digital Ownership Audit

Цифровые активы это домены и DNS, хостинг, исходный код, лицензии CMS, аналитика, рекламные кабинеты, CRM и почта, API и учётные записи, на которых работает бизнес, вместе с его контентом. Каждый из них должен быть оформлен на аккаунт компании, а не на личный. Активы, которые поддерживают, например статьи, описанные процессы и кейсы, со временем дорожают, а не обесцениваются, и это становится заметно при продаже компании.

Подробнее: Что происходит с сайтом после покупки компании?

Цифровое владение это реальный контроль компании над своим доменом, DNS, хостингом, репозиторием кода, аналитикой, Search Console, платёжными и почтовыми сервисами через аккаунты, которые принадлежат ей самой. Логин администратора или выгрузка данных это доступ, а не владение: договор может передать сайт, а пароли и ключи останутся у людей, которые уже ушли. Каждый компонент можно отнести к одной из групп: владеем, арендуем (понятная зависимость) или зависим от человека или подрядчика, до которого больше никто не может дотянуться. Кто будет владеть сайтом после запуска, лучше решить до того, как решать, как его строить.

Подробнее: Большинство компаний не владеют своим сайтом. Они владеют экосистемой зависимостей.

Привязка к поставщику (vendor lock-in) это зависимость от подрядчика или платформы, из-за которой уйти от них дорого или невозможно в разумный срок. Простой тест: может ли компания заменить своего разработчика, агентство, хостинг, CRM или платформу, не потеряв критичных функций. Выгрузка данных может оказаться бесполезной без закрытой логики, которая их окружает. Риск вполне практический: Bitrix24 объявил, что с 1 июня 2023 года его облако перестанет работать в Украине, и пользователи могли потерять порталы и данные.

Подробнее: Чем ты реально владеешь, а что арендуешь: Digital Ownership Audit

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

Подробнее: Скрытый технический долг, из-за которого редизайн сайта стоит дороже плана

Технический дью-дилидженс это независимая проверка кода, инфраструктуры, безопасности, лицензий и контроля над доменами и аккаунтами компании, которую проводят для покупателя или инвестора до сделки. Она показывает, что на самом деле покупается, что держится на конкретных людях и сколько будут стоить исправления. Наша сессия стоит $1 500, полная проверка от $7 500; чаще всего работа занимает от пяти до десяти рабочих дней.

Подробнее: Сессия технического дью-дилидженс

Аудит цифрового владения это проверка того, чем бизнес действительно владеет, а что арендует или от чего зависит: сайт, код, данные, сервисы, договоры с подрядчиками и ключевые люди. Он отвечает на один вопрос: что сломается, если завтра исчезнет разработчик, агентство или платформа. В итоге вы получаете карту владения и зависимостей и список приоритетов; наш аудит стоит от $1 000 и занимает от пяти до десяти рабочих дней.

Подробнее: Аудит цифрового владения и долга

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

Подробнее: Аудит цифрового владения и долга