Давайте будем честными. На самом деле это не 15 лет. Мне всего 34. Я не был архитектором решений всю свою жизнь.
Но последнее десятилетие я глубоко погрузился в корпоративную архитектуру. Я прошёл путь от младшего разработчика до технического лидера. Я создавал высоконагруженные микросервисы. Я помогал внедрять Scrum.
И не поймите меня неправильно — мне действительно нравились некоторые вещи. Динамичная среда была интересной. Мне нравилось формировать гибкие команды, даже внутри огромных, медленно движущихся корпораций.
Но где-то на этом пути я перестал создавать ради удовольствия.
Последние несколько лет я в основном занимался консалтингом. Фрилансил на Toptal. Рисовал архитектурные диаграммы. Три облака. Кластеры Kubernetes. Очереди сообщений. 3 разные команды только для поддержания этой штуки.
«Корпоративные технологии имеют очень мало общего с созданием великих вещей. Они о минимизации рисков.»
Корпоративные технологии имеют очень мало общего с созданием великих вещей. Они о минимизации рисков. Это защита своих решений. Бесконечные Jira-задачи и совещания по согласованию, где 10 человек обсуждают цвет кнопки.
Мне нравится технологии: Hono или ElysiaJS, bee-queue или BullMQ. Стоит ли продолжать с .NET или использовать TypeScript. Мне нравится создавать что-то с нуля. И, честно говоря, я ненавижу корпоративный балласт.
Кроме того, я хочу зарабатывать. Не просто стабильный консалтинговый чек — я хочу непропорционально высокую прибыль от того, чем я владею.
💡 Инсайт: Парадокс архитектора
Как архитекторов нас учат создавать системы, которые выживут при смене команды, но тот же опыт делает нас ужасными независимыми основателями. Мы переусердствуем в решении проблем, которых ещё не существует, тратя месяцы на инфраструктуру, которая никогда не будет использована.
Мышление архитектора против мышления независимого основателя
Как архитектор, вся твоя работа — создавать системы, которые не развалятся, если завтра уволят половину инженеров (коэффициент автобуса). Вы создаёте слои абстракции. Вы спорите неделями о том, использовать RabbitMQ или Kafka для функции, которую буквально ещё никто из пользователей не просил.
«Когда у вас команда из 50 человек, принятие решения занимает неделю. Когда вы работаете один, вы принимаете его за пять минут.»
Когда у вас команда из 50 человек, принятие решения занимает неделю. Когда вы работаете один, вы принимаете его за пять минут.
А если посмотреть на найм сейчас? ИИ проверяет резюме. Соискатели используют ИИ-помощников, чтобы подсказывать ответы во время собеседования. Компания использует ИИ-агентов, чтобы задавать вопросы и оценивать код.
Это буквально роботы, разговаривающие с роботами. Так зачем вообще беспокоиться?
Когда вы работаете как независимый основатель, вы просто пропускаете всю эту фальшивую «театральность». Вы не проводите собеседования. Вы просто садитесь и создаёте.
💡 Инсайт: ИИ меняет всё для соло-предпринимателей
Один разработчик, правильно использующий ИИ-инструменты, может легко обогнать корпоративную команду среднего размера. Конкурентное преимущество сегодня — не в количестве людей, а в устранении всех препятствий, мешающих людям создавать.
Создание QuotyAI: Продукт, который действительно выполняет работу
Я был техническим сооснователем в Superbench. Мы создавали ИИ для продаж и планирования для компаний, предоставляющих услуги на дому.
Это отличный продукт, но я хотел глубже погрузиться в ИИ — я искал больше этого «вау»-эффекта.
Поэтому я создаю QuotyAI, продукт, который мне нравится и который соответствует моим интересам: детерминированная продающая ИИ-платформа со встроенным агентом для написания кода. Вместо того чтобы просить LLM угадывать ответы, он генерирует реальную исполняемую бизнес-логику на TypeScript — формулы ценообразования, правила составления коммерческих предложений, валидацию заказов — так что ответы всегда на 100% точны. Он объединяет настоящую базу знаний, омниканальный почтовый ящик и полную аудируемость в одном инструменте, чего не делают конкуренты.
Это тот «вау»-фактор, который я искал: ИИ, который не просто звучит умно, но действительно надёжно выполняет работу.
💡 Инсайт: Детерминированность — следующий рубеж ИИ
Большинство ИИ-продуктов сегодня оптимизируются под убедительность. Реальная возможность — в ИИ, который генерирует верифицируемый, исполняемый результат. Это разница между ИИ, который даёт советы, и ИИ, который реально выполняет вашу работу.
Взять работающее, оставить балласт
Вы не поднимаете Kubernetes кластер в первый день. Вы не переусердствуете в архитектуре. Вы просто создаёте именно тот кусок кода, который решает проблему перед вами.
Мы живём в эпоху, когда ИИ-агенты могут написать за вас скучную стандартную часть. Один разработчик, правильно использующий ИИ-инструменты, может легко обогнать корпоративную команду среднего размера.
Не усложняем ли мы программное обеспечение просто ради оправдания наших высоких зарплат? Я думаю, что да. И я сыграл в эту игру достаточно.
Корпоративный опыт — не мусор
Каждая из этих корпоративных практик была изобретена потому, что кто-то обжёгся. Я ничего из этого не выбрасываю.
Я по-прежнему пишу поддерживаемый, идиоматический код на TypeScript. У меня по-прежнему есть правильные CI/CD-конвейеры с запуском тестов перед каждым деплоем. У меня по-прежнему точные контракты между бэкендом и фронтендом. У меня по-прежнему всё мониторится через OpenTelemetry. Я по-прежнему использую проверенные паттерны, такие как внедрение зависимостей.
Разница очевидна. Я не создаю семь слоев абстракции для функции, которую будут использовать десять человек. Я не поднимаю Kubernetes-кластер для чего-то, что отлично работает на VPS за $15. У меня нет двухнедельного процесса архитектурного обзора.
«Сломайте что-то не то один раз в корпоративном масштабе, и вы быстро поймёте, какие правила действительно важны.»
Сломайте что-то не то один раз в корпоративном масштабе, и вы быстро поймёте. Вы узнаете, какие правила действительно важны. Вы берёте хорошие части, которые предотвращают боль. Вы оставляете балласт позади.
Вы просто создаёте именно тот кусок кода, который решает проблему перед вами. Один разработчик, правильно использующий ИИ-инструменты, может легко обогнать корпоративную команду среднего размера.
Обменять «театральность» на исполнение
Вот что независимый технический основатель значит для меня сегодня.
Венчурное финансирование не требуется. Фальшивая «театральность» найма отсутствует. Бесконечные совещания по согласованию не нужны. Просто создаёшь именно то, что людям действительно нужно.
Я обменял десяти_person архитектурные обзоры на решения за пять минут. Обменял Kubernetes-кластеры на простые, надёжные деплои. Обменял Jira-задачи на реально работающее программное обеспечение.
Кроме того, я хочу генерировать реальный доход. Не просто получать стабильный консалтинговый чек. Я хочу непропорционально высокую прибыль от того, чем я владею.
Я создаю QuotyAI публично. Я буду деться каждой ошибкой, каждой победой и каждым деплоем. Я создаю его для владельцев хостелов, операторов кафе и представителей малого бизнеса. Им не нужен корпоративный балласт. Им просто нужно что-то, что работает надёжно.
И впервые за годы я снова создаю ради удовольствия.
Поймёт ли остальная индустрия, что она тонет в собственной сложности, пока не стало слишком поздно?
Часто задаваемые вопросы
Почему вы ушли из корпоративной архитектуры, чтобы стать независимым основателем?
После десятилетия создания корпоративных систем я понял, что большая часть моей работы была о минимизации рисков, а не о создании отличных продуктов. Я хотел владеть тем, что создаю, пропускать корпоративную «театральность» и вернуться к созданию ради удовольствия, одновременно создавая реальную ценность для малого бизнеса.
Как корпоративный опыт помогает независимому основателю?
Корпоративный опыт учит тому, какие инженерные практики действительно предотвращают проблемы при масштабировании. Я по-прежнему использую CI/CD, OpenTelemetry и внедрение зависимостей — но пропускаю семь слоев абстракции и двухнедельные архитектурные обзоры, которые не нужны небольшим командам.
Чем QuotyAI отличается от других ИИ-инструментов для продаж?
QuotyAI использует детерминированный ИИ, который генерирует исполняемую бизнес-логику на TypeScript, а не просто звучит убедительно. Это означает, что формулы ценообразования, правила составления коммерческих предложений и валидация заказов всегда на 100% точны, с полной аудируемостью, которой не могут похвастаться конкуренты.
Может ли один разработчик действительно обогнать корпоративную команду?
Да, когда устранены все препятствия. Одному разработчику, эффективно использующему ИИ-инструменты, не нужно посещать совещания по согласованию, ждать архитектурных обзоров или лавировать в корпоративной политике. Он может полностью сосредоточиться на создании того, что важно.