How We Built Larko: From Idea to Production SaaS

Why Build Our Own Product

DriveCode is a product studio. We don't just write code for clients. We decided that the only way to truly understand the pain of product teams is to become one ourselves.

Larko was born from a real problem: managing field teams (couriers, installers, technical staff) is chaos made of Excel spreadsheets, messengers, and manual money accounting.

Architecture: Multi-Tenant from Day One

We immediately designed a multi-tenant architecture, even though we had only one client at launch (ourselves). A decision that seemed excessive paid off: Larko now serves multiple independent companies from a single instance.

Stack:

• Frontend: Flutter (iOS, Android, Web) + Telegram Mini App (Next.js)
• Backend: Supabase (PostgreSQL + Edge Functions + Realtime)
• Infrastructure: Vercel (Web), Supabase Cloud (API), GitHub Actions (CI/CD)

First Three Months: MVP

We consciously limited the MVP to three modules:

• Orders — creation, assignment, statuses, GPS tracking
• Finance — advances, bonuses, corrections, worker balance
• Team — onboarding, roles (manager/worker), verification

Every week we conducted demos with real workers. Feedback was harsh but honest: "Too many buttons," "Where's my money from yesterday?", "I don't understand what this status means."

Key Mistakes

Mistake #1: Overly complex onboarding. Initially, we required workers to upload a passport photo, complete verification, and confirm their email. Result — 60% dropped off at the second step. We simplified to: name + phone + manager confirmation.

Mistake #2: Realtime everywhere. We connected Supabase Realtime to every table. Result — excessive WebSocket connection load and complex debugging. Now Realtime is used only for orders and chat.

Mistake #3: Ignoring offline mode. Field workers often operate in areas with poor coverage. We added Drift (SQLite ORM) for local caching and queue-based sync.

Financial Module — The Heart of the Product

Paradoxically, Larko's most important module turned out to be not order tracking, but financial accounting. Managers wanted to see each worker's balance in real time: how much earned, how many advances received, how many bonuses accrued.

We built a ledger-based system: every financial operation is a journal entry (credit/debit). Balance is calculated as the sum of all entries. This provides a complete audit trail and eliminates "disappearing money."

Lessons for Client Projects

Every mistake we made in Larko became a template for client projects:

• Onboarding: Maximum 3 steps. Everything else — after first use.
• Realtime: Only for critical data (orders, messages). Everything else — polling or optimistic UI.
• Offline: If the app is used "in the field" — offline-first is mandatory.
• Finance: Ledger-based accounting from day one, even if it seems excessive.

Result

Larko has been in production since February 2025. Five modules, three platforms, real users. This isn't a portfolio project — it's a living business with daily transactions, feedback, and bug fixes.