My own SaaS product, two months in.

The incumbent is hated and unbeatable at the same time.

Indian pharmacies and distributors run on desktop ERPs that look twenty years old, live on one machine, hide hundreds of raw config toggles, and come with dealer-set pricing and thin support. Users complain constantly — and still won't leave.

The reason is simple: those tools are fast. A counter biller works keyboard-only and never looks at the mouse. Most modern web ERPs lose exactly here, by pushing clicks and modals into the billing loop. So Pharos has one non-negotiable: billing speed is the product, benchmarked in keystrokes per bill rather than clicks.

Keep the speed. Fix everything else.

Five people use the same data and want opposite things — the biller wants raw speed, the owner wants a glance, the accountant wants an audit trail. Rather than compromise into one grey screen, Pharos gives each role a different home.

• Speed is the feature. Keyboard-first entry, instant response, optimistic UI. No modal in the billing loop.
• Progressive disclosure. The power is all there; first run shows about a tenth of it. A trade-preset wizard replaces the toggle wall.
• Reports become worklists. Ageing, expiry and reorder stop being reports and become "who to call today" and "what to clear this week".
• Web-native, multi-user. Multiple users and roles from day one, responsive on a phone, and offline-tolerant so a flaky line never stops a sale.

One sale document, three lifecycle stages.

An invoice, an estimate and a delivery challan share an item grid and almost nothing else. Instead of three screens, the document toggle reconfigures the one screen — panels appear and disappear, totals get renamed, validation changes, and stock and GST posting behave differently.

Tender adds its own branching: cash, UPI, credit or a split allocation that blocks save until the remainder hits zero — with two-level credit limits, where a soft breach warns and can be overridden and a hard breach stops the bill outright.

What's in the MVP, and what deliberately isn't.

Phase 1 — UI built, services next

• Keyboard-first sale bill, tender modes, document-type states and conversions
• Item master with batch and expiry, customer master, ageing worklist
• Purchase entry and an import wizard for supplier PDF/Excel/CSV
• GST invoicing, e-invoice, e-way bill
• Sales hub with status tabs and a needs-action filter
• Owner dashboard with KPIs and alerts
• Multi-user roles, PWA offline cache, trade-preset onboarding

Deferred on purpose

• Deep accounting and balance-sheet depth
• Schemes engine and loyalty
• Field-sales app, multi-firm, payroll
• Manufacturing and BOM
• The long tail of configuration

Product decisions are engineering decisions.

Doing all of it alone means I can't hand a hard question sideways. Choosing that converted estimates stay visible as "Invoiced" rather than vanishing is a UX call, a schema call and an audit-trail call at the same time — and I have to make it, then build against it.

The front end is live and real — every state above exists as a working screen, keyboard shortcuts included — and I designed each one before writing it. The services underneath are the current build, and they're the half of this I've spent three years doing professionally.

That's the part I'd bring to a team: I can hold the whole thing in my head — market, screen, API, deploy — and still ship the boring middle of it.