|
|
# 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.
|