Как построить IT-продукт без технического образования — опыт основателя

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

Этот миф остановил сотни основателей, которые так и не решились реализовать свои идеи. В 2025 году российский IT-рынок вырос на 27%, до 4,8 трлн рублей, при этом 62% новых SaaS-продуктов запускают предприниматели без технического бэкграунда. Этот тренд подтверждает: технические навыки больше не барьер для создания успешного продукта. Наоборот, не-IT основатели часто выигрывают за счет глубокого понимания пользовательских болей и рыночных реалий.

И моя история это подтверждает. Я не программист и никогда им не был. Более того, на момент запуска первого продукта у меня не было команды разработчиков. Была только идея, понимание потребностей пользователей. Тем не менее, сегодня AWX — это международный финтех-сервис с пользователями по всему миру, официально зарегистрированная структура и полноценная команда профессионалов.

— Почему отсутствие кода — это преимущество?

Если бы я был техническим основателем, то фокусировался бы на архитектуре, а не на продукте. По данным CB Insights, 42% провалов стартапов связаны с «не тем продуктом», а не с багами. Предприниматель без технического образования интуитивно понимает клиента лучше, чем разработчик.

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

— Если бы вас попросили разработать пошаговый подход к созданию работающего сервиса для не-технарей, то каким бы он был?

Я работаю не для того, чтобы кого-то учить, но готов поделиться мнением, как основателю пройти путь от идеи до финального продукта. Буду приводить примеры, опираясь на собственный опыт и ошибки.

— Итак, с чего начнем?

С поиска технического исполнителя. 2017 год. Я еду в машине на свою текущую работу. В голове уже оформилась идея создать технологический сервис. Останавливаюсь на перекрестке и вижу простой баннер: «Делаем сайты». Звонок по номеру на том баннере стал поворотным моментом в моей жизни. Человек, ответивший на звонок, сегодня — наш технический директор.

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

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

— Для основателя технический партнер — это не переводчик с языка бизнеса на язык программирования. Где найти кандидата?

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

— Но и с техническим партнером надо уметь договориться. Как говорить с разработчиками на одном языке?

Главный страх основателя: «Я не смогу объяснить разработчикам, что мне нужно, и они сделают не то». Этот страх обоснован. Но у задачи, которую он передо мной поставил, было простое решение.

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

Вот что мне помогает донести видение до команды разработки:

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

Разработчики сами переведут этот сценарий в технические требования.

Второе. Прототипы без программирования. Первую версию мы делали не в коде, а в виде прототипов. Сегодня для этого существуют десятки инструментов: от Figma для дизайна до Tilda и Glide для создания работающих прототипов без единой строки кода. 

— Это сейчас стало популярно, но действительно ли нужно такое упрощение?

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

— Еще одна особенность, которая характерна для рынка. Ваш MVP был готов в 2017 году, а компания начала работу в 2020. Почему MVP сразу не вышел в релиз?

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

Это важнейший урок для всех, кто строит IT-продукт: MVP (minimum viable product) — это не минимально работающий код. Это минимально работающий бизнес.

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

Первая версия продукта должна ответить не на вопрос «работает ли код?», а на вопрос «готовы ли мы обслуживать спрос?».

— Какие выводы вы сделали из этого опыта?

Да, они могут пригодится многим коллегам-предпринимателям. Главное, что мы сделали правильно в тот период, так это:

• Не стали нанимать большой штат до проверки гипотез
• Сохранили отношения с техническим партнером, даже когда проект «заморозили»
• Использовали паузу для сбора обратной связи и доработки концепции

— Как нанимать команду, когда ты не эксперт в технологиях?

Когда пришло время масштабироваться, перед нами встал классический вопрос: как отбирать технических специалистов, если не разбираешься в коде?

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

Принцип 1. Профессионализм важнее личной симпатии. Hard skills — это база. Но как их оценить нетехническому основателю? Мы используем несколько методов:

• Практические задания, которые готовят и проверяют технические лиды, когда они уже появились в команде
• Интервью с несколькими членами команды (коллективная оценка)
• Проверка предыдущего опыта и реальных проектов кандидата

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

Принцип 3. Культура открытости. Мы с самого начала строили компанию как прозрачную структуру. Это касается и отношений внутри команды. Разработчики должны понимать бизнес-задачи, а основатель — технические ограничения. У нас нет разделения на «этих» и «этих». Есть общая цель.

— И, руководствуясь этими принципами, вам удалось перерасти стартап?

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

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

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

— И каковы ключевые уроки этого этапа?

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

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

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

— Подведем итоги. Технологии — это инструмент или цель?

Оглядываясь назад, я понимаю: отсутствие технического образования было не недостатком, а преимуществом. Потому что я всегда смотрел на продукт глазами пользователя, а не разработчика. Я задавал «глупые» вопросы, которые помогали упростить интерфейс. Я требовал объяснений, которые делали продукт понятнее для миллионов.

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

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

Как я говорю своей команде: «Самая сложная технология — не код, а люди и их доверие. Все остальное — это уже вопрос времени и правильного подхода».

— Что ждет рынок в 2026–2027 годах?

Госрегулирование IT (особенно финтех) ужесточается, но это открывает окно возможностей. Компании без технических основателей, которые понимают комплаенс и UX, захватят 35% рынка SaaS. Главное преимущество таких предпринимателей — умение говорить языком клиента и регулятора одновременно.

Создать IT-продукт без технического образования сегодня проще, чем когда-либо. Главное — четкое понимание проблемы пользователя и воля найти правильных партнеров. Рынок ценит результат, а не дипломы.