Как я запустил свой первый SaaS-проект работая по найму целый день

в 12:31, , рубрики: cron, crontab, SaaS, SaaS / S+S, start-up, стартап

Привет! Представляю вашему вниманию перевод статьи How I Shipped My First SaaS Side Project While Working Full Time Тиграна Хакобяна, который работая в известном сервисе отложенного постинга Buffer смог запустить свой проект и даже его монетизировать.

Как я запустил свой первый SaaS-проект работая по найму целый день - 1

Это моя личная история о том, как я запустил свой первый SaaS-проект, работая 40 часов в неделю в Buffer. Цель этой статьи — вдохновить вас. Если вы такой, как я, у которого есть работа на полный рабочий день, и вы хотите построить прибыльный побочный бизнес в качестве источника дохода, тогда эта история вызовет у вас отклик. В этой статье я хочу показать, что я нисколько не вспотел или переработал и, тем не менее, мог предложить реально работающий SaaS-продукт.

Введение

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

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

Идея

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

  • Я хотел решить какую-то настоящую проблему, возможно, ту, с которой лично сталкивался
  • Это должно было быть для рынка, который я хорошо знаю
  • Это не должно быть новой идеей (это не изменит мир)
  • Это могло бы стать каким-то бизнесом

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

image
Мои записи, где я сохранял все идеи

С самого начала я знал, что, вероятно, могу быть более успешным, если создам что-то для разработчиков, потому что знаю рынок довольно хорошо, и большинство моих близких друзей и фолловеров технически подкованы. Я мог использовать свои контакты и аудиторию, чтобы подтвердить идею и получить ценные отклики, прежде чем решиться на что-либо. Это действительно сократило все мои идеи до списка из 2-3 вещей, над которыми я мог работать. В одной из идей было то, к чему я постоянно возвращался снова и снова. Это было то, с чем я столкнулся как в сервисе Buffer, так и во время работы над моими предыдущими параллельными проектами. Простой способ контролировать запланированные задания в cron. Поскольку одна из областей, которыми я занимаюсь в Buffer — инфраструктура данных аналитики, я запустил дюжину заданий в cron в фоновом режиме для сбора ежедневных аналитических данных для наших клиентов. Это должно было быть всем актуально. Сервис мониторинга Datadog, который мы используем в Buffer, действительно великолепен, но он изначально предназначен для мониторинга продолжительно работающих сервисов или серверов. Мне была нужна простая панель инструментов, где бы я мог видеть список всех моих заданий в cron, их статусов и журналов. Каждый день получаю отчет обо всех запущенных заданиях, поэтому знаю, что все идет по плану.

Выбрав эту идею, я хотел узнать, есть ли на рынке работающие решения. Если решения есть — это хороший признак того, что имеется спрос на определенные инструменты. Фактически, на рынке были пара решений с различными платными планами. Я не обязательно хотел создать что-то совершенно новое, потому что, если бы я это сделал, было бы намного сложнее определить и проверить рынок. Все существующие решения имели платные планы, поэтому я знал, что люди готовы заплатить за это. Следующей целью было оценить правильность моей мысли, создав и запустив MVP.

MVP

Я потратил 2 месяца на создание первой версии Cronhub (да, я дал ей имя). Что-то жизнеспособное, что я мог бы послать на пробу куче моих друзей и фолловеров в Твиттере. Для MVP мне нужно было что-то очень простое, но и достаточно ценное, за что люди будут платить. Я знаю, вы можете подумать, что 2 месяца — это долгое время для создания MVP, но я не принял традиционный подход «работы до пота» и вместо этого:

  • Работал только 1-2 часа каждый день
  • Спал 8 часов каждый день.
  • Смотрел Netflix всякий раз, когда хотел.
  • Полностью отдыхал в выходные дни.
  • Использовал все технические решения, с которыми мне было комфортно.

Поскольку я работаю полный рабочий день, я работал над Cronhub обычно с 7 до
8:30 вечера, я мог бы также работать по утрам, но большую часть утра я проводил в спортзале. Было несколько дней, когда я чувствовал себя умственно истощенным после работы, и я притормаживал, но большую часть времени я придерживался своей ежедневного графика. Я знал, что если я хочу закончить этот проект, мне надо было сохранить заряд и коммитить каждый день, даже если это небольшой коммит (может быть даже коммит из одной строчки). Концентрация всегда была очень полезна для меня, чтобы двигаться дальше. Я использовал Trello для разбивки моих задач проекта на небольшие этапы.

image
Моя доска Trello для Cronhub

Я пытался сделать каждую задачу настолько маленькой, чтобы мог начать и закончить за один день. Сохранение задач небольшими помогло мне быстрее запустить продукт и увидеть мой ежедневный прогресс. Когда вы видите какой-то прогресс, он во многом мотивирует и поддерживает вас в работе. Может это трюк над разумом? Работа над большими задачами замедляет нас и, в конце концов, мы сдаемся, потому что нам скучно, и нам хочется поработать над чем-то еще. Я никогда не работал ночью. Ложился спать около 10:30 каждый день и просыпался в 7. Правильный сон — мой приоритет номер один. Он определяет ментальную энергию, которая есть в течение дня, и я не могу ей пожертвовать. Помимо сна, я решил потратить большую часть своих выходных на то, чтобы сделать что-то совершенно другое, типа поиграть в футбол, смотреть фильмы или общаться с друзьями и семьей. Несмотря на то, что мне нравится кодить, я знаю, что легко сжечь себя. Выходные помогли мне освежить мой мозг.

Я думаю, что как разработчику вам всегда хочется использовать самые продвинутые и крутые технологии. Это нормально. Я тоже этого хочу. Однако, моя цель была другой, и я хотел построить и запустить Cronhub так быстро, как только мог, с опорой на технологии, которые я уже знал. Я концентрировался на своей цели и использовал Laravel и Vue.js. Cronhub — одностраничное приложение, использующее Laravel в качестве бэкэнда.

Закрытый бета-запуск

20 февраля я закончил минимум необходимой разработки Cronhub и был готов пригласить первую группу пользователей, чтобы попробовать Cronhub. После моего твита около 20-25 человек обратились ко мне в Twitter с просьбой о приглашении, и отзывы, которые я получил от них, были очень ценными.

image
Этот твит был был приглашением на закрытое бета-тестирование

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

Публичный запуск

Через три месяца, сегодня, я публично запускаю свой первый SaaS-проект. Ура!

Очевидно, я нервничаю и не знаю, будет это работать или нет. Однако, я знаю, что это приблизит меня на один шаг к моей цели. Цель — сделать Cronhub прибыльным онлайн-бизнесом, где я могу научиться и испытать все секреты ведения бизнеса. В конце концов, что хуже еще может случиться? Я бы многому научился!

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

Полученные уроки

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

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

  • Решите проблему, с которой вы лично сталкиваетесь. Это так важно, потому что по существу вы строите продукт для себя, всегда об этом помните. Это значительно облегчает принятие решений о продукте. Вы знаете, какие вопросы вы должны задать, и шансы выше, когда вы задаете правильные вопросы.
  • Уменьшайте свои задачи. Когда вы разбиваете свой проект на куски, старайтесь сделать их меньше. Хороший способ измерить размер задачи — спросить себя: «Могу ли я выполнить эту задачу за день?». Если ответ «Нет», то, вероятно, это большая задача, и вы можете разбить ее дальше.
  • Хорошо спите и отдыхайте. Не могу не подчеркнуть, насколько важен правильный сон. Вам не нужно работать ночью. Сосредоточьтесь на постепенном прогрессе и небольших ежедневных достижениях. Если вы не позаботитесь о себе, вы скоро устанете и в конце концов сдадитесь.
  • Выберите рынок, который вы хорошо знаете. Я разработчик, и я хорошо знаю этот рынок. Я знаю, что нужно, чтобы быть разработчиком и как сотрудничают команды разработчиков. Это дает мне представление о том, что будет и что не будет работать на этом рынке. Конечно, я все еще могу ошибаться, но шансов ошибиться намного меньше.
  • Расскажите о своем проекте. Это сложная задача для меня, и я все еще к этому приспосабливаюсь. Мне не очень нравится говорить о себе. Мне больше нравится слушать. Мне нелегко говорить о проекте, который я создаю, потому что я немного застенчив и не хочу создавать впечатление, что постоянно говорю о себе. Тем не менее, я знаю, что мне нужно выговориться и продать свой проект. Именно так другие узнают о моем продукте. Эта статья является примером этого.

В заключение

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

Продолжающий запускать продукты — Тигран.

Автор: marcovnik

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js