Решения, которые стоит принять до первой строки коду

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

Разработчик закрывает пробелы, потому что пустое место всё равно станет экраном, полем или записью в базе. Кто владеет аккаунтами. Что берём готовым, а что пишем своим. Куда попадает заявка. Что считается принятым. Кто вправе сказать «нет». По умолчанию отвечает тот, кто пишет код, и потом вы платите за изменение его ответа. В предложении это меняется бесплатно, в записи в базе уже нет, и цена отличается на порядок.

1. Что берём готовым, а что своё

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

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

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

2. Аккаунты и домен должны принадлежать вам с первого дня

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

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

3. «Принято» это набор кликов, а не ощущение

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

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

4. Куда должна попасть заявка

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

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

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

5. Где можно проверять работу

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

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

6. Решает один человек, а «нет» записано

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

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

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

• Что берём готовым и что пишем своим, с критерием: отменённая подписка или переделка записей.
• Домен и все аккаунты на компанию, с доступом, который можно отозвать.
• Пять-десять проверок приёмки, написанные до начала сборки.
• Место, куда попадает заявка, описанное как путь и проверенное одним примером.
• Один человек, решающий за продукт, и датированное письменное «нет» для каждого отказа.

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