Бизнес-модель продажи и использования ПО
Многие бизнес-процессы принято стандартизировать и автоматизировать. Благодаря повторяемости и воспроизводимости проще выстраивать и контролировать рабочие процессы, оперативно выявлять отклонения и проблемы.
При работе с сайтами аналогичная ситуация. Тут тоже есть свои процессы. Типовой цикл работы с клиентами у бизнеса выглядит так:
Кратко
SEO для SaaS — это не одна механика, а три разные: контентный подход (растём на статьях и длинном хвосте), продуктовый (выводим в топ и докручиваем сами страницы сервиса) и массовый (программно генерируем тысячи похожих страниц под низкочастотку). Они дают разный результат, разную скорость и разные риски. Большинство сервисов сжигают бюджет не потому, что делают SEO плохо, а потому что взяли подход не под свою структуру спроса. Ниже — как они устроены под капотом, на реальных дашбордах Метрики и Топвизора, и как выбрать свой.
Привет, на связи Дмитрий, основатель агенства Сайткрафт. За последние годы мы вели поиск для десятков SaaS и онлайн-сервисов, и почти на каждом старте слышим один и тот же запрос: «сделайте нам SEO, нужен трафик и заявки». Проблема в том, что под этой фразой прячутся три совершенно разных проекта. Их легко перепутать на старте, и тогда полгода уходит впустую: трафик вроде растёт, а заявок нет, или позиции есть, а индекс выкашивает фильтр. В этой статье разберу три подхода к SEO для онлайн-сервиса инженерно — что внутри каждого, на каких данных видно, что он работает, и как не выбрать чужой.
Содержание
1. Почему один и тот же SEO у двух SaaS даёт разный результат
2. Подход 1 — контентный: рост на статьях и длинном хвосте
3. Подход 2 — продуктовый: заявки дают сами страницы сервиса
4. Подход 3 — массовый: тысячи похожих страниц под низкочастотку
5. Три подхода в одной таблице
6. Как понять, какой подход ваш
5 клиентов по 10 000 рублей в месяц - 50 000 рублей MRR. Но при корректном подсчете на выходе получается лишь 27 000 - почти половина регулярной выручки будто испаряется. Разбираю типичные ошибки, которые допускают команды при расчете MRR, и объясняю, почему одна и та же база клиентов может показывать совершенно разные цифры в зависимости от методики подсчёта.
Для кого
Фаундерам, CMO и маркетологам SaaS, онлайн-сервисов и платформ, которые планируют бюджет на продвижение и хотят считать его от плана по квалифицированным заявкам.
Кратко
Бюджет на продвижение онлайн-сервиса — это не одна строка «реклама» в таблице, а минимум три статьи расходов: медиабюджет и работа по каналам, команда с подрядчиками, инструменты и сервисы. Сумма выводится из плана по квалифицированным заявкам и стоимости такой заявки в каждом канале. Дальше — вилки по шести каналам, обратный расчёт от воронки и реальные цифры из сквозного дашборда по одному B2B-сервису.
На связи Дмитрий Шестаков, управляющий партнёр Сайткрафт. Мы продвигаем SaaS и онлайн-сервисы, и каждую неделю слышим один и тот же вопрос: сколько закладывать на продвижение. Обычно его задают так, будто существует единственно правильная цифра — 150, 300, 500 тысяч в месяц. Единственно правильной цифры не существует. Существует расчёт. Бюджет — это производная от того, сколько вам нужно квалифицированных заявок и сколько такая заявка стоит в каждом канале. С этого и начнём.
Содержание
1. Почему «возьмите 200 тысяч в месяц» — плохой ответ
2. Из каких статей вообще складывается бюджет
3. Сколько стоит каждый из 6 каналов
4. Как привязать бюджет к плану по лидам
5. Куда на самом деле утекает бюджет внутри канала
6. Три сценария бюджета: минимальный, рабочий, агрессивный
7. На чём чаще всего переплачивают
Всех приветсвую! В данной статье я не буду пояснять какие-то сложные вещи касательно нагрузочного тестирования. Просто хочется поделится своей болью, пронесенную сквозь года в разных enterprise системах. Может я не один такой?
Итак, представьте, что вы инженер по нагрузке...
Я работаю в контекстной рекламе и аналитике пять лет. Когда популярное расширение xml-river перестало работать, у тысяч специалистов сломался привычный сбор семантики через KeyCollector. Я решила проблему локально: написала десктопную программу на PySide6, которая напрямую работала с новым официальным API Wordstat. Программа продавалась с пожизненной лицензией, а пользователи ходили в API под моим личным токеном. Всё работало отлично, пока клиентов не стало слишком много: общий лимит в 5000 запросов в сутки превратился в массовые ошибки 429 Too Many Requests. Стало ясно: модель с общим токеном доживает дни. В этом посте — технический разбор того, как я за одну неделю полностью переписала архитектуру, перевела парсер на SaaS-модель (FastAPI + SQLite) с независимыми квотами для каждого пользователя. С кодом, схемами и честной юнит-экономикой
Для кого
Фаундерам, CMO и продактам SaaS, онлайн-сервисов и платформ, которые отвечают за выручку компании и устали оценивать рекламу по объему заявок. Тем, у кого между показом объявления и оплатой проходят недели и месяцы, а решение по бюджету каждый раз упирается в стоимость заявки.
Кратко
Стоимость заявки на сложном продукте показывает не то, ради чего вы тратите бюджет. Она дешевеет ровно тогда, когда в воронку идет необязательный поток. Ниже карта из семи метрик от показа до повторной продажи: что каждая измеряет, на какой вопрос отвечает и откуда брать данные. С таблицей, реальным сквозным дашбордом и разбором, почему дешевая по заявке кампания часто стоит с нулем сделок.
На связи Дмитрий, управляющий партнер Сайткрафта. У меня есть нелюбимый вопрос на встречах с фаундерами: по какой цифре вы решаете, что реклама работает. В девяти случаях из десяти отвечают одинаково, по стоимости заявки. И на длинном цикле это самая удобная и самая вредная метрика сразу. Удобная, потому что считается в один клик в любом рекламном кабинете. Вредная, потому что дешевеет именно тогда, когда в воронку идет поток необязательных контактов. Ниже без общих слов: почему так устроено и какие семь метрик стоит держать перед глазами вместо одной.
Содержание
1. Почему стоимость заявки врет на сложном продукте?
2. Карта от показа до повторной продажи: 7 метрик вместо одной
3. Сколько стоит квал и доходит ли он до сделки?
4. Цена клиента, окупаемость и пожизненная ценность: на что смотреть вместо заявки?
5. Почему канал нужно оценивать в горизонте сделки, а не за две недели?
Всем привет! Это Денис Сметнев. Последние пару месяцев я плотно сижу на вайбкодинге. Поднял свой сервер, запилил базу лидов из Телеграма и карту знаний, хотя последний раз кодил в 9 классе на Pascal. Вижу, что у многих появилась мысль: если я могу сам сделать себе любой софт под задачу, зачем тогда вообще нужны SaaS-продукты? Неужели они умрут? В этой статье хочу порассуждать, как на самом деле изменится рынок и почему хоронить софт пока рано.
«У нас есть рекуррентные платежи, значит подписки уже работают».
Обычно именно с этого начинается история появления собственной таблицы subscriptions, джобов в кроне для продления доступа, логики расчёта MRR и десятков исключений в коде. Разбираемся, какие задачи на самом деле решают рекуррентные платежи, где заканчивается их зона ответственности и почему многие SaaS-компании рано или поздно приходят к полноценному биллингу.
Нейросети уже отправляют на сайты теплый трафик. На реальном запросе и на цифрах нашего проекта показываю, от чего зависит попадание в их ответы и что мы для этого делаем.
Меня зовут Андрей Аврамчук, и я редактор в команде спецпроектов МТС Web Services. У меня много времени и сил отнимают созвоны, фидбеки, комментарии и ревью. Иногда они теряются, иногда я что-то оттуда забываю или не понимаю, а иногда не понимают меня.
Коллеги по МТС Web Services запустили MWS TeamStream. Продукт объединяет сервисы записи экрана, ИИ и облачных технологий, позволяет создавать короткие видео и быстро ими делиться по ссылке. С его помощью легко записывать видоекомментарии и ставить задачи. Формат меня заинтересовал, и я решил поэкспериментировать. Спойлер: изменился весь процесс правок материалов, которые поступают ко мне ежедневно огромным потоком. И неожиданно я прокачал бонусный навык. Какой — узнаете в конце статьи :)
Платёж не прошёл. Отключить пользователя сразу или подождать? Если подождать, то сколько и на каких условиях? Разбираем механику grace-периода изнутри: состояния подписки, поведение доступа для B2C и B2B, цепочку уведомлений и технические подводные камни.
Этот вопрос спрашивает каждый второй клиент, обращающийся за системой видеонаблюдения. У каждого свой вкус, поэтому наше мнение – лишь наш вкус от Спецлаб:
«Напишем сами, там простая логика», — так говорит каждая вторая команда из тех, с кем мы работаем. Простая логика оказывается льготными периодами, пересчётами при смене тарифа и разработчиком, который единственный знает, почему вот этому клиенту выставляется именно такая сумма. Четыре грабли и список того, что стоит заложить до первого клиента.
Последние месяцы я вижу одну и ту же мысль: SaaS умирает, AI-агенты забирают работу из интерфейсов, а компании перестают платить за пользовательские лицензии. На первый взгляд кажется, что так и есть.
Если агент может сам прочитать CRM, создать задачу, разобрать заявку, сходить в API и принести руководителю готовый статус, зачем держать десятки людей в системе? Пусть машина сама делает работу, а человек только проверяет.
Но когда смотришь на это изнутри SaaS-продукта, картина выглядит по-другому. Я работаю в Kaiten — мы делаем платформу для задач, проектов, документов, заявок и процессов. То есть находимся ровно в той модели, которую сейчас принято хоронить.
Последний год показал, что хоронить рано. Но и делать вид, что ничего не меняется, уже странно.
За последние годы я выучил наизусть классический набор инженерных рисков — упадёт сервер, отвалится канал к ДЦ, крешнется хард, потеряются бэкапы — и набор готовых решений под них. Это азбука, которая казалась исчерпывающей.
Но 2026 год преподнёс мне сюрприз. Создавая свой ИИ-стартап, я понял, что мир изменился, и в нём появился целый новый класс архитектурных рисков — таких, о которых в моей азбуке не было ни строчки. И ровно об эти новые риски я и пошёл спотыкаться.
Итак, усаживайтесь поудобнее и слушайте историю — историю про путешествия… путешествия нашей инфраструктуры и о реалиях разработки современных ИИ-стартапов из Москвы. Я расскажу вам о настоящем инженерном приключении, которое со мной произошло в процессе построения сервиса Mimirjotun.ru.
Я начал с requests.get() к Hysteria2 API, а через месяц получил рабочий VPN-сервис: FastAPI, React, PostgreSQL, JWT, Docker Compose, несколько VPS-нод, сбор трафика и автодеплой. А ещё выводы о работе с ИИ: где он ускоряет разработку, как улучшить качество кода и почему без собственного понимания проект быстро превращается в месиво.
Всем привет!
После публикации прошлой статьи про шаблон для микропроектов я получил много полезной критики. Часть замечаний оказалась настолько хорошей, что я решил пересобрать некоторые архитектурные решения и заодно переосмыслить сам подход к MVP-разработке в эпоху AI-агентов.
В конце статьи я оставлю ссылку на свой DEV-блог, если захотите узнать больше о соло-разработке SaaS продуктов.
Первым делом давайте разберём пару интересных замечаний с прошлой публикации и проработаем их. Если что, версия шаблона, которую мы улучшаем в гите в коммите 55505089d7fee07e1579839b2983b7c8f4227d7c.
Для разработчиков умных камер, умных видеорегистраторов и нейросетевой видеоаналитики ПО видеонаблюдения нужна нейросеть, способная работать в реальных условиях наших улиц. А там никто с профессиональной камерой не ходит, правильный ракурс не настраивает, свет не выставляет, без сжатия не снимает и вообще все делает вопреки здравому смыслу учебников ВГИК.
Гамбит, конечно, подойдет для любых других задач, но здесь сделан упор на удобство сбора материала ИЗ систем видеонаблюдения и на разметку датасета с целью создания нейросетей ДЛЯ систем видеонаблюдения.
Гамбит не столько для отшлифованных фоток и рилсов из Интернета, а как раз наоборот – для не особо качественных видеозаписей из архивов видеонаблюдения. В Спецлабе называют такой контент «диким».
Глаза дают человеку только 20% зрительной информации, остальное додумывает мозг. А может ли ИИ додумывать то, чего невидно?
Нейросеть «скелетон» - одна из первых систем видеонаблюдения с ИИ, которая демонстрирует способности такого скрытого зрения.
Текстом сложно объяснить то, что надо видеть: