Як ми побудували Larko: від ідеї до production SaaS

Навіщо будувати свій продукт

DriveCode — це product studio. Ми не просто пишемо код для клієнтів. Ми вирішили, що єдиний спосіб по-справжньому зрозуміти біль продуктових команд — стати такою командою самим.

Larko народився з реальної проблеми: управління польовими командами (кур'єри, монтажники, технічний персонал) — це хаос із Excel-таблиць, месенджерів та ручного обліку грошей.

Архітектура: Multi-Tenant з першого дня

Ми одразу закладали multi-tenant архітектуру, хоча на старті мали лише одного клієнта (себе). Рішення, яке здавалося надмірним, окупилося: зараз Larko обслуговує кілька незалежних компаній з одного інстансу.

Стек:

• Frontend: Flutter (iOS, Android, Web) + Telegram Mini App (Next.js)
• Backend: Supabase (PostgreSQL + Edge Functions + Realtime)
• Інфраструктура: Vercel (Web), Supabase Cloud (API), GitHub Actions (CI/CD)

Перші три місяці: MVP

Ми свідомо обмежили MVP до трьох модулів:

• Замовлення — створення, призначення, статуси, GPS-трекінг
• Фінанси — аванси, бонуси, корекції, баланс воркера
• Команда — онбординг, ролі (менеджер/воркер), верифікація

Щотижня ми проводили демо з реальними воркерами. Фідбек був жорстким, але чесним: «Занадто багато кнопок», «Де мої гроші за вчора?», «Я не розумію, що це за статус».

Головні помилки

Помилка #1: Занадто складний онбординг. Спочатку ми вимагали від воркерів завантажити фото паспорта, пройти верифікацію та підтвердити email. Результат — 60% відвалювались на другому кроці. Ми спростили до: ім'я + телефон + підтвердження менеджера.

Помилка #2: Realtime всюди. Ми підключили Supabase Realtime до кожної таблиці. Результат — зайве навантаження на WebSocket-з'єднання та складний дебаг. Зараз Realtime використовується тільки для замовлень та чату.

Помилка #3: Ігнорування офлайн-режиму. Польові воркери часто працюють у зонах з поганим покриттям. Ми додали Drift (SQLite ORM) для локального кешування і queue-based sync.

Фінансовий модуль — серце продукту

Парадоксально, але найважливішим модулем Larko виявився не трекінг замовлень, а фінансовий облік. Менеджери хотіли бачити баланс кожного воркера в реальному часі: скільки заробив, скільки авансів отримав, скільки бонусів нараховано.

Ми побудували ledger-based систему: кожна фінансова операція — це запис у журналі (credit/debit). Баланс обчислюється як сума всіх записів. Це дає повну аудиторську trail та виключає «зникнення грошей».

Уроки для клієнтських проєктів

Кожна помилка, яку ми зробили в Larko, стала шаблоном для клієнтських проєктів:

• Онбординг: Максимум 3 кроки. Все інше — після першого використання.
• Realtime: Тільки для критичних даних (замовлення, повідомлення). Решта — polling або optimistic UI.
• Офлайн: Якщо додаток використовується «в полі» — offline-first обов'язковий.
• Фінанси: Ledger-based облік з перших днів, навіть якщо здається надмірним.

Результат

Larko працює в продакшні з лютого 2025 року. П'ять модулів, три платформи, реальні користувачі. Це не портфоліо-проєкт — це живий бізнес із щоденними транзакціями, фідбеком та багфіксами.