Calm
At dinner rush, the interface must reduce anxiety. One primary action. Clear status. No surprise modal. No visual decoration competing with the next task.
01Priority zero
The executive decision
The product vision is ambitious. The engineering answer should be calm: protect what is already excellent, replace what cannot scale, and refuse expensive complexity before customers prove it is needed.
Recommended path
Do not rewrite the database today. Your native MongoDB architecture, embedded order snapshots, state machines, unique-index idempotency and 242-file test surface make a database rewrite the highest-risk, lowest-return change available.
Use Percona Server for MongoDB or MongoDB Community on Indian-region infrastructure, Cloudflare R2 for media, Caddy for domains, and the existing Next.js application. Start lean; add a three-node replica set before the first serious SLA.
57%Current weighted production readiness
6 weeksFocused path to a sellable foundation
83%Traffic removed by fixing polling
0Database rewrite required now
Why this can become a category leader
The hardest foundations are already unusually good: Host-controlled tenant identity, audience-bound sessions, separate fulfilment and money state machines, encrypted merchant payment credentials, exact-byte webhook verification, and fail-closed index verification. The missing work is mostly durability, enforcement and interface discipline—not invention.
02Know the truth
Readiness, without theatre
A working screen is not a finished system. This score rewards mechanisms that keep the product correct tomorrow—not only code that happens to work today.
How this score is calculated
Each subsystem is scored from static review and weighted by business impact. A high score requires working code, automated protection, operational evidence, and a recovery path. Tenant queries are currently scoped correctly, for example, but score lower because nothing structurally prevents the next query from omitting tenant_id.
The score is not a vanity metric. It is a sequencing tool: launch blockers first, then risks that worsen with every merchant, then features.
03Ordered work
Twenty priorities. One order.
Do not parallelize everything. Each item below either removes a launch blocker, prevents an irreversible failure, or lowers the cost of every task after it.
What is intentionally not in the first ten
Native mobile apps, AI recommendations, marketplace settlement, deep loyalty automation, advanced integrations, and multi-country tax. They may become valuable. None matters before media persists, logins are throttled, isolation is enforced, backups restore, and a merchant can complete a full day without support.
04North star
World-class is a feeling, then a system
“World’s #1” cannot be implemented as more features. It is earned when every role feels the product was designed specifically for the moment they are in.
Immediate
Every tap acknowledges within 100 ms, even when the network has not finished. Use optimistic UI only where reversal is safe; use explicit progress where money is involved.
Forgiving
Cart survives refresh. Draft survives signal loss. A failed payment recovers. Destructive actions explain their consequence and offer undo where technically possible.
Familiar
Customers should order without learning the product. Merchants should recognize the language of their operation—not software language.
Fast
Performance is part of the interface. A beautiful menu that appears after four seconds is not beautiful. Set budgets and fail the build when they regress.
Trusted
Prices never change silently. Payment state is unambiguous. Customer data is not shown to roles that do not need it. Every important action has a trace.
The product sentence
“Your restaurant, under your brand, without commission.” Every feature and every screen should strengthen that sentence. If a feature does not make direct ordering easier, operations calmer, customer relationships stronger, or ownership clearer, it waits.
05Phone first
Design from 360 pixels outward
Phone-first is not “desktop, stacked.” It means information architecture, interaction, performance and physical ergonomics begin with one hand and an unreliable network.
Non-negotiable interface rules
- 44×44 px minimum tap targets; 48 px for the primary action.
- 16 px minimum input text so iOS never zooms the page unexpectedly.
- One-column reading flow under 700 px. No horizontal table required for a core task.
- Bottom-reachable primary actions for cart, accept, ready, dispatch and deliver.
- No hover-only meaning. Every status, help and menu works with touch and keyboard.
- Respect safe areas for notches and browser controls with
env(safe-area-inset-*).
Information rules
- Show the next decision, not every available option.
- Use progressive disclosure for modifiers, filters and secondary analytics.
- Keep amounts, status and timing visually stable—never jump while data loads.
- Replace dense tables with cards that preserve label/value relationships.
- Use plain operational language: “Start cooking,” not “Transition to PREPARING.”
- Put error recovery beside the error, not in a disappearing toast alone.
A practical responsive system
360Baseline phone width. Everything must work here.
600Large phone / small tablet: allow two-column utility grids.
900Tablet and compact desktop: persistent navigation becomes optional.
1200Operations screens can use dense boards—without shrinking text.
Performance budgets for the phone experience
- Customer storefront LCP: ≤2.5 s at p75 on mid-tier Android / Fast 4G.
- INP: ≤200 ms at p75; CLS: ≤0.1.
- Initial customer-route JavaScript: ≤170 KB gzip; admin route: ≤250 KB before role-specific lazy chunks.
- Hero image ≤90 KB AVIF/WebP; menu thumbnails ≤35 KB at rendered size; never ship originals.
- API p95: reads ≤300 ms warm, writes ≤600 ms, excluding third-party payment latency.
- Skeleton appears ≤150 ms; no blank white screen. Network failure reaches a useful recovery state ≤3 s.
Accessibility is part of premium design
Target WCAG 2.2 AA. Visible focus, correct landmarks, one H1, labelled controls, status updates announced through aria-live, colour never the only status signal, motion reduced when requested, and kitchen alerts available visually and audibly. Test every release with keyboard, VoiceOver/TalkBack, 200% text, and sunlight-level contrast.
06Every person
One platform, six different jobs
A customer, owner and kitchen operator do not need variations of one dashboard. They need purpose-built journeys sharing one truth underneath.
07Architecture choice
Do not leave MongoDB. Leave Atlas.
Those are different decisions. Atlas is a hosting product. MongoDB is the data model, query API, index contract and test surface your entire application already uses.
Best fit now: Percona Server for MongoDB in India
Percona describes its server as a fully compatible drop-in replacement for MongoDB Community: the same drivers and tooling, with enterprise-grade auditing, encryption and other features available without Atlas. That gives this codebase the lowest migration risk and the greatest control over cost.
Pilot: one Indian-region VM plus encrypted off-host backups. Production: separate application and database hosts. Serious scale: three data-bearing voting replica members, majority writes, independent failure domains, tested restores.
No application rewrite
The existing mongodb v6.6 driver, aggregation pipelines, transactions, TTL indexes, unique-key idempotency and scripts remain usable. Migration is data movement and operations—not product surgery.
Predictable economics
You buy fixed RAM, CPU and NVMe. No per-operation pricing, no surprise tier jump, and no idle poll charged as a database transaction beyond the hardware already running.
The responsibility is real
You own patching, replica health, backups, restores, monitoring, disk growth and failover. Saving money by skipping those is not saving money—it is borrowing from the incident.
What production self-hosting actually requires
Three data-bearing voting members
MongoDB's own production checklist recommends at least three, journaling, and w: "majority". A standalone server is a pilot configuration, not production high availability.
Independent failure domains
Different hosts, preferably different zones. Three containers on one VM provide process redundancy and zero machine redundancy.
Private network only
No public 27017. Firewall allow only app nodes and operator VPN; TLS between members; dedicated least-privilege application user.
Two backup mechanisms
Nightly logical backup plus volume snapshot / PITR-capable continuous backup, both encrypted and copied off-provider. Restore monthly into a scratch environment.
Capacity alarms
Disk 70/80/90%, replication lag, oplog window, connections, page faults, slow queries, CPU steal and backup age. Alerts must reach a human.
Written failover runbook
Who responds, how to elect/recover, how the app behaves, RPO/RTO, and how to communicate. Test it before you market an SLA.
Do not make this mistake
Do not place the Vercel app in Mumbai and a budget database in Germany. Your API performs several sequential database round trips; 120 ms of network latency multiplied six times becomes a slow screen before any query runs. Keep app and database in the same region and private network. If the database moves to an Indian VM, move the Next.js server there too—or benchmark the hybrid path before committing.
When a PostgreSQL rewrite becomes rational
Not because Postgres is “better.” It becomes rational if one of three things becomes true: reporting and cross-entity joins dominate product work; strict relational invariants are repeatedly reimplemented in application code; or your team gains enough capacity to run a dual-write, verification and cutover program without pausing the product.
Your current workload—embedded order snapshots, flexible menu variants/add-ons, append-heavy events, host-scoped tenancy—is a legitimate MongoDB fit. A rewrite is roughly 6–10 focused engineering weeks plus a long tail of race and migration testing. Do not spend that before merchants prove the schema is the constraint.
Official references: Percona MongoDB compatibility · MongoDB self-managed production checklist · Replica-set deployment.
0823 options ranked
The database and hosting field
Ranked for this exact repository—not generic popularity. Scores weight code compatibility, Indian latency, production reliability, operating burden, price predictability and exit cost.
How to use this list
Ranks 1–8 preserve the current MongoDB API and are the only options I would consider now. Ranks 9–17 are managed or compatible services requiring careful integration tests. Ranks 18–23 are strategic rewrites or convenience platforms—not launch choices.
Why “Mongo-compatible” does not mean drop-in
DocumentDB, Cosmos DB, Firestore Mongo compatibility and FerretDB speak enough of the Mongo wire protocol to use familiar drivers. They are different database engines with different operator coverage, index behaviour, transaction semantics, aggregation support and billing models. This application uses compound unique indexes for idempotency, TTL indexes, findOneAndUpdate atomicity, aggregation pipelines, raw webhook events and migration scripts. Every one must run through the full integration suite against the candidate before production.
A successful connection string is not migration evidence.
09Scale deliberately
One architecture, four maturity stages
Big-company quality does not require big-company waste. Reliability should grow ahead of merchant risk—not years ahead of revenue.
One India-region machine
Next.js standalone + Percona/Mongo + Caddy, Cloudflare in front, R2 for media, encrypted backup copied off-provider. No SLA. This is explicitly a pilot configuration.
Separate the data, prepare recovery
App and database on separate private-network hosts. Continuous Mongo backup or frequent oplog-aware backup, daily restore verification, warm replacement host scripted but not running. Founding merchants know this is beta.
High availability becomes real
Two stateless app nodes behind a load balancer; three data-bearing replica members across failure domains; majority writes; rolling deploys; Sentry, metrics, on-call alerts; monthly failure drill.
Remove hot paths, not just add hardware
SSE or efficient conditional polling, tenant config cache, queues for media and reconciliation, analytics rollups, read secondary for reports, autoscaled app nodes, quarterly disaster-recovery exercise.
Architecture rule
The application remains stateless. Tenant identity remains Host-controlled. Media lives outside the app filesystem. Every mutable document carries tenant_id. Background work is idempotent. Every queue can redeliver. Every deployment can roll back without undoing a schema migration.
10Transparent model
A calculator you can audit
No binary sliders, no hidden free tier, no fake single number. Choose a scenario, edit real inputs, and see an expected monthly range with the assumptions exposed.
Company planning model
Start with a preset, then replace every input with your expected reality.
Paying or actively using the platform this month.
Average across all active merchants.
Optimized = hidden-tab pause, average 20s idle, cursor/ETag.
The recommendation is selected by default.
Exclude GST; use blended monthly/annual ARPU.
Transactional storage compounds; menu storage does not.
Advanced workload and Vercel assumptions
Used only for Vercel provisioned-memory billing.
I/O wait is excluded from active CPU billing.
—Expected infrastructure / month
—Subscription revenue / month
—Infrastructure as % of revenue
—API requests / month
—Peak database operations / second
—Database + backup footprint
—Processed media footprint
—Infrastructure / tenant
—Margin after infrastructure
See the exact model and pricing anchors
11Scale reality
From first merchant to 5,000
The table compares the current request pattern with the optimized target, using 60 orders/day, two admin devices, 13 trading hours and ₹1,499 ARPU.
| Tenants | Current requests | Optimized requests | Recommended topology | Expected cost | % revenue |
|---|
Read ranges, not rupees
Infrastructure quotes differ by region, tax, snapshots, support and committed use. This table deliberately uses ranges. Exact-looking ₹18,074 figures create confidence without accuracy; “₹14k–₹21k based on the stated hardware and workload” is the honest planning answer.
12Speed + cost
Performance work in the right order
Faster and cheaper are the same project here. The dominant waste is not rendering—it is asking the server, repeatedly, whether nothing changed.
The first 2½ days
Pause every poll when document.visibilityState !== "visible". Move the order board from fixed 5-second polling to a cursor/ETag response with adaptive backoff: 5 seconds immediately after activity, 20 seconds after idle, snap back on any change. Cache Host→tenant resolution for 60 seconds.
This removes roughly 80–85% of API requests in the target model without making a screen feel slower. In fact, user-perceived responsiveness improves because active moments still use 5 seconds while abandoned tabs stop competing for resources.
Then fix query shape
Bound the dashboard history
The returning-customer aggregation currently groups the tenant’s entire revenue history every 15 seconds. Add a date window now; replace it with daily rollups next.
Add five missing indexes
orders{tenant_id,updated_at}, customers{tenant_id,created_at}, products{tenant_id,deleted_at,sort_order}, notifications{tenant_id,audience,read}, and global orders{created_at} for platform metrics.
Stop JavaScript aggregation
Reports pull full order documents and reduce them in JS. Push matching, grouping, projection, sorting and pagination into Mongo. Return only the shape the screen renders.
Make customer pagination real
The API currently fetches at most 1,000 customers, joins and filters in memory, then calls slice(). Past 1,000 the total is false. Paginate and segment in the database.
Roll up platform metrics
The super-admin overview polls every 20 seconds and scans across all tenants. Maintain hourly/daily metric documents from order events and read those instead.
Expire low-value events
audit_logs and analytics_events grow forever. Keep legally/security-relevant audit records longer; TTL raw product analytics after aggregation.
Bundle and rendering
AdminApp.jsx statically imports all ten views. A delivery rider opening orders downloads Recharts and QR code generation. Use next/dynamic per route/role, prefetch the most likely next view, and measure the result. For customer pages, serve transformed images with explicit dimensions so they never shift layout.
Performance test matrix for every release
- 360×800 mid-tier Android, Slow/Fast 4G, cold and warm.
- iPhone Safari with 200% text, keyboard open, and “Reduce Motion.”
- Kitchen tablet running 8 hours with 100+ order transitions—watch memory and timer leaks.
- Two admin tabs, one hidden, one visible—verify the hidden tab produces zero polls.
- 50/100/500 tenant synthetic load with current and optimized update modes.
- Atlas/Percona
explain("executionStats")for every list, board and report query. - Budget gate in CI: JS bytes, LCP lab threshold and endpoint p95 regression.
13Earn trust
Security, payments, and recovery
A category leader is not the product that never fails. It is the product that fails predictably, contains the damage, recovers automatically, and can explain what happened.
Before the first paying merchant
- Rate-limit merchant and platform login plus password-change endpoints using the existing atomic OTP limiter.
- Remove wildcard CORS; fail closed when
CORS_ORIGINSis absent in production. - Reject loopback values in
platformHosts()under production and test arbitrary Host forwarding at ingress. - Require and backup
PAYMENT_CREDENTIAL_ENCRYPTION_KEY; losing it makes captured payments unreconcilable. - Restrict kitchen users from full CRM PII.
- Make tenant scoping mechanical with
tenantDb(ctx)and a CI prohibition on raw merchant collection access.
Before enabling live payments
- Run the payment index migration preview, investigate every duplicate, snapshot, then apply before payment code deploys.
- Fix and test cancellation during in-flight capture: today it can leave money captured, order cancelled, and no refund row.
- Build reconciliation for uncertain provider creation, failed events, browser close and exhausted webhook retries.
- Implement provider refund execution; current
REFUND_PENDING → REFUNDEDis bookkeeping only. - Test real Mongo unique-index races—not only the in-memory fake.
- Keep
platform_managedrejected. Merchant-direct funds preserve 0% commission and avoid settlement regulation.
The reliability ladder
99.5%Founding beta: ≤3h 39m downtime/month, no SLA.
99.9%Production target: ≤43m 49s/month.
99.95%Growth: ≤21m 55s/month, tested failover.
99.99%Enterprise only when architecture and team can prove it.
Backups are not a checkbox
Define RPO and RTO by stage. Encrypt backups with a key stored separately. Keep one copy outside the infrastructure provider. Alert on backup age. Restore monthly into a new environment and verify tenant counts, recent orders, payment states and media references. After any index or payment migration, restore again.
“The provider has snapshots” is not a restore test.
India compliance foundation
You process customer names, phone numbers, addresses and order history on behalf of merchants. Build per-tenant export and deletion; retention schedules; consent and privacy notices; breach-response workflow; processor/controller clauses in merchant terms; and least-privilege staff access. Confirm DPDP and GST obligations with Indian counsel and a chartered accountant.
14Profitable by design
Price the commission you replace
Do not sell this as another billing tool. Sell ownership: the merchant’s brand, domain, customer relationship and money—with no order commission.
Starter
One outlet, three staff, 2UP subdomain, QR ordering, pay at counter, core CRM. The low-friction entry.
Growth · anchor
Custom domain, unlimited staff, KDS, coupons, analytics, merchant-direct Razorpay, priority support. Most merchants should choose this.
Per additional outlet
Consolidated reporting, outlet-specific menu and staff. Pricing grows with merchant capacity, never order count.
Packaging rules
Annual = two months free. No three-year commitment until pricing is validated with 50 paying merchants. Unlimited orders on every paid plan—never punish successful customers. Custom domain is the natural upgrade trigger. Trial expiry suspends writes, never access to history or export.
Unit-economics guardrails
<10%Infrastructure / recurring revenue after roughly 100 merchants.
>80%Gross margin after hosting, payment and direct support.
<3 moCustomer acquisition payback before paid scaling.
<2%Monthly involuntary churn after payment retries mature.
Why subscription automation waits
With zero clients, UPI plus manual activation is not primitive—it is learning. Building webhooks and dunning before anyone pays answers no product question. Automate when 15–25 active merchants make manual renewal operationally painful. Until then, use the time for onboarding, speed and merchant interviews.
1512-week execution
Build the foundation before the spectacle
Six two-week outcomes. The roadmap is sequenced so each phase reduces the risk or cost of the next.
CI, observability, and the immediate security edge
GitHub Actions for install/build/unit/all integrations/secret scan; Sentry; staging isolation; password rate limits; strict CORS; production Host guard; encryption-key guard.
R2 and the complete media lifecycle
Presigned direct upload, raster validation and EXIF stripping, media ownership collection, CDN variants, quotas, management-role enforcement, orphan cleanup, dual-read migration if files exist.
Polling, cache, indexes, and query shape
Hidden-tab pause; adaptive ETag/cursor polling; Host→tenant cache; five missing indexes; TTL events; dashboard bound; real customer pagination; platform rollups.
Tenant database wrapper and money correctness
Introduce tenantDb(); migrate merchant handlers; eliminate raw access allow-list; repair cancel-versus-capture; add real-Mongo race tests; verify unique index invariants.
Onboarding, entitlement, and responsive redesign
Merchant setup wizard, menu CSV import with preview/undo, plan limits at write paths, trial lifecycle, legal pages, tenant export/delete, route-level code splitting, all six role journeys polished on 360px.
Payments, recovery, and controlled launch
Payment migration and restore drill; reconciliation worker; provider refunds; Razorpay Test Mode matrix; 10× load test; two founding merchants; run one real dinner rush with observation before public sales.
Definition of 100%
Not every imaginable feature. It means a merchant can self-onboard, import a menu, receive and fulfil orders, collect money, understand customers, recover from failure, and leave with their data—without the founder watching the system.
16Launch gate
What “ready” means
Tap each item as it is proven. Progress is stored only in this browser. A screenshot or HTTP 200 is not evidence.
0 of 0 proven0%
—Evidence
Sources and model limits
Provider terms move. The document tells you where each anchor came from and where the model deliberately uses a range.
Official references
Percona Server for MongoDB · MongoDB production checklist · AWS Lightsail pricing · DigitalOcean Droplets · Hetzner Singapore · OVH India · OCI Ampere.
ScaleGrid MongoDB · IBM Cloud MongoDB · Cosmos DB MongoDB vCore · Amazon DocumentDB · Firestore MongoDB compatibility · FerretDB.
Calculator limits
The calculator is a capacity and unit-economics planner, not a cloud invoice. Self-host prices use published 4/8/16 GB VM anchors and explicit HA topologies. Managed Mongo costs use public tier anchors and a range because provider sizing is not reducible to operations/second alone.
Vercel mode includes its current Mumbai rates—$0.140/active CPU-hour, $0.0116/GB-hour provisioned memory and $0.60/million invocations—with editable CPU, wall-time and memory assumptions. It uses max($20 seat, metered usage) to reflect the Pro usage credit. Taxes, FX movement and human operations are outside the model.
Research updated 24 September 2026. Content obtained from external sources was paraphrased for licensing compliance. Confirm prices, regions, quotas and licenses before purchasing. Legal and tax content is general information, not professional advice.
17Suggestions · intentionally last
Five founder suggestions
Everything optional is here, at the end, so it cannot distract from the work that makes the core trustworthy.
Own one category before “the world”
Become the best commission-free ordering platform for independent Indian restaurants, cafés and boutique hotels first. Category leadership is a narrower promise kept exceptionally well, then expanded.
Make onboarding the product
The real competitor is not another SaaS. It is “too difficult to switch.” Photograph or import a menu, verify a number, connect a domain, print QR cards. Target first order in under 20 minutes.
Observe ten dinner rushes
Analytics will tell you what was clicked. Standing beside a counter tells you why. Watch customer, owner, kitchen and delivery roles under pressure before building another major feature.
Turn reliability into marketing
Publish uptime, incident history, data ownership and export policy. “Your orders, your customers, your money, your data” is stronger when the operational proof is public.
Earn the mobile app later
Ship a truly installable PWA first. Wrap with Capacitor only when native printer, camera, push or background behaviour creates measurable value. One web codebase should remain the product.
Keep the ambition. Narrow the next move.
A world-class company is built by repeatedly making the next customer experience calmer, faster and more trustworthy—while keeping enough margin to do it again tomorrow.