Инженер Sherif Amer после сокращения в Infineon потратил два с половиной года на путешествия, самостоятельное изучение разработки и собственный проект, а затем стал первым разработчиком стартапа Indemni. Его история хорошо описывает реальность ранней команды: здесь один человек может за день спроектировать распределённую систему, вечером выпустить функцию для клиента, а наутро разбираться с инцидентом в продакшене.
Amer пришёл в Indemni — стартап из батча Y Combinator W24, работающий с проверкой водителей, данными перевозчиков и мониторингом грузов в реальном времени. Компания помогает грузовым брокерам снижать риск мошенничества и увереннее принимать грузы к перевозке, сообщает Y Combinator Blog. Для русскоязычных разработчиков и фаундеров здесь нет экзотического «секрета успеха»: ценность раннего инженера определяется не стеком в резюме, а способностью брать на себя неопределённые задачи и доводить их до работающего результата.
До смены карьеры Amer разрабатывал встраиваемые системы и проверял смешанные аналого-цифровые микросхемы в Infineon. После увольнения он не стал сразу искать похожую позицию в полупроводниковой отрасли. Вместо этого инженер путешествовал, осваивал software engineering и строил Roamies — собственный продукт. Подробностей о проекте и его коммерческих результатах в источнике нет, но сам опыт оказался практической подготовкой к стартапу: пришлось самостоятельно выбирать, что именно строить, как проверять решения и где не тратить время на лишнюю сложность.
В Indemni его формальная должность — Founding Engineer, то есть инженер из самой первой команды. Сам Amer описывает себя проще: как инженера с продуктовым мышлением, который много пишет код. При выборе компании он смотрел не на громкость титула, а на состав команды, круг проблем и степень ответственности. Ему было важно, чтобы основатели допускали технические споры и не сводили роль разработчика к исполнению тикетов. Для найма первых инженеров это важный сигнал: обещания «влияния на продукт» ничего не стоят, если архитектурные и продуктовые решения уже принимаются в закрытом режиме.
Первый разработчик стартапа Indemni строил значительную часть асинхронной инфраструктуры и системы уведомлений. В его зоне ответственности оказались потребители Redis Streams, восстановление сообщений, контроль конкурентного доступа, ограничение частоты запросов и доставка уведомлений. Отдельно он развивал инфраструктуру верификации: интегрировал внешних поставщиков идентификационных данных, выстраивал многошаговые сценарии и определял, как сервис обрабатывает и анализирует результаты проверки.
Такой набор задач звучит знакомо любому инженеру, работавшему в маленькой B2B-команде. На ранней стадии нет отдельного подразделения, которому можно передать проблемы с очередями, наблюдаемостью или ограничениями внешнего API. Amer прямо говорит, что сбои инфраструктуры обычно становятся и его проблемой. Взамен он получил право не тащить каждый компонент в управляемый облачный сервис по умолчанию: можно сравнить стоимость, сложность и требования к масштабу, а затем собрать решение под текущую потребность бизнеса. Это не аргумент против managed-сервисов, а напоминание, что «по умолчанию» — плохое архитектурное обоснование.
Одним из заметных проектов стал планировщик задач, который Amer построил поверх уже используемой в компании инфраструктуры Redis Streams. В реализации он привлекал ИИ-агента для программирования: передавал ему архитектурный контекст и ограничения, а затем делегировал часть написания кода. По его оценке, интерес представлял не сам факт генерации кода, а возможность сместить фокус на архитектуру — выбор технологий, фиксацию компромиссов и проверку результата. Для команд, которые внедряют кодовых агентов, это вполне приземлённый сценарий: инструмент ускоряет работу, но не отменяет необходимость понимать устройство системы и цену ошибок.
По мере роста Indemni и появления новых инженеров роль Amer изменилась. Теперь он чаще занимается архитектурой, инженерными правилами, стандартами качества кода и наставничеством. Самым полезным результатом он называет рост самостоятельности коллег: новые разработчики принимают технические решения и выпускают качественные изменения без постоянной проверки со стороны первого инженера. Для фаундера это, пожалуй, один из немногих масштабируемых результатов раннего технического найма — не героически закрывать всё самому, а постепенно делать команду независимой.
Переход из крупной полупроводниковой компании оказался для Amer переходом не только между технологиями, но и между способами принимать решения. В большой организации есть уровни согласования и чётко очерченные зоны ответственности; в стартапе приходится действовать при неполных данных, быстро корректируя курс. Тем, кто хочет стать первым разработчиком стартапа, стоит заранее проверить не только знания распределённых систем или frontend-фреймворков. Критичнее готовность спорить с основателями по существу, работать без идеального ТЗ и отвечать за последствия собственного решения — именно эта комбинация всё чаще отделяет раннего инженера от просто сильного исполнителя.
