Насим из MobyTap: 5 лет с Фора Софт — оценка 10/10 без колебаний

Почему этот отзыв важен для заказчиков

Если вы выбираете партнёра по разработке ПО, то пятилетние отношения с клиентом, безупречная оценка 10/10 и подробное публичное интервью встречаются реже, чем значок G2. Насим Икбал пришёл в Фора Софт в 2016 году от другого подрядчика прямо посреди разработки, остался с нами до запуска и в течение многих лет доработок, а затем согласился записать разговор ниже на камеру.

Эта страница — не просто отзыв. Это разбор конкретных решений, которые превратили первую идею приложения предпринимателя из сферы переработки в MobyTap — платформу проверенных видеоотзывов, которая до сих пор работает на iOS, Android и Web. Каждый урок ниже повторяется в проектах, которые мы выпускаем в этом году.

Знакомьтесь, Насим — ветеран отрасли переработки, у которого появилась первая идея для приложения

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

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

Первый разговор — почему Насим сменил подрядчика посреди разработки

Словами Насима: «Удивительно, но именно Вадим меня нашёл. Я был на онлайн-платформе с тендерами, у меня было много предложений, и я уже выбрал компанию. Но когда Вадим написал, я подумал: окей, давай пообщаемся. Его характер и всё, что он делал, было профессионально. Я подумал: „Хоть мы и заключили договор с другими, почему бы и нет“. Он попросил дать „Фора Софт“ шанс — и я дал. Вот с этого всё и закрутилось».

Вадим показал Насиму подборку релевантных прошлых работ, а не стандартную презентацию. Именно так начинаются наши первые звонки и сегодня. Мы не таскаем с собой презентацию на 60 слайдов о своих возможностях — мы приносим три-пять проектов, которые больше всего похожи на ваш.

Урок 1 — можно менять подрядчика посреди разработки

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

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

Урок 2 — начинающим основателям нужен партнёр, а не исполнитель

Насим: «Я впервые разрабатывал приложение. Последние 15 лет работал в сфере переработки. Так что, когда у меня появилась эта идея, я думал, что переработка и видеоприложения — это совершенно разные миры. … Звучит просто, но, как только погружаешься, понимаешь, что всё не так просто».

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

Самая сложная техническая задача — доменные имена всего мира

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

Насим: «Мы застряли на том, чтобы упростить пользователям ввод доменного имени любой компании в мире. Когда вы оставляете отзыв, приложение определяет, где вы находитесь, и находит местный бизнес, о котором вы пишете. Никто в мире такого ещё не делал. … Мы застряли на 4–5 месяцев».

Наши инженеры заметили, что Google только что выпустил Places SDK для Android. Одно предложение — и: «Мы сможем это сделать».

Урок 3 — инженерия по первым принципам экономит месяцы и бюджет

Насим: «Вы, ребята, буквально сэкономили мне целое состояние, придумав, как добавить в приложение доменные имена со всего мира».

Эта закономерность работает в целом. Большинство задач в разработке приложений решаются быстрее, если сделать шаг назад, а не давить сильнее. Новый SDK, другой протокол, возможность платформы, появившаяся в прошлом квартале — обычно именно это и есть разница между «невозможно» и «выпустим в следующем спринте». Наших инженеров поощряют следить за примечаниями к релизам платформ и задавать вопрос: «Меняет ли это саму задачу?» — прежде чем писать хоть строчку кода.

«Всё дело было в общении» — почему процесс важнее часов

И снова Насим: «Сбоев было немного. Это было просто непрерывное улучшение. Всё, что мы делали, — улучшали приложение, делали его лучше. А ваша команда — потрясающая. Всё дело было в общении и в том, чтобы донести до вас мою мысль. Вы, ребята, сильно упростили мне жизнь, а ведь в этом и весь бизнес».

Наша работа основана на нескольких простых принципах общения: у каждого проекта — выделенный менеджер, который переводит задачи с языка бизнеса на язык разработки, двухнедельные спринты с живыми демонстрациями, общее рабочее пространство в Jira/Notion, где каждое решение фиксируется, и прямой доступ к инженерам, писавшим код. Ничего экстраординарного — просто дисциплина, нехватку которой большинство клиентов замечают только после ухода от предыдущего подрядчика.

Сопровождение после запуска — то, что, по словам Насима, подняло планку для всех последующих подрядчиков

Насим: «Лучшее в Фора Софт — это поддержка после запуска. Вы так высоко подняли планку, что теперь я жду такого от каждой компании. Поддержка была на высшем уровне, а общение — просто потрясающее, это действительно впечатлило. Даже здесь, в Великобритании, в Англии, мы такого не получаем».

Теперь это полноценная услуга — поддержка и сопровождение программных продуктов. Ежемесячная абонентская плата включает мониторинг сбоев, помощь с публикацией в App Store и Google Play, обновление зависимостей, патчи безопасности и доработки, сравнимые по объёму с отдельной функцией. Большинство клиентов, остающихся после первого года, переходят на такую модель.

10/10 за профессионализм, общение и вовлечённость

На просьбу оценить нас по трём стандартным для агентства критериям Насим ответил: «Даже не думаю над оценкой. Это 10 из 10 без раздумий».

Эта оценка дословно приведена на странице проекта MobyTap и опубликована в структурированных данных на нашем сайте, чтобы её могли показывать поисковые системы и AI-системы ответов. Это часть более широкого массива подтверждений: компания Фора Софт была названа одной из ведущих компаний по разработке iOS-приложений на 2026 год по версии Techreviewer, и за 21 год мы выпустили более 625 продуктов.

Что взять на заметку, если вы выбираете партнёра

1. Звонок с отделом продаж — это превью будущего проекта. Если он шаблонный, проект тоже будет шаблонным. Насим перешёл в Фора Софт после единственного разговора, в котором Вадим привёл релевантные примеры, а не зачитывал презентацию.

2. Начинающие основатели заслуживают партнёра со своим мнением. Готовность оспаривать объём задач, честные компромиссы и прозрачные цифры важнее, чем «да» на всё подряд.

3. С небольшим бюджетом тоже можно выпускать отличные продукты. «Был у вас маленький бюджет или большой — вы всё равно управляли им идеально». Разница в расстановке приоритетов, а не в количестве часов.

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

5. Рекомендации — честный маркетинговый канал. Заключительная фраза Насима — «если кому-то нужно видеоприложение, я сразу думаю о вас и передаю ваш номер и контакты» — это именно тот рост, ради которого работает сервисный бизнес.

Кто такая Фора Софт сегодня — более 625 продуктов и 21 год работы в сфере видео

С 2005 года мы выпустили более 625 программных продуктов, специализируясь на видео в реальном времени, искусственном интеллекте, WebRTC и мобильной разработке. Мы создавали платформы такого масштаба, как BrainCert (более 500 млн минут занятий, доступность 99,995%), TransLinguist (контракт с NHS в Великобритании, более 30 000 переводчиков, поддержка более чем 75 языков), TradeCaster (более 22 тыс. пользователей трейдингового сообщества) и десятки других значимых проектов.

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

Что мы предлагаем сегодня и чего не было у MobyTap в 2016 году

Десять лет улучшений накопились. Базовое предложение, которое сработало для MobyTap, осталось прежним — разработка ПО на заказ с выделенной командой. Что изменилось с 2016 года:

Agent-Engineering. Наша практика Agent-Engineering ускоряет разработку на 30–40% по сравнению с бенчмарками 2024 года, особенно в проектах с большим объёмом видео и использованием ИИ.

Интеграция AI. Услуги по интеграции ИИ внедряют OpenAI, Anthropic, Deepgram, ElevenLabs, а также кастомные модели Core ML — возможностей, которых не было при запуске MobyTap.

Видео в реальном времени при любом масштабе. Специализируемся на WebRTC, LiveKit, MediaSoup, Twilio и Agora — с отдельной страницей услуг по каждому направлению.

Модель выделенной команды. Формат выделенной команды — когда у клиента уже есть продуктовый специалист, а нужны только инженерные ресурсы.

Как начать тот же разговор, что Насим начал в 2016 году

Разговор в 2016 году проходил по электронной почте и по холодному звонку. Версия 2026 года проще. Договоритесь о 30 минутах с Вадимом напрямую — он по-прежнему первый, с кем вы поговорите. Возьмите с собой один-два вопроса, примерное представление о бюджете и важный для вас срок. После звонка у вас будет конкретный следующий шаг.

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

Система принятия решения — выберите следующего подрядчика за пять вопросов

Вопрос 1. На первом звонке показали релевантные работы или рассказали о возможностях? Если рассказали — продолжайте поиск.

Вопрос 2. Будете ли вы общаться с инженерами, которые напишут код? Если нет — коммуникация уже нарушена.

Вопрос 3. Может ли подрядчик описать, как будет выглядеть сопровождение на втором году? Если ответ «там видно будет» — они исчезнут после запуска.

Вопрос 4. Публикует ли он отзывы клиентов с именами, которые готовы ответить на звонок? Анонимные цитаты не в счёт.

Вопрос 5. Готовы ли они сказать «нет» при оценке объёма работ? Подрядчики, которые соглашаются со всем подряд, выпускают перегруженные продукты, которые не удерживают пользователей.

Ошибки, которых стоит избегать при выборе партнёра по разработке

1. Оптимизация по почасовой ставке. Самая дешевая команда на старте часто оказывается самой дорогой в итоге. Насим заплатил дважды, потому что выбрал самого дешёвого подрядчика.

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

3. Игнорировать пересечение часовых поясов. Вам нужно минимум четыре часа пересечения рабочего времени в день. При нулевом пересечении двухдневные задачи растягиваются на две недели.

4. Пропустить SLA на период после запуска. Поддержку по сбоям, безопасности зависимостей и соответствию требованиям сторов нужно прописать в договоре до запуска, а не обсуждать уже после, когда всё горит.

5. Не спросить, кто будет вашим менеджером проекта. Менеджер проекта — это 80% всего опыта работы. Назовите имена, а не должности.

KPI, которые стоит отслеживать при работе с любым партнёром по разработке

KPI качества. Доля сессий без сбоев — не менее 99,9% (iOS) / 99,5% (Android); задержка P95 на критическом пути; динамика рейтинга в App Store; скорость устранения проблем по данным MetricKit / Firebase Crashlytics.

KPI поставки. Процент завершённых спринтов — не менее 85%; отклонение по стори-поинтам — менее 15% за спринт; количество релизных циклов в квартал.

KPI отношений. NPS основателя — раз в квартал; доля идей по функциям, предложенных инженерной командой; скорость поступления рекомендаций после запуска продукта.

Когда мы — не тот партнёр

Если вам нужна чистая аутстаффинговая компания, которая выдаст пять разработчиков к понедельнику без участия в продукте, мы вам не подходим. Если ваш продукт — типовой бэк-офис на CRUD-операциях без компонентов реального времени, видео, аудио или AI, наша специализация себя не окупит. А если основатель ждёт еженедельного «да», то честные возражения на наших звонках по оценке объёма работ будут восприниматься как помеха, а не как помощь.

Любой из этих трёх случаев? Мы скажем об этом на первом звонке и порекомендуем кого-то другого. Пять лет MobyTap начались с того, что мы сказали «да»; многие отношения в нашей воронке начинаются с того, что мы говорим «нет» неподходящему объёму работ.

Частые вопросы

Что почитать дальше

Готовы пережить свой момент «эти ребята знают своё дело»?

Пятилетняя история Насима с Фора Софт — одна из более чем 600, которые мы могли бы рассказать. В большинстве таких историй закономерность одна и та же: внимательный первый разговор, команда, построенная вокруг продукта, сложная техническая задача, решённая благодаря изучению заметок к релизам платформы, и поддержка, которая годами помогает приложению оставаться «живым». Именно поэтому рекомендации до сих пор приносят большую часть нашего нового бизнеса.

Когда вы будете готовы начать свою версию этой истории, мы всего в одном звонке от вас.