День 67 :: На этой неделе: готовимся к тестированию!
Следующая неделя станет ключевой – мы выходим на тестирование нашего MVP!
🔧 Что у нас уже готово:
1. Сайт-витрина – работает, выглядит круто и почти готов к приему первых пользователей.
2. Админ-панель – пока минимальная версия, но её достаточно для базового тестирования. Доработаем по ходу дела.
3. Портал продавца – регистрация и авторизация на месте. Пока это скорее лендинг, чем полноценный портал, но для старта – то, что нужно.
🔧 Что ещё в процессе:
4. Личный кабинет покупателя – проектируем.
5. Панель управления продавца – переносим из старой версии.
6. Панель курьера – только шаблон, но мы в процессе.
Итого готовность инструментов: 20–70%. А тестирование уже вот-вот начнется!
Задачи масштабные:
- Подключение партнёров
- Привлечение клиентов
- Организация работы курьеров
Успеем ли? Рынок ждёт наш сервис, и мы полны решимости!
Следите за обновлениями и не переключайтесь. Ваши лайки и комментарии – это топливо для нашей команды! 🚀
@achopochom — закулисье создания стартапа🦄
#mvp
Следующая неделя станет ключевой – мы выходим на тестирование нашего MVP!
🔧 Что у нас уже готово:
1. Сайт-витрина – работает, выглядит круто и почти готов к приему первых пользователей.
2. Админ-панель – пока минимальная версия, но её достаточно для базового тестирования. Доработаем по ходу дела.
3. Портал продавца – регистрация и авторизация на месте. Пока это скорее лендинг, чем полноценный портал, но для старта – то, что нужно.
🔧 Что ещё в процессе:
4. Личный кабинет покупателя – проектируем.
5. Панель управления продавца – переносим из старой версии.
6. Панель курьера – только шаблон, но мы в процессе.
Итого готовность инструментов: 20–70%. А тестирование уже вот-вот начнется!
Задачи масштабные:
- Подключение партнёров
- Привлечение клиентов
- Организация работы курьеров
Успеем ли? Рынок ждёт наш сервис, и мы полны решимости!
Следите за обновлениями и не переключайтесь. Ваши лайки и комментарии – это топливо для нашей команды! 🚀
@achopochom — закулисье создания стартапа🦄
#mvp
День 111 :: Ошибка номер один: как мы слишком поверили в AI и что из этого вышло 🤖💥
Ошибки — это не провал. Это уроки, которые делают нас сильнее. И сегодня я хочу рассказать о нашей главной ошибке, которая задержала запуск MVP, но зато научила нас двигаться быстрее и умнее.
В чём была ошибка?
Мы слишком сильно поверили в искусственный интеллект как в программиста. Да, AI — это мощный инструмент, который помогает писать код, генерировать идеи и даже находить баги. Но, как оказалось, он не идеален. 🛠️
Мы хотели, чтобы AI писал код сразу по всем правилам: с тестами, логированием, кэшированием и всем, что только есть в лучших практиках. Но такой подход съел кучу времени. Почему? Потому что AI пока не может писать безупречный код. И отладка, как известно, занимает до 90% времени разработки.
Что мы поняли?
1. MVP — это минимальный продукт.
Не нужно пытаться сделать всё идеально с первого раза. Тесты, логирование и прочие "плюшки" можно добавить позже. Главное — запустить и получить обратную связь от рынка.
2. Мелкие итерации — это спасение.
Мы перестроили процесс: теперь AI работает над небольшими задачами, а код сохраняется мелкими коммитами. Это позволяет в любой момент вернуться к стабильной версии, если что-то пошло не так.
3. Готовые модули — это круто.
Мы активно используем готовые "кубики" кода, которые встраиваем в наш сервис. Это экономит время и силы.
Что в итоге?
За три с небольшим месяца AI написал нам огромное количество кода (вот бы кто-то посчитал точное количество строк! 😄). Но главное — мы поняли, что только двигаясь мелкими итерациями и фокусируясь на MVP, можно достичь скорости, недоступной даже огромным командам разработчиков.
Что дальше?
Мы продолжаем работать, учиться на ошибках и двигаться вперёд. AI всё ещё наш главный помощник, но теперь мы знаем, как использовать его с умом.
А вы сталкивались с подобными ошибками? Делитесь в комментариях — обсудим!
@achopochom — закулисье создания стартапа🦄
#стартап #ошибки #AI #разработка #MVP
Ошибки — это не провал. Это уроки, которые делают нас сильнее. И сегодня я хочу рассказать о нашей главной ошибке, которая задержала запуск MVP, но зато научила нас двигаться быстрее и умнее.
В чём была ошибка?
Мы слишком сильно поверили в искусственный интеллект как в программиста. Да, AI — это мощный инструмент, который помогает писать код, генерировать идеи и даже находить баги. Но, как оказалось, он не идеален. 🛠️
Мы хотели, чтобы AI писал код сразу по всем правилам: с тестами, логированием, кэшированием и всем, что только есть в лучших практиках. Но такой подход съел кучу времени. Почему? Потому что AI пока не может писать безупречный код. И отладка, как известно, занимает до 90% времени разработки.
Что мы поняли?
1. MVP — это минимальный продукт.
Не нужно пытаться сделать всё идеально с первого раза. Тесты, логирование и прочие "плюшки" можно добавить позже. Главное — запустить и получить обратную связь от рынка.
2. Мелкие итерации — это спасение.
Мы перестроили процесс: теперь AI работает над небольшими задачами, а код сохраняется мелкими коммитами. Это позволяет в любой момент вернуться к стабильной версии, если что-то пошло не так.
3. Готовые модули — это круто.
Мы активно используем готовые "кубики" кода, которые встраиваем в наш сервис. Это экономит время и силы.
Что в итоге?
За три с небольшим месяца AI написал нам огромное количество кода (вот бы кто-то посчитал точное количество строк! 😄). Но главное — мы поняли, что только двигаясь мелкими итерациями и фокусируясь на MVP, можно достичь скорости, недоступной даже огромным командам разработчиков.
«Я промахнулся более 9000 раз за свою карьеру. Я проиграл почти 300 игр. 26 раз мне доверяли сделать победный бросок, и я промахнулся. Именно поэтому я добился успеха».
Майкл ДжорданЧто дальше?
Мы продолжаем работать, учиться на ошибках и двигаться вперёд. AI всё ещё наш главный помощник, но теперь мы знаем, как использовать его с умом.
А вы сталкивались с подобными ошибками? Делитесь в комментариях — обсудим!
@achopochom — закулисье создания стартапа🦄
#стартап #ошибки #AI #разработка #MVP
День 116 :: Почему мы всё ещё не запустили MVP? Или как Alibaba научила нас не торопиться (но всё равно страшно) 🚀💥
Знаете, в стартапах есть два типа людей: те, кто запускает MVP на коленке за неделю, и те, кто хочет построить космический корабль с первого дня. Мы — вторые. И вот почему.
Проблема: мы не умеем делать «плохо»
Представьте, что вы печете торт. Можно купить готовую смесь, замесить за 5 минут и получить съедобный результат. Но нет — я хочу вырастить пшеницу, собрать ваниль с Мадагаскара и взбить масло вручную. Шутка. Но в ней есть доля шутки.
Наша цель на год — запустить доставку в Крыму. Казалось бы, что может быть проще, чем создание функционала для ОДНОЙ БАЗОВОЙ ТРАНЗАКЦИИ:
1. Разместить тестовый товар.
2. Добавить корзину.
3. Позвать курьера.
4. Profit!
Ну а дальше то что? Клиенты скажут - хотим! А у нас вместо сервиса - Потемкинская деревня.
Поэтому мы хотим сразу рабочую систему, которая выдержит сотни тысяч заказов в секунду, как Alibaba. Или круче. Потому что иначе — зачем? Зачем затевать какую-то фигню на полтора заказа в день?
---
Вот вам отрывок из книги «Alibaba и умный бизнес будущего»:
Вывод: если все строить «на коленке», потом будет больно. Очень.
Почему мы не можем просто «запуститься»?
1. Архитектура — это как фундамент небоскрёба.
Можно построить сарай за день, но когда вы решите вырастить его до 100 этажей, он рухнет. Мы выбираем небоскрёб.
2. Масштаб или смерть.
Наш MVP — не «корзина и курьер». Это система, которая должна обрабатывать тысячи транзакций в секунду, иметь отказоустойчивость, кэширование, распределённые сервисы. Иначе — коллапс, как у Alibaba в 2012.
3. Технологии — это не «допилим потом».
Если сегодня написать код без тестов, завтра он превратится в спагетти-монстра, который съест все наши ресурсы.
---
Что мы делаем вместо запуска?
- Строим систему, которая масштабируется горизонтально.
Чтоб завтра можно было добавить серверов — и она не сдохла.
- Пишем тесты. Много тестов.
Да, это долго. Но когда придёт лавина заказов, мы не хотим, чтобы код напоминал карточный домик.
- Учимся на ошибках гигантов.
Alibaba, Amazon, Netflix — все они прошли через ад масштабирования. Мы просто не хотим повторять их ошибки.
---
Когда же запуск?
Скоро. Очень скоро. Но сначала мы должны быть уверены, что когда вы нажмёте «купить», система не скажет: «Ой, всё».
А пока — спасибо за терпение. Помните: мы строим не сарай. Мы строим космодром. 🚀
@achopochom — закулисье создания стартапа🦄
#стартап #MVP #технологии #масштабирование #Alibaba
Знаете, в стартапах есть два типа людей: те, кто запускает MVP на коленке за неделю, и те, кто хочет построить космический корабль с первого дня. Мы — вторые. И вот почему.
Проблема: мы не умеем делать «плохо»
Представьте, что вы печете торт. Можно купить готовую смесь, замесить за 5 минут и получить съедобный результат. Но нет — я хочу вырастить пшеницу, собрать ваниль с Мадагаскара и взбить масло вручную. Шутка. Но в ней есть доля шутки.
Наша цель на год — запустить доставку в Крыму. Казалось бы, что может быть проще, чем создание функционала для ОДНОЙ БАЗОВОЙ ТРАНЗАКЦИИ:
1. Разместить тестовый товар.
2. Добавить корзину.
3. Позвать курьера.
4. Profit!
Ну а дальше то что? Клиенты скажут - хотим! А у нас вместо сервиса - Потемкинская деревня.
Поэтому мы хотим сразу рабочую систему, которая выдержит сотни тысяч заказов в секунду, как Alibaba. Или круче. Потому что иначе — зачем? Зачем затевать какую-то фигню на полтора заказа в день?
---
Вот вам отрывок из книги «Alibaba и умный бизнес будущего»:
В первые несколько лет после начала распродаж лавинообразное нарастание трафика приводило к выходу из строя серверов Alibaba, коллапсу банковских платежных каналов и прекращению работы сетей, принимающих заказы, по всей стране. После 2012 г., когда утроение объема транзакций практически парализовало систему и задержало доставку заказов на несколько недель, Alibaba и ее многочисленные партнеры постоянно работают над повышением пропускной способности и эффективности логистической системы.
...
Близилась полночь, пальцы пользователей по всей стране, как, впрочем, и по всему миру, застыли в ожидании над экранами смартфонов — в Китае заказы в основном делаются через мобильные устройства. Громкость музыки в центре управления усилилась, когда начался обратный отсчет — пять, четыре, три, два, один.
Чудо происходило у меня на глазах. За 11 секунд объем продаж через нашу платформу достиг 100 млн юаней ($15 млн); 17 секунд спустя — 1 млрд ($150 млн). При этом 97% заказов поступило с мобильных устройств. Лучшие предложения шли нарасхват. Те, кто медлил с оформлением заказа хотя бы несколько секунд, обнаруживали, что продукты, выбранные ими за последний месяц, уже проданы.
Через три минуты объем продаж составлял уже 10 млрд юаней ($1,5 млрд). Потребовался всего час, чтобы достичь совокупного объема продаж за День холостяка в 2014 г., а впереди было целых 23 часа. На пике активности платформы Alibaba обрабатывали 325 000 заказов и 256 000 платежей каждую секунду.
Вывод: если все строить «на коленке», потом будет больно. Очень.
Почему мы не можем просто «запуститься»?
1. Архитектура — это как фундамент небоскрёба.
Можно построить сарай за день, но когда вы решите вырастить его до 100 этажей, он рухнет. Мы выбираем небоскрёб.
2. Масштаб или смерть.
Наш MVP — не «корзина и курьер». Это система, которая должна обрабатывать тысячи транзакций в секунду, иметь отказоустойчивость, кэширование, распределённые сервисы. Иначе — коллапс, как у Alibaba в 2012.
3. Технологии — это не «допилим потом».
Если сегодня написать код без тестов, завтра он превратится в спагетти-монстра, который съест все наши ресурсы.
---
Что мы делаем вместо запуска?
- Строим систему, которая масштабируется горизонтально.
Чтоб завтра можно было добавить серверов — и она не сдохла.
- Пишем тесты. Много тестов.
Да, это долго. Но когда придёт лавина заказов, мы не хотим, чтобы код напоминал карточный домик.
- Учимся на ошибках гигантов.
Alibaba, Amazon, Netflix — все они прошли через ад масштабирования. Мы просто не хотим повторять их ошибки.
---
Когда же запуск?
Скоро. Очень скоро. Но сначала мы должны быть уверены, что когда вы нажмёте «купить», система не скажет: «Ой, всё».
А пока — спасибо за терпение. Помните: мы строим не сарай. Мы строим космодром. 🚀
@achopochom — закулисье создания стартапа🦄
#стартап #MVP #технологии #масштабирование #Alibaba
День 117 :: Почему PostgreSQL замедляет наш MVP, но это того стоит 🐘💡
Если бы стартапы были кулинарией, то переход с MySQL на PostgreSQL — это как поменять газовую плиту на молекулярную кухню. Всё сложнее, дольше, но результат... Когда-нибудь он будет фантастическим. А пока объясняем, почему мы «допиливаем» и терпим.
---
Почему PostgreSQL задерживает наш MVP?
1. «Мы учимся заново готовить»
Раньше мы жили в уютном мире MySQL, где JOIN-ы были простыми, а запросы — предсказуемыми.
Теперь — погружаемся в PostgreSQL с его:
- CTE (Common Table Expressions) — это как SQL на стероидах.
- Оконными функциями — чтобы делать аналитику в одном запросе.
- JSONB — потому что NoSQL внутри SQL это круто (и сложно).
Итог: Пишем запросы в 2 раза дольше, но они в 10 раз мощнее.
---
2. «Микросервисы требуют магии»
Наш сервис — это не монолит, а оркестр из микросервисов. PostgreSQL тут — дирижёр, который должен:
- Синхронизировать данные между сервисами без конфликтов.
- Обрабатывать сложные JOIN между 100+ таблицами (спасибо, что вообще есть).
- Масштабироваться так, чтобы не упасть при первом же наплыве заказов.
Пример: Запрос для расчёта оптимального маршрута курьера в реальном времени — это не
---
3. «Тестирование — это ад»
Раньше в MySQL мы проверяли запросы за 5 минут. Теперь:
- EXPLAIN ANALYZE — чтобы понять, почему запрос тормозит.
- Индексы-призраки — то создашь, то удалишь, а они всё равно не работают.
- Репликация и шардирование — потому что «надо сразу делать как у взрослых».
Почему мы не откажемся от PostgreSQL?
1. Сложные запросы = гибкость
- Геоданные — ищем ближайших курьеров через PostGIS.
- Полнотекстовый поиск — чтобы пользователи находили «крымский сыр» даже с опечаткой.
- Триггеры и процедуры — автоматизируем всё, что можно.
2. Надёжность > скорость
MySQL падал при 1000 одновременных запросов. PostgreSQL держит удар даже при 10 000.
3. Будущее уже здесь
Когда мы масштабируемся до уровня Alibaba (а мы масштабируемся!), PostgreSQL позволит:
- Горизонтально масштабировать базу через Citus.
- Работать с Petabytes данных без переписывания кода.
- Строить real-time аналитику прямо в БД.
---
Что в итоге?
Да, мы тормозим. Но только потому, что:
- Пишем не «костыли», а архитектуру на 5 лет вперёд.
- Учимся работать с инструментом уровня Enterprise.
- Готовимся к тому, что наш MVP превратится в монстра с 500 000 RPS.
P.S. Если бы Илон Маск спешил, SpaceX до сих пор запускала бы ракеты на MySQL.
@achopochom — закулисье создания стартапа🦄
#стартап #PostgreSQL #MVP #техдолг #микросервисы
Если бы стартапы были кулинарией, то переход с MySQL на PostgreSQL — это как поменять газовую плиту на молекулярную кухню. Всё сложнее, дольше, но результат... Когда-нибудь он будет фантастическим. А пока объясняем, почему мы «допиливаем» и терпим.
---
Почему PostgreSQL задерживает наш MVP?
1. «Мы учимся заново готовить»
Раньше мы жили в уютном мире MySQL, где JOIN-ы были простыми, а запросы — предсказуемыми.
Теперь — погружаемся в PostgreSQL с его:
- CTE (Common Table Expressions) — это как SQL на стероидах.
- Оконными функциями — чтобы делать аналитику в одном запросе.
- JSONB — потому что NoSQL внутри SQL это круто (и сложно).
Итог: Пишем запросы в 2 раза дольше, но они в 10 раз мощнее.
---
2. «Микросервисы требуют магии»
Наш сервис — это не монолит, а оркестр из микросервисов. PostgreSQL тут — дирижёр, который должен:
- Синхронизировать данные между сервисами без конфликтов.
- Обрабатывать сложные JOIN между 100+ таблицами (спасибо, что вообще есть).
- Масштабироваться так, чтобы не упасть при первом же наплыве заказов.
Пример: Запрос для расчёта оптимального маршрута курьера в реальном времени — это не
SELECT * FROM orders. Это 15 вложенных подзапросов, 3 оконные функции и молитва. ---
3. «Тестирование — это ад»
Раньше в MySQL мы проверяли запросы за 5 минут. Теперь:
- EXPLAIN ANALYZE — чтобы понять, почему запрос тормозит.
- Индексы-призраки — то создашь, то удалишь, а они всё равно не работают.
- Репликация и шардирование — потому что «надо сразу делать как у взрослых».
Почему мы не откажемся от PostgreSQL?
1. Сложные запросы = гибкость
- Геоданные — ищем ближайших курьеров через PostGIS.
- Полнотекстовый поиск — чтобы пользователи находили «крымский сыр» даже с опечаткой.
- Триггеры и процедуры — автоматизируем всё, что можно.
2. Надёжность > скорость
MySQL падал при 1000 одновременных запросов. PostgreSQL держит удар даже при 10 000.
3. Будущее уже здесь
Когда мы масштабируемся до уровня Alibaba (а мы масштабируемся!), PostgreSQL позволит:
- Горизонтально масштабировать базу через Citus.
- Работать с Petabytes данных без переписывания кода.
- Строить real-time аналитику прямо в БД.
---
Что в итоге?
Да, мы тормозим. Но только потому, что:
- Пишем не «костыли», а архитектуру на 5 лет вперёд.
- Учимся работать с инструментом уровня Enterprise.
- Готовимся к тому, что наш MVP превратится в монстра с 500 000 RPS.
P.S. Если бы Илон Маск спешил, SpaceX до сих пор запускала бы ракеты на MySQL.
@achopochom — закулисье создания стартапа🦄
#стартап #PostgreSQL #MVP #техдолг #микросервисы