One table.
Every way to order.

A connected restaurant service platform.

The usual name for the new module is Table Management + Captain/Waiter Ordering. In India, “captain” commonly describes the staff member taking orders. “Table service” is the clearest customer-facing label. “KDS” means kitchen display system; “KOT” means kitchen order ticket.

Keep the existing order modes: DINE_IN, PICKUP, DELIVERY and ROOM_SERVICE. A waiter and a QR code are order sources within dine-in. They do not need competing order engines or a fifth fulfilment mode.

Sell the outcome: a venue can run a busy shift, build repeat business and present its own brand. Full accounting, inventory, payroll and every POS integration are separate product commitments.

Build on the newer work.

This brief uses your uploaded build log, master plan, continuity handoff and six images, plus the three experiment sites. It is a document and design review; the current application repository, deployed providers and merchant billing accounts were not audited here.

The visit is the connection.

A physical table exists all day. A table session represents one dining party’s visit. That session can contain several submitted rounds, from several authorized people, without mixing the next party’s orders into the same bill.

1. Seat the party.Create a visit for Table 5. Optionally record guest count and captain. A table may be occupied before anyone orders.
2. Take the first round.The captain opens Tables → Table 5 → Add items. They choose existing variants/add-ons, enter instructions and confirm “Send to kitchen.” No customer OTP is required for a staff-authorized order.
3. Accept a guest’s QR round.The guest sees “Table 5” clearly. The QR identifies the table; joining the current visit requires the configured authorization. The guest order uses the existing customer authentication policy until a separate guest-checkout decision is made.
4. Add another round.Send only the new items. Earlier tickets retain their content and history. Record the source, actor, time and round number.
5. Prepare and serve.Kitchen staff acknowledge the ticket. Item or station progress rolls up to the order. A captain separately confirms service; “ready” does not mean “served.”
6. Settle and reset.The cashier sees a consolidated bill with payment allocations and exceptions. Close the operational visit only under an explicit settlement policy; then mark the table for cleaning and ready for the next party.

Essential first version: table/area setup; list or grid; active visits; captain assignment; phone/tablet order entry; multiple rounds; prominent table labels; kitchen acknowledgement; served status; running bill; payment evidence; owner controls; history. A simple grid is sufficient before a drag-and-drop floor designer.

Next, after the basic visit is reliable: audited table transfers and joins; seat/course ordering; split by item or amount; partial cash/UPI/card collections; held/fire-later dishes; call-waiter and request-bill actions; reservations as a separate capability. Each needs its own permissions and accounting rules.

Staff access uses the existing staff login and tenant authorization. A captain can take orders and see assigned service; a chef can see preparation details; a cashier can record allowed collections; an owner/manager can approve sensitive corrections. Avoid shared owner passwords and exposing all customer data to every device.

A kitchen screen that supports a rush.

Priorities: newest additions must stand out; older unacknowledged work must remain visible; ready items alert the right captain; cancellations after submission create a visible correction, rather than silently deleting food in preparation. Recall and reprint need audit records.

Architecture recommendation: keep Next.js, MongoDB and the established tenant resolver. Extend the existing durable order-effects/retry mechanism where suitable. Persist the order and a durable event intent together using a proven atomic design; publish through a retryable worker; use authenticated tenant-scoped subscriptions. MongoDB remains authoritative, while live events notify screens to refresh or apply a versioned projection.

A managed publish/subscribe service is a sensible pilot candidate. Native WebSockets on Vercel are also now possible according to its June 2026 announcement; this does not remove the need for shared fan-out, reconnection, authorization and delivery recovery. Choose one transport after a small comparison, not an infrastructure rewrite. [8]

Offline scope: phase one can retain a draft and clearly show that the kitchen has not received it. A cloud-only PWA cannot honestly promise continued kitchen delivery during a complete internet outage. True local offline operation needs a separate local POS/gateway and synchronization design, including price/menu freshness, conflicts, numbering, printing and payment rules.

Printing: include a manual printable fallback first. Automatic KOT printing is a scoped integration with a tested device/connection list, delivery acknowledgements and duplicate-print controls. Hardware and unattended printing support should be confirmed before sale.

Give the restaurant its own character.

The 2UP marketing site sells software. A restaurant homepage sells food and a place to visit. They can share a reliable foundation while using different layouts, imagery, typography and calls to action.

Your CRM screenshot already has a usable workspace structure. Add Tables prominently under Operate, beside Live orders and Kitchen display. Give captains a focused entry screen after login. Your mobile checkout is visually consistent; prioritize mode/table context, reduce optional form clutter, and keep the payable amount and action clear when the keyboard opens.

Homepage modules: brand/header, hero, ordering modes, popular items, categories, current offers, story, gallery, opening hours, address/map link, contact and factual footer. Use real restaurant content. Empty galleries and invented reviews should never be required to fill a template.

Order-page options: list or image cards; approved density; category navigation; search; supported dietary filters; featured items; visible sold-out states; item customization; sticky cart; accurate open/closed state. QR entry should go directly to a table-aware menu rather than force the guest through a marketing homepage.

Store versioned theme settings per merchant. Provide preview, draft, publish and rollback. Preserve accessible contrast and required ordering information. Keep arbitrary scripts, unsafe HTML and changes to payment/security logic outside the theme editor. Scope caches by tenant/host, theme version and locale to prevent one restaurant’s branding or content appearing on another domain.

Make quality measurable.

Per-merchant SEO must apply to each restaurant’s public pages, rather than only the main 2UP website. Retest the tenant SEO work recorded in WP-12 before deciding what is missing.

• Crawlable content: serve meaningful restaurant and menu content in the initial/server-rendered HTML; do not require login, geolocation permission or a modal before a visitor can browse. Keep real-time cart and table context out of shared caches. [4]
• Identity: unique titles/descriptions, one clear page heading, Open Graph image, favicon, address, phone, opening hours and valid links. Use actual location information rather than repeated generic copy.
• Structured data: appropriate Restaurant/LocalBusiness JSON-LD, with matching visible facts, address, cuisine, hours and menu URL. Validate it. Schema markup does not guarantee rich results or rankings. [5]
• Canonical domain: choose one primary merchant domain. Redirect equivalent public subdomain URLs after the custom domain is live; generate canonicals and sitemaps from verified domain data. Table, campaign and session URLs must not become indexable duplicates. [6]
• Private pages: authenticate admin, cashier, kitchen, account and order tracking routes. Apply suitable noindex rules, remove private URLs from sitemaps and avoid treating robots.txt as access control.
• Local discovery: maintain the merchant’s Google Business Profile details and appropriate website/order links with their authorization. Publish useful real location pages. Measure search impressions, non-brand clicks and completed orders.
• Images and performance: responsive compressed variants, declared dimensions, sensible image loading and no unnecessary scripts. Test image-heavy themes, not only empty demo menus.

Adapt the layout to the job: phone ordering uses one clear column and a reachable cart; tablets can show menu and cart together; desktop can add persistent categories. Captains need fast search and large controls. KDS needs readable tickets at kitchen distance. Core tasks should avoid horizontal page scrolling; wide reports may use a clearly contained table or mobile summary.

Use 44–48px product touch targets, visible focus, clear labels and status text alongside color. Carry the build log’s deferred focus-return, hidden-title, KDS exit-target and post-fix browser checks into the next verification. “100% responsive” should mean a defined, tested support matrix and graceful behavior at intermediate widths—not a promise about every possible device.

Compete on the complete visit.

Suggested first market: owner-operated, single-outlet restaurants and cafés where you can observe staff during service and provide fast onboarding. Become dependable at one complete visit before taking on chain-wide menu management or custom integrations.

Measure the advantage through time to first order, kitchen acknowledgement, serving errors, direct-order conversion, support effort and renewals. Claiming to beat every competitor cannot substitute for those results.

Sell the term. Show the monthly equivalent.

The initial term uses the explicit price book in section 09. It supersedes the earlier three-paid-month offer and pay-10/pay-11 annual proposals. All amounts below are before applicable tax, additional promo codes and usage. Pro remains quote-only until an agreed premium scope is deliverable.

These are proposed product entitlements, including work not yet released. Verify table bills, station routing, split settlement, loyalty and integrations before advertising availability. Every paid plan includes the defined baseline design, security, technical SEO, recovery and export access.

India’s additional processing-fee proposal remains ₹2 pickup / ₹3 delivery, plus enabled metered services. Dine-in and room service have no per-order processing fee. UAE usage/provider tariffs require local validation. Quote platform subscriptions, optional projects, recurring services, credit funding and courier costs separately.

Commitment and renewal: 24 months is the checkout’s recommended starting selection; 48 months has the lowest initial monthly-equivalent rate. The initial software rate is fixed for the paid term. A subsequent 12-month renewal is illustrated at the current reference tariff, with a final quote and changes disclosed in advance. Automatic renewal starts off and needs an approved mandate.

A 14-day software evaluation may happen before purchase. It does not create a monthly subscription or silently charge a full-year contract. Standard onboarding may be waived for eligible founding pilots; custom design, travel, message volume and courier trips are separate.

More commitment. A better initial rate.

Annual-only purchase policy: every software purchase covers at least one year. Display “per month equivalent,” the term length, full subscription amount, tax, selected add-ons, credits, code discounts and renewal reference before confirmation. The following are proposed initial-term rates, not historical selling prices or guaranteed future tariffs.

India · initial monthly equivalent and full prepaid subscription

UAE · initial monthly equivalent and full prepaid subscription

Prices exclude additional promo codes, tax, usage, optional services and credit funding. Annual care/campaign add-ons cover their first 12 months even when software is purchased for longer. One-time design is charged once. Domain registration, physical hardware, ads and carrier fares are separate.

Renewal reference · the next 12 months

Reference amounts assume today’s tariff and exclude tax. They are not a future tariff guarantee or an active automatic-debit mandate. A final renewal quote is required before renewal. A long initial contract does not hide separate annual add-on renewals.

Multiple offers, with controlled combinations

Only one software-subscription code applies at a time. Eligible setup, design and credit-bonus groups can combine with it. Codes never add paid products automatically. Setup included in a custom project is not charged again; a setup-waiver code cannot create an extra discount against an already-free line.

Offer Studio can edit market/term rates, products, enabled codes, new codes, tax illustrations and credit minimums; import/export configuration; and restore defaults. Its edits are local to the current browser. The production billing server must own authentication, approved prices, first-purchase identity, quotas, campaign budgets, dates and atomic redemption.

Use real campaign dates and verified limits instead of invented countdowns or “places left” claims. Keep a bounded founding setup offer and explicit first-credit-grant eligibility. Additional subscription discounts have the caps above; usage and funded service value are not silently discounted.

Tax illustration: the checkout defaults to India 18% and UAE 5% for the stated registered-local-supplier taxable domestic scenario. Actual registration, supply, invoice and credit-funding treatment needs confirmation. Funded-credit tax is left under review by default, and the checkout labels its known total accordingly. [13] [15]

One balance. Clear charges.

Founder’s new direction: add prepaid service credits, a ₹1,000 minimum top-up, first-deposit offers, platform-managed promo codes and fixed fees on delivery/pickup orders. This revises the earlier subscription-only, zero-order-fee proposal. The subscription prices remain hypotheses; the new fees below are additional hypotheses.

Call the merchant screen Billing & Credits. “Global” means one merchant’s paid balance works across eligible 2UP services. It does not mean a diner can spend a universal wallet at unrelated restaurants. Each restaurant retains its own food payments and customer relationship.

Minimum deposit: apply ₹1,000 to each normal top-up rather than forcing every table-only venue to fund unused services. A merchant can enable billable services when ready. Exceptional bank/refund adjustments are finance operations, not a way to evade the top-up minimum.

Fund the account: authenticated owner selects ₹1,000/₹2,500/₹5,000 or a custom amount ≥₹1,000 → sees paid value, bonus eligibility, tax treatment and full payable → pays through 2UP’s own billing collection account → server verifies payment amount, currency and captured/confirmed status → one ledger credit is posted. A successful browser redirect alone must never fund the balance. Duplicate payment notifications must not create duplicate credits. [9]

The top-up flow belongs to 2UP’s platform billing, separate from the restaurant’s food-payment credentials, webhook routes and payment gates. A 2UP top-up payment is not merchant food GMV.

Tax and refunds: have the accountant classify the advance/voucher/service arrangement before configuring tax timing, invoices and credit notes. Do not hardcode that ₹1,000 cash always equals ₹1,000 usable credits regardless of tax treatment. The examples here use ₹1,000 funded service value and exclude tax. Propose no arbitrary expiry of paid value; bonus credits can expire under disclosed terms. Refund eligible unused paid value to the original payment method after resolving holds, usage, disputes and applicable terms; promotional value has no cash payout.

Use one billing account per tenant in the single-outlet launch. Authorized pooling across a merchant group comes only with the group/outlet model. Use separate INR, AED and QAR balances/rate cards in later markets; there is no automatic cross-currency conversion or globally transferable rupee balance.

A controlled first-top-up offer

Recommended test: fund ₹1,000 and receive ₹100 promotional credits, once per verified merchant business. Bonus credits last 60 days and initially offset 2UP’s delivery/pickup processing fees. Paid credits fund metered communications. This gives a real benefit without giving away an unbounded third-party messaging budget.

Platform admin controls code, campaign dates/timezone, minimum paid value, bonus percentage/fixed amount, maximum award, eligible country/plan/SKUs, per-business redemptions, total campaign budget, stacking rules and expiry. Reserve campaign budget during the top-up attempt; grant the bonus only after the eligible payment is confirmed. Freeze the accepted offer on that attempt and release abandoned reservations safely. Refunds/chargebacks need linked bonus reversals and review of already consumed value.

Keep platform top-up promotions separate from restaurant food coupons. Staff accounts, duplicate webhook deliveries and retrying the same payment must not produce additional “first deposits.” Consume eligible bonus credits by earliest expiry, then paid value; freeze the allocation on each hold so expiry and refunds remain traceable.

Example ending value: ₹1,000, before holds; only ₹950 is usable for communications under this bonus policy. This is a funding illustration, not a real transaction or provider rate quote.

A small fixed fee, clearly disclosed.

Test ₹2 per accepted pickup order and ₹3 per accepted delivery order, before applicable tax. Apply the same launch rates across Core/Growth to simplify the first offer. Future plan/volume rates can be versioned after measured economics. These are proposed 2UP prices—not competitor prices, provider charges or a statement of current implementation.

Charge the merchant’s service balance, not the diner by default. Any merchant decision to recover a fee from a diner needs a separate, clearly displayed checkout policy and local review. Publish “Subscription + fixed delivery/pickup processing fees + optional service usage.” Do not market this as “no per-order fees.”

1. Quote and reserve before taking the customer’s payment.Determine the mode and rate on the server; reserve eligible merchant credits atomically. Capture the rate-card version and a unique logical order/attempt reference. An abandoned checkout releases the hold after its state is resolved.
2. Debit once when the valid order is accepted.Require the necessary verified customer payment or permitted pay-at-counter/COD policy. Automatic acceptance uses the same rule. An added item, status update, device retry or extra courier attempt is not another order.
3. Reverse according to a visible policy.Proposed default: rejected/failed/abandoned orders release holds; a final cancellation before preparation reverses a captured 2UP order fee. After preparation begins, retain the fee unless a supported exception applies. Food refunds and carrier cancellation fees have separate rules.
4. Handle corrections with linked entries.Owner/finance-approved reversals reference the original debit and restore the original eligible buckets, respecting bonus expiry. Do not delete ledger history or automatically refund a courier cost the carrier has retained.

Low balance: warn at ₹200, escalate at ₹50, and allow the owner to set a larger threshold. Pause new marketing sends before optional campaigns consume critical capacity. An optional ₹100 operating reserve can protect storefront OTP and transactional usage; it is an earmark within the paid balance, not extra credit. Reserve required billable verification capacity before starting a new checkout.

When there is insufficient spendable value, stop a new billable checkout before customer payment starts, preserve the cart and alert the merchant. Continue tracking/fulfilling already accepted or paid orders and handling their funded work. A balance drop must not switch off their kitchen screen, erase history or interrupt a table visit. Avoid unlimited automatic overdrafts. Opt-in auto top-up can follow later with a supported mandate, monthly cap, retry limits and owner notices.

Third-party delivery management

2UP should orchestrate a partner, not operate its own fleet: serviceability → delivery quote → approved booking → rider/ETA details when supplied → pickup → delivery/failed/cancelled → reconciliation. Keep the courier quote and the ₹3 2UP processing fee distinct. A delivery order using the restaurant’s own rider can still incur the normal order fee; it has no external courier fare.

Start with one contracted provider in the pilot city. Shiprocket Quick publicly offers hyperlocal food delivery and API integration, making it a candidate to evaluate—not a confirmed 2UP partner. Coverage, restaurant suitability, API access, account ownership, cancellation rules and actual rates need confirmation. Standard parcel APIs must not be assumed to provide the same food-delivery workflow. [11]

Default money flow: merchant pays the courier through its own approved provider arrangement; 2UP displays the quoted/settled fare and manages the supported booking/status flow. If the contract/API does not support this arrangement, choose another supported arrangement before enabling booking. Do not silently route carrier settlements through the service balance.

Map external IDs to the tenant/order, verify provider notifications where supported, deduplicate events and recover missing updates by a supported status lookup. A booking timeout is “checking,” not permission to book another rider blindly. Show last-updated time and provider-supplied ETA/location; display honest status-only tracking when live coordinates are unavailable. Carrier “delivered” does not automatically prove cash collection or payment settlement.

Control the bill without rewriting history.

What your documents establish: plan/trial states, some entitlement enforcement, manual activation, billing-repair handling and audit surfaces are documented. They do not establish a working prepaid credit ledger, top-up payment lifecycle, metered charging engine or first-deposit promotions. Review current source in Kiro before reusing or adding modules; a Plan page alone is not a wallet.

Platform administration can provide the cross-merchant operational and billing overview requested by the founder. Use named roles: support can inspect masked billing facts; finance can propose/refund/adjust under policy; an authorized platform owner publishes tariffs and offers. Detailed merchant/customer access should be scoped, justified and audited. No raw provider secrets, unrestricted impersonation or shared admin password is necessary.

Every manual credit or debit requires a reason, amount, currency, actor, reference and timestamp. High-value refunds/adjustments should require a second authorized approval when the team supports it. The operator posts an adjustment entry rather than editing an account’s balance field. Reconcile payment-provider events, usage events and ledger postings daily; flag mismatches instead of silently “fixing” totals.

For a campaign, show audience size after consent/opt-out checks, billable segments/categories, rate version, estimated maximum and included usage. Reserve the authorized budget, capture attributable billable events and release unused holds. A timed-out provider request remains unresolved until checked; do not release its money and send again as if it never happened.

Where an approved bring-your-own-provider arrangement bills the merchant directly, do not also debit the same provider charge from 2UP credits. Charge only any separately published 2UP service fee and show the two responsibilities clearly.

Rate cards: version by country/currency, service/SKU, unit, plan, effective date, sell rate, provider cost basis and tax treatment. Preserve the accepted quote/version on every usage event. Notify merchants of prospective changes. Support a maximum quote or expiry so a provider rate change cannot silently exceed an authorized campaign budget. Track margin after actual provider cost, top-up collection fees, promotions, reversals and support.

Rollout: review existing billing code → ledger and top-ups → one-time order fees → one messaging provider with budgets → first-deposit promotions → one delivery partner → optional renewal/auto top-up. Pilot and reconcile each stage before widening access. This report specifies the design; it does not implement a production financial ledger.

Charge each cost where it belongs.

The amounts below are original pricing hypotheses for 2UP’s own services, before applicable tax. They are not verified vendor tariffs, market averages or approved offers.

Delivery launch: distinguish delivery order capture, management of a restaurant’s own rider, and third-party courier dispatch. These are three different capabilities. Begin with the workflow already documented in the product; add one locally useful courier integration after merchants request it and commercial access is confirmed.

Marketing launch: start with consent-aware customer records, simple segments, coupons and measurable links. Add opt-out handling, spending caps, sender onboarding and attribution before bulk campaigns. For managed marketing, compare incremental repeat sales with message cost, discounts and campaign labor; gross order value alone is not profit.

Design economics: quote estimated delivery hours × loaded hourly cost ÷ (1 − target project margin). Example assumption: 30 hours × ₹500 ÷ 0.50 = ₹30,000 at a 50% project gross-margin target. Measure revisions and QA time. Agree design asset rights, export/handover, recurring fees and cancellation milestones before starting.

Website-only projects may be supplied without restaurant operations, under a separate website/care scope. A customer buying custom design plus ordering pays the agreed one-time design project and the software subscription. Avoid duplicate platform-hosting or compulsory “maintenance” charges for the same service.

Profit comes from repeatable delivery.

Use paying outlets for revenue planning. One thousand registrations or pilot accounts are not one thousand subscriptions. Food sales, tax collected, courier charges and unconsumed service advances are not automatically 2UP revenue. The original calculator and three-cost illustration below cover subscriptions only; they exclude additional order/usage revenue, its associated costs and promotional redemptions.

Your existing cost report recommends a ₹1,74,750 monthly service allowance at 1,000 outlets and 30 orders/outlet/day, with separate contingency, taxes and people. Its login-route and infrastructure assumptions need revalidation. Table-service traffic can change that workload significantly. Do not reuse the same budget as a capacity guarantee.

Three subscribed devices per outlet would be 3,000 concurrent staff connections if all were online together. Add guest tracking, reconnects, presence, peak bursts and payload/egress separately. Subscriptions should be tenant/role scoped; broadcasting all customer information to every staff device is unnecessary and costly.

Staff-entered orders need not incur customer SMS OTP, which can lower verification cost. More rounds, station screens and retries can raise database and live-update cost. Measure both effects before changing providers or buying capacity.

Support is a scaling constraint: one support hour per outlet per month is 1,000 hours at 1,000 outlets—6.25 full-time equivalents at an illustrative 160 hours each, before internal overhead. Standard themes, training, a useful setup checklist and understandable error states directly improve margin.

Track realized ARPU after discounts, cloud/OTP/message cost, onboarding hours, support minutes, collection losses, churn and paid renewals. Use an 80% contribution/gross-margin ambition as a design target, with consistent accounting definitions. It is not a current result. Keep recurring software margin and one-time design margin visible separately.

Order-fee scenario: 1,000 active outlets × (10 pickup orders/day × ₹2 + 10 delivery orders/day × ₹3) × 30 days = ₹15 lakh of gross processing charges in that illustrative month, before promotions, reversals and tax. The updated ₹20.99 lakh initial-term subscription revenue equivalent plus that activity is ₹35.99 lakh of gross service value before those adjustments and all costs. This is not a sales or cash forecast; usage-dependent order fees are separate from subscription MRR. Do not add prepaid subscription receipts or top-up receipts a second time.

Track subscription MRR, earned order fees, metered service charges, unused paid advances, issued/used/expired bonuses, provider costs, paid-credit refunds, gateway fees and tax separately. Gross-versus-net presentation for resold provider services requires the accountant’s principal/agent assessment. Reconcile cash collection, earned revenue and outstanding credit obligations; high top-up cash must not hide operating losses.

Ship a complete shift first.

1. Gate 0 · Establish the actual release baseline.In Kiro, inspect the working tree, staged WP-12/WP-13 changes, current routes and deployed evidence. Complete the documented post-fix checks and provider journeys. Preserve the protected checkpoint and payment gates.
2. Gate 1 · Pilot connected table service.Add/extend table entities, visits, staff order entry, new rounds, live KDS updates and a basic consolidated bill. Start with one kitchen and explicit cashier permissions. Test a real busy shift in a few independent single-outlet venues.
3. Gate 2 · Release the website foundation.Ship three high-quality responsive themes, safe customization, tenant SEO checks and publication/rollback. Keep QR entry fast. Use the same menu and pricing logic across themes.
4. Gate 3 · Validate the paid offer.Use one coherent price sheet with roughly 10 paid pilot venues, showing subscription, flat order fees and optional usage. Pilot/reconcile the credit ledger, top-ups, unique order-fee postings and one messaging route before promotions and wider use. Capture actual order volume, support effort, renewal willingness and reasons for losing a sale.
5. Gate 4 · Add validated advanced operations.Station routing, safe transfers, partial/split settlement, managed print integrations and measured growth features. Deliver in small packages with feature gates and clear release criteria.
6. Gate 5 · Expand in stages.At 10 → 50 → 200 → 1,000 active outlets, review live order latency, restore evidence, peak load, onboarding capacity and contribution margin. Do not let a calendar target replace the operational gates.

Country readiness is a product and commercial checklist, not a currency toggle. Do not assume the Indian payment provider, invoice template, courier or message account automatically applies abroad. No current country-specific tax or legal determination is made in this brief.

Multi-tenant operation remains the platform architecture. Multi-outlet merchant groups are a different feature, explicitly deferred in the approved master-plan decision. Sell independent outlet subscriptions with clear expectations until shared group controls are truly implemented and verified.

Extend the order engine carefully.

Resolve these before building the bill.

1. Existing billing/POS: will pilot restaurants keep Petpooja or another POS and use 2UP alongside it, or should 2UP produce the primary restaurant bill? This determines integration, reconciliation and fiscal-invoice scope.
2. Offline requirement: is a clear pending draft acceptable during an outage, or must orders continue reaching the kitchen over the local network? The second option needs a separate local architecture.
3. Launch cohort: which city, how many pilot venues, and roughly how many tables/captains per venue? That gives a useful first device and peak-load test.

What this plan stands on.

External pages checked 26 October 2026. Vendor statements describe advertised capabilities, not independently tested performance. Product design, package limits, prices for 2UP services, targets and financial scenarios in this brief are recommendations or labeled assumptions.

1. [1] Petpooja: Captain ordering app, Kitchen display system and pricing page. No exact local Petpooja subscription price is asserted.
2. [2] uEngage Edge web ordering and La Pino’z website. The exact La Pino’z contract and design charges are unknown.
3. [3] Owner.com official pricing, including the guest support-fee statement in its FAQ. USD figures are not an Indian quote.
4. [4] Google Search Central: JavaScript SEO basics.
5. [5] Google Search Central: LocalBusiness structured data.
6. [6] Google Search Central: canonical URLs.
7. [7] web.dev: Core Web Vitals thresholds.
8. [8] Vercel: WebSocket support announcement, 22 June 2026.
9. [9] Razorpay: webhook validation, duplicate events and event order. Provider events require validation; wallet postings also require application-level idempotency.
10. [10] RBI: Master Directions on Prepaid Payment Instruments, displayed as updated 30 September 2026; section 2.1 distinguishes own-service closed instruments from third-party payment/settlement. This brief does not classify 2UP as exempt or licensed.
11. [11] Shiprocket Quick official product page: food delivery and API capability. No partnership, pilot-city coverage, account arrangement or final fare has been verified.
12. [12] WhatsApp Business Platform official pricing. Exact active account rates, discounts and BSP fees are not quoted; use verified current contract/rate-card data.
13. [13] UAE Federal Tax Authority, checked 27 October 2026; its VAT calculator shows a 5% VAT calculation. The checkout uses a local taxable-supply illustration; actual tax treatment remains to be established.
14. [14] Hostinger: renewal periods and advance payments. Its documentation explains monthly comparisons with full-term upfront collection. The user-supplied screenshots informed the term selector; 2UP rates are original proposals.
15. [15] GST Council: IT/ITES FAQ, question 5 states the standard IT-services GST rate used for the 18% illustration. This does not determine all 2UP supplies, exports or prepaid-credit tax treatment.
16. Founder experiments: one.2up.in, its pricing page, 5.2up.in, and 10.2up.in. Retrieved directly after the research fetcher could not open these hosts. Used as planning artifacts, not proof of current revenue, costs or released features.
17. Uploaded primary project material: 2UP-MASTER-COMPANY-PLAN.md, BUILD_PROGRESS(1).md and 2UP_PROJECT_HANDOFF_2026-10-21.md. Newest relevant build-log entries take precedence over historical implementation inventories; source inspection is still required.
18. Uploaded visual material: merchant CRM desktop, customer checkout mobile, platform home desktop, and three screenshots including the competitor navigation, file selection and La Pino’z page. No project code or external account was modified.