The problem
Who suffers today when a group orders food together?
When friends, flatmates or office colleagues order together, one person does all the work outside the app. They collect everyone's choices on WhatsApp, rebuild the cart by hand, pay the whole bill, and then spend a day or two chasing people for their share on UPI. Choices get lost, late additions arrive after the order is placed, and the host often never gets all the money back.
Why it suits Ownly's Chennai launch. Every group order brings up to eleven new people into the app through one share link. That is a cheaper way into a new city than winning customers one at a time, and Chennai's office corridors (OMR, Velachery) and flatmate and hostel areas (T. Nagar, Adyar, Anna Nagar, Nungambakkam, Mylapore) already order in groups.
Goal: adoption first, repeat group orders second. North star: completed group orders per week.
Evidence status: the pain comes from my own experience and observation. It hasn't been measured yet, so I wrote the research plan before claiming anything about how common it is.
Product concept and one-pager
If a leadership team had five minutes, what should they decide?
Recommendation: proceed with validation, not a full build. The concept note and one-pager put the idea in front of a decision-maker: one shared order for up to 12 people, each paying their own share, as an invite-led way into Chennai.
They are deliberately honest about what is not yet known, and name three issues to settle before any real launch:
- Payments: collecting up to 12 separate payments, reconciling them to one order and settling the restaurant has to be confirmed with a licensed payment provider.
- Pricing: the prototype charges packaging per dish, while Ownly's public promise is no packaging fee. That needs Ownly's call.
- Market size: the Chennai numbers are scenario estimates, not observed demand.
Every claim is labelled as a documented fact, my own observation, an assumption or a recommendation.
User research plan
How do I learn what people actually do today, without leading them?
- 12 interviews: 6 hosts and 6 members, 25 to 35 minutes each, across office lunches, shared flats and hostels.
- A 7 to 9 minute survey with separate branches for hosts and members.
- Neutral questions about the last real order, never "would you use…". Every risky question has a rewrite in a bias audit.
- Concept reactions are kept separate from behaviour, and sample answers are labelled hypothetical.
Status: ready to run. No findings are claimed until the interviews are done.
Personas and stories
Who is this for, and what does a good day look like for them?
Arjun, the office lunch organiser on OMR. He collects twelve orders on WhatsApp, pays ₹2,800 up front and sends reminders the next morning. With Ownly Together he shares one link, everyone adds and pays their own share, and next week he taps "Order again with this group".
Priya, a flatmate in Velachery. She doesn't know whether the amount next to her name includes someone else's food or the delivery charge. With Ownly Together she picks her own food, sees exactly what she owes and pays it herself.
The personas are assumptions to test in the interviews, not research findings.
Customer journey
Where does the experience break, from first hearing about it to coming back?
| Priority fix | Pain it removes | Measured by |
|---|---|---|
| WhatsApp link straight into the group | "Another app?" at onboarding | Invite-to-signup conversion |
| Live shared cart with individual totals | "Any hidden charges?" | Cart-join rate |
| Each person pays their own share | The host fronting the whole bill | Group orders completed per week |
| "Order again with this group" | Inviting everyone again | Repeat group orders per week |
Market sizing
Is the opportunity in Chennai big enough to matter?
| Level | People | Annual GMV |
|---|---|---|
| TAM · group-order users in Chennai metro | 6.05 lakh | ₹648.65 Cr |
| SAM · in the launch areas | 1.51 lakh | ₹162.16 Cr |
| SOM · year one, 7% adoption | 10,584 | ₹11.35 Cr |
| Conservative case, 3% adoption | 4,536 | ₹2.65 Cr |
Illustrative planning estimates built from stated assumptions (group of 4, 0.75 orders a week, ₹1,100 basket). GMV is not Ownly's revenue.
Competitors
What already exists, and where is the gap?
Swiggy, Zomato and EatSure already offer shared group carts, so a shared cart alone isn't a reason to switch. Desk research couldn't confirm member-by-member payment at checkout on any of them, and EatSure's published flow has the host finalise and pay.
Where Ownly Together competes: each person pays their own share, the host chooses how the bill is split, cash handed to the host is tracked until it reaches the restaurant, and a saved group can reorder in one tap.
Desk research, not a hands-on audit. Features vary by city and rollout.
Product rules (PRD)
What exactly are we building, and what are we deliberately not building?
Not in this version: fee discounts or price comparisons, multiple restaurants in one order, rider names or tracking of real riders, real payments.
Design
How do I get from a PRD to screens a stranger can use?
I designed in Google Stitch from the PRD with eight prompts. The first version came back in Stitch's yellow, set in Hyderabad, with invented fee claims, rider names and a 6-person cap. I wrote four rounds of correction prompts and then started again in a new project from a proper Ownly pink design system, with the rules and a "do not include" list in the very first prompt. That produced 26 screens, 13 for mobile and 13 for desktop.
Build
Can it actually work, on a real database, for real people?
Back end on Supabase. Eleven tables with row-level security on every one, 25 database functions, eight SQL scripts and an audit log written only by triggers. Shares, charges and the split are all worked out in the database, never in the browser, so every phone sees the same numbers.
Data. 15 real Chennai restaurants and 150 dishes researched with ChatGPT, every dish with a free-licence photo.
Front end. React and Vite, deployed on Vercel. A cloud coding session built the first version from a written build plan with a test, audit and rebuild loop. I then tested it signed in and drove every fine-tuning round.
Privacy. Members see the delivery area, never the exact address; the map pin is the middle of the area. A mobile number is required but never shown to the group.
Testing, and what testing changed
What did real use reveal that the plan missed?
| Three-device test | Pays | How |
|---|---|---|
| Host (Chrome) | ₹446.41 | UPI |
| Member (phone) | ₹496.42 | Cash to host |
| Member (second browser) | ₹267.42 | Card |
| Whole bill | ₹1,210.25 | Exact to the paisa |
I worked out every share by hand before the host placed the order. The database matched each one exactly.
12-week roadmap
How does this get from prototype to a controlled launch?
- Weeks 1–2: discovery, research, architecture, payment-provider feasibility.
- Weeks 3–4: alpha with the shared cart working end to end.
- Weeks 5–6: real UPI split payment and settlement.
- Weeks 7–8: beta with selected Chennai office and flatmate groups.
- Weeks 9–10: user acceptance testing; week 11 is buffer.
- Week 12: controlled public launch.
Stop rule: real-money split payment doesn't ship until collection, settlement, refunds and approvals are verified.
Chennai go-to-market
How does it reach the first groups?
Start where groups already order together: OMR and Velachery office teams, then flatmates and hostels in T. Nagar, Adyar, Anna Nagar, Nungambakkam and Mylapore. Every host is the acquisition channel, because their share link brings the rest of the group in.
Tools I used: