Source: founder discussion between Iman Suherman and Herry Suryo Nugroho (WhatsApp, culminating 31 Aug 2026), including Personal Cloud Backup clarifications the same day.
This file records product and delivery decisions only. Personal / unrelated topics from the chat are intentionally excluded.
Partnership
| Topic | Decision |
|---|---|
| Collaboration | Build apps together; Alocare-style (no salary between founders) |
| Roles | Herry — Android + Windows; Iman — backend + iOS + macOS + control-plane / specs |
| Delivery workflow | All four clients reach acceptance together per phase; public release is simultaneous (ADR-003) |
| Infra cost (early) | Keep backend cheap; free tier must not explode server data |
| Org | GitHub org per product: lakuyo-id |
| Company holding name | Deferred; ship product-first under Lakuyo |
Product selection
| Topic | Decision |
|---|---|
| First product | Lakuyo merchant commerce app |
| Core domains | POS + Inventory are both first-class core parts of Lakuyo |
| Expansion | Order Management, restaurant flows, multi-outlet, advanced reporting, customer membership (POS-024) |
| Customer membership (POS-024) | Merchant-run store membership: register pelanggan member, member vs walk-in pricing, admin-configurable discounts, purchase history per member only — walk-in sales have no customer profile history (stakeholder input, Franky Marbun, 31 Aug 2026) |
| Later ideas (not scheduled) | Gym class/membership management as a standalone product and other vertical apps |
Domain vocabulary
- POS — checkout and transaction processing (Cart, Checkout, Payment, Receipt, Sale / transaction history).
- Inventory — product and stock management (Product catalogue, stock quantity, receiving / adjustment, Stock movement history).
- Order Management — separate domain; expands later; Order ≠ Sale.
- Order — customer-requested items before final checkout; an Order is not a completed Sale.
- Sale — completed commercial transaction after checkout/payment confirmation.
- Sales — staff role that assists customers and may create an Order; it does not mean a completed Sale.
- Waiter — restaurant/café-specialized Sales/order-taking role.
Canonical domain architecture:
Lakuyo
├── POS
│ ├── Cart
│ ├── Checkout
│ ├── Payment
│ ├── Receipt
│ └── Sale / transaction history
│
├── Inventory
│ ├── Product catalogue
│ ├── Stock quantity
│ ├── Receiving / adjustment
│ └── Stock movement history
│
└── Customer membership (Phase 3, POS-024)
├── Member registry (pelanggan member)
├── Member vs walk-in pricing
├── Admin membership discounts
└── Member purchase history
Order Management
→ separate domain
→ expands later
→ Order ≠ SaleSee Product/Domain Terminology for the canonical vocabulary.
Brand
| Topic | Decision |
|---|---|
| Product name | Lakuyo — local / Javanese feel (“kearifan lokal”), distinctive vs crowded kasir/toko names |
| Rejected / conflicted names | Laku, Kasira, Kasio, Larisku, Tokoku, and others colliding with existing POS/brands |
| Domains | Prefer a proper product domain (not personal suherman.net / nugroho.me long-term); exact domain TBD after availability + trademark checks |
See Product/Brand Name Lakuyo.
Commercial model
| Topic | Decision |
|---|---|
| Product rule | Local-first by default, cloud-enhanced when you need it. |
| Free | Single-device operation, local SQLite only, no Lakuyo backend |
| Free capability | Core POS + Inventory and manual local backup/restore remain usable without a Lakuyo account |
| Main Phase 1 backup feature | POS-008 Backup & Restore includes free local backup and Personal Cloud Backup |
| Personal Cloud Backup provider | Google Drive on Android, iOS, macOS, and Windows (merchant’s own Google account) — not iCloud, so backup lineage is cross-platform compatible |
| Personal Cloud Backup unlock | One-time, store-managed non-consumable purchase; indicative price ≈ Rp100.000; also included while Pro is active |
| Automatic backup | Included and ON by default after Google Drive authorization; user may turn it off; manual Back Up Now remains available |
| What is backed up | Local SQLite database and product images (and related merchant-owned backup payload defined by POS-008) |
| Storage cost / quota | Merchant’s Google Drive account; Lakuyo does not host Personal Cloud Backup data; size limits follow the merchant’s Google Drive plan |
| Backup boundary | Disaster recovery/device replacement only — not coordinated multi-device sync and not Lakuyo cloud backup |
| Purchase scope | Platform/store scoped unlock; each client’s store restores its own purchase; storage is Google Drive on all four clients |
| Restore Purchase | Required on the unlock page as an explicit way to recover prior one-time ownership; app should also auto-query ownership when practical |
| Paid subscription | Multi-device, Lakuyo cloud sync/backup, and related cloud services via subscription |
| Subscription billing | Google Play Billing / App Store so recurring payment is store-managed |
| Why free is local-only | Prevent free-tier data growth from blowing backend cost |
Backup product boundary
- POS-008 / Free local backup — manual local backup / restore; no purchase required.
- POS-008 / Personal Cloud Backup (Drive Backup) — main Phase 1 capability; Google Drive on all four clients; ≈ Rp100.000 one-time unlock or active-Pro inclusion; automatic backup default ON; Lakuyo backend stays free of free-tier storage cost (
user ↔ Google). - POS-014 / Pro cloud backup — recurring subscription; Lakuyo-managed cloud capability (multi-device sync path).
Personal Cloud Backup is not TBD and does not require a separate future spec ID. It belongs inside POS-008.
Pro downgrade
- If Pro ends, local POS + Inventory continues as Free.
- Existing Personal Cloud Backup data in Google Drive is never deleted because entitlement expired.
- Existing Personal Cloud Backup may still be restored for disaster recovery.
- A prior one-time Personal Cloud Backup purchase remains owned forever and can be rediscovered with Restore Purchase.
- Pro membership by itself does not grant lifetime ownership: if the merchant never bought the one-time unlock, new Personal Cloud Backup writes and automatic backup lock when Pro ends until they buy once or renew Pro.
Backup lineage / single active writer
Free and Personal Cloud Backup support one active operational device, not coordinated multi-device use. Lakuyo should not add backend DRM solely to prevent manual copying. POS-008 instead protects data integrity:
- Backups carry stable lineage metadata, including source installation, revision, timestamp, and schema/format version.
- Google Drive metadata identifies one active cloud-backup writer for a backup lineage.
- Restoring onto another installation requires explicit confirmation that the new installation becomes the active backup writer.
- The previous installation remains usable locally but cannot continue writing that Personal Cloud Backup until ownership is explicitly reclaimed.
- Divergent local databases are not merged; concurrent coordinated operation requires Pro sync.
The backup contract must be versioned and migration-safe rather than defined as simply copying a raw SQLite database file. All four clients share the same Google Drive backup contract so a merchant can restore across platforms when using the same Google account.
Merchant payments (in-store)
| Topic | Decision |
|---|---|
| Small merchants | Manual settlement: cash, EDC, or merchant’s existing static QRIS — cashier confirms payment in POS |
| Larger merchants (optional) | Integrate a PSP such as Doit later — not forced on small merchants (≈ Rp200k/mo + per-txn fees is too heavy for many warung) |
| Own payment platform | Out of scope early (licensing hard); use third party until scale justifies cutting middleman |
Devices & UX
| Topic | Decision |
|---|---|
| Client platforms | Android, iOS, macOS, Windows — all first-class; released together per phase (ADR-003) |
| Counter hardware | Android-based POS terminals via Android client; Mac/Windows for counter PC/laptop |
| Form factors | Phone, tablet, Mac, and Windows PC/laptop |
| Phone use cases | Waiter/Sales order-taking; inventory and stock checks while walking the floor |
| UX principle | POS must stay simple and fast — cashiers work under time pressure |
Roles (entities)
Initial role set agreed for design:
- Admin — setup, catalogue, configuration, entitlements
- Kasir — checkout and payment completion
- Sales — customer assistance / order-taking; broader than café-only Waiter
- Inventory — stock operations
- Waiter — café/resto-specialized Sales/order-taking role (phone)
A person may hold multiple roles. One person on one active operational device may perform all roles on Free. Distinct coordinated devices generally imply paid multi-device sync.
Engineering implication
These decisions are authoritative inputs to product/, architecture/, and specs/. Domain nouns should remain explicit in code and contracts: prefer Order, Sale, Payment, Product, and StockMovement over ambiguous uses of “sales”.
Implementation PRs still require a specification ID per RULES.md.
External feedback (Ex VM, 31 Aug 2026)
Source: Ex VM WhatsApp group after Lakuyo early-access announcement. Product narrative detail: Product/Competitive Landscape.
| Topic | Input | Decision |
|---|---|---|
| Mac/Windows desktop app | Pricool asked about installers; Andre initially advised defer | Revised: macOS + Windows are Phase 1 clients; all four platforms release together (ADR-003) |
| Platform priority | Andre: stay mobile for starters | Mobile and desktop counter (Mac/Windows) for merchants on any device they already own |
| Counter hardware | Andre: Android POS vendors | Android POS terminals plus native macOS/Windows for counter PC use |
| paper.id | Sonny: current user; review for adjustments | Capture competitive notes; keep free core POS + manual payments; basic accounting only in Phase 1 |
| Moka / fees | Pricool: fee comparison | Emphasise Rp0 recurring single-device core vs subscription-led incumbents |
| Gateway-fee model | Andre: paper.id ≈ Doku SME | Optional future PSP revenue (POS-015) for opt-in merchants; not Phase 1 dependency |