# 08 — How the Major Players Build It (settles D8)

Brainstorm requested by founder: how do the major players architect these systems, and
what does that mean for our Android-POS question? Based on market knowledge through
early 2026 — verify specifics before quoting externally.

## India — the incumbents and challengers

| Player | Segment | Client architecture | Offline strategy | Lesson for us |
|--------|---------|--------------------|--------------------|---------------|
| **TallyPrime** | Accounting + inventory, universal SMB | Windows desktop, proprietary engine | Fully offline; remote access bolted on later | Keyboard-first speed built a 30-year moat. UI is famously *stable* — validates your "no major frontend changes" instinct. Weak at POS counters. |
| **Marg ERP** | Pharma/FMCG retail & distribution | Windows desktop | Offline-first, cloud companion apps (owner app, ordering) | Vertical depth (batch/expiry, schemes) wins whole segments. Their mobile apps are satellites, not the core. |
| **Busy** | SMB accounting/billing | Windows desktop | Offline, cloud add-ons | Same shape as Tally; dealer channel is the distribution engine. |
| **GoFrugal** | Supermarkets, retail chains | Windows POS + store server, cloud HQ, mobile satellite apps | Local-first billing, cloud back office | **The closest analog to our plan.** Hybrid works at supermarket scale. Their weakness: complexity/onboarding — our opening. |
| **Vyapar** | Micro/small merchants | **Android-first** + Windows desktop | Local SQLite + cloud sync, freemium | Mobile-first wins the micro segment on price & simplicity — but doesn't serve a busy supermarket counter. Don't fight them on price early. |
| **QueueBuster** | Small-format retail, kiosks | **Android POS** | Cloud back office, offline-tolerant app | Android POS is viable for small format and line-busting — not for keyboard-speed checkout lanes. |
| **Zoho Books/Inventory** | SMB, online-comfortable | Pure cloud web/mobile | Browser caching at best | Cloud-only fails the queue test; they don't win physical high-throughput counters. |
| **Petpooja** | Restaurants | Local POS (Windows/Android) + cloud | Local server resilience | Even in restaurants, winners keep billing local. |
| **Ginesys** | Enterprise retail chains | Store server + cloud HO | Store-level autonomy | Our Phase-4 Enterprise shape already matches this. |

## Global reference points

| Player | Architecture | Takeaway |
|--------|--------------|----------|
| **Square** | iPad/Android, cloud-first, limited offline mode | Wins on payments + simplicity in small format; their offline is a fallback, not a foundation — regularly hurts them in bad-connectivity markets. |
| **Shopify POS** | Tablet, cloud-first | Retail-lite; not built for 40-items-a-minute lanes. |
| **Toast** | Android terminals, local store-level resilience + cloud | Proof Android + local sync works at scale — but they control the hardware end-to-end, which we won't. |
| **Lightspeed** | Cloud, iPad | Mid-market; same cloud-first ceiling. |

## The patterns (what everyone converges on)

1. **Nobody who wins high-throughput counters is cloud-only.** Every player serving
   supermarkets bills locally and syncs up. Our local-first hybrid is the market's
   convergent answer, not a contrarian bet.
2. **Device follows segment.** Keyboard throughput (supermarket lanes) → Windows desktop.
   Mobility and price (micro merchants, aisle billing, events) → Android. No major player
   serves both segments with one client — they share the *platform*, not the screen.
3. **Incumbent moats**: keyboard muscle memory, the CA/accountant ecosystem, and the
   dealer channel. **Challenger wedges**: price, UPI-native payments, onboarding speed,
   mobile. We hold incumbent-style moats (existing base, dealer path, domain depth) and
   can steal the challenger wedges (Purchase Inbox, WhatsApp, 15-minute onboarding).
4. **Stable frontend, evolving backend** is literally how Tally kept its base for
   decades — the counter UI is boring and eternal; innovation ships in the engine,
   compliance, and automation. This is your stated principle, confirmed by the market.

## Conclusion — D8 resolved

**v1: Windows desktop POS (Electron).** Your existing base runs Windows; the supermarket
segment demands keyboard speed, weighing scales, and ESC/POS — that's where desktop wins
and where your revenue is.

**Phase 3–4: Android companion app** — line-buster billing from the aisle during rush
hours, stock-take scanning, owner approvals — sharing the same billing-engine package and
sync protocol (which is why the engine is a pure TS package from day one).

**Full Android POS parity: only if/when we deliberately go down-market** to micro
merchants — a pricing and support decision, not a technical one, and not v1.

This keeps D2 (Electron) intact and keeps the Android door permanently open at the
architecture level.