We Built an Ordering System That Starts With the Word "Hi"

The first version we shipped took orders perfectly well and did not survive contact with a Friday night.

Not because it broke. Because it stopped too early. A customer could message the restaurant, get a link, browse a menu, add items and pay, and then the system had nothing more to say to them. The order appeared on a dashboard, the kitchen cooked it, somebody eventually carried it to a door. In between, the customer sat with their phone face up on the table wondering whether any of that was happening.

We had built the part everyone builds. Here is what we learned building the rest of it.

Decision one: the link expires at 23 hours

This looks like an arbitrary number and it is the most consequential line in the product.

WhatsApp opens a 24 hour customer service window when a customer messages a business first. Inside that window, the business can send free form messages: text, images, buttons, anything, with no pre approved template and no per template cost. When the window closes, only approved templates get through, each one submitted for review and billed.

So the question of how long an ordering link stays valid is not a security question. It is the question of whether the restaurant can speak to the customer at all for the rest of the order.

Set the link to 48 hours and a customer who orders on hour thirty is now outside the window. Their confirmation, their dispatch notice and their delivered notice all have to go through templates, which means pre written text, approval delays and a per message cost on a Rs 400 order.

Set it to 23 and every message in the entire lifecycle is a reply inside a conversation the customer opened. Free form, free of cost, and structurally consensual in a way no SMS blast has ever been.

The platform rule that looks like a restriction is actually the moat. Only businesses the customer chose to talk to get to talk back.

Decision two: the order type comes before the menu

We initially put delivery, takeaway and dine in as a choice at checkout, which is where most software puts it, because that is where the fulfilment decision logically belongs.

It was wrong for a reason that has nothing to do with logic. The order type changes the menu. It changes prices, it changes what is available, it changes packaging, and on dine in it changes whether an address field should exist at all. Asking at the end meant showing the customer a menu we might have to revise under them.

Asking first also had a second effect we did not anticipate. Restaurants that could run all three through one link started running all three. When each one needed its own setup, almost every operator configured delivery and left takeaway and dine in on the aggregators, which is a strange outcome given dine in is the highest margin thing they do.

Decision three: recommendations live on the item, not the cart

Every ecommerce instinct says put the upsell at checkout. Food does not behave like ecommerce.

The moment a customer is receptive to a raita is the moment they are looking at a biryani, not the moment they are looking at a total. By the checkout page they have mentally closed the order and anything else feels like an upcharge.

This is not a subtle effect. The aggregators have spent extraordinary amounts optimising exactly this surface, and a direct channel that ships a flat menu is voluntarily giving that revenue back while complaining about commission rates.

Decision four: dispatch is a decision, not a contract

We assumed restaurants would want a delivery integration. Singular.

What they actually wanted was to choose per order. A two kilometre drop with a bike free at the counter should go to their own rider, because it costs them almost nothing. Six kilometres in the rain at nine on a Friday should go to Porter or Rapido, because the alternative is losing their rider for forty minutes.

Every restaurant we spoke to was already doing this manually with phone calls. The software had simply never given them the switch.

The thing we got wrong

For most of the first year we thought we were solving discovery.

That is the pitch everyone in this category makes: escape the marketplace, get found on your own. It sounds right and it is almost entirely wrong for independent restaurants. They have local demand already. People in the neighbourhood know the place, the Instagram page has followers who live within four kilometres, and the QR code on the table is discovery.

What they were missing was the thirty five minutes between payment and delivery. The aggregators did not win on discovery. They won on status updates. They built the only system that talks to a customer after the money is taken, and every restaurant trying to compete with a confirmation email was competing with about fifteen percent of the actual product.

The broader point

For fifteen years the moat in consumer software was the install. Getting an icon onto a home screen was expensive, so whoever paid for it sat between the business and its customer and charged rent for access.

India has spent several years dismantling that trade without ever calling it a policy. UPI turned payments into a public rail instead of a wallet's moat. ONDC is attempting the same for discovery. WhatsApp, entirely by accident, did it for the interface itself. Five hundred million people already have a general purpose ordering surface installed, and nobody owns the right to charge for reaching them through it.

When the install stops being a moat, the moat moves to whatever is genuinely hard. In food that has always been the same thing: getting hot food to a door on time, and telling the person it is coming.

That is bad news for anyone whose real product is a directory. It is very good news for anyone who can run fulfilment.

I work on Menuthere, which gives restaurants a WhatsApp ordering line, a branded storefront and the admin and dispatch layer underneath it. If you are building in this space and disagree with any of the four decisions above, I would like to hear it.