A demo is built to show you the best thirty minutes any piece of software will ever have. One clean sample order, one smooth bill, one polished dashboard with pre-loaded sample data that makes the reporting look richer than it'll be on your actual first week. That's not a criticism of any particular vendor — it's just what a demo is, by design, everywhere. The salesperson's job is to show the product working. Your job, as the person about to sign a contract and rewire how your restaurant takes orders, is to find out what happens outside that thirty minutes.
The gap between "the demo looked great" and "this actually works for my restaurant" is where most bad restaurant-software decisions happen. Not because vendors lie — most don't — but because a demo, left to run on its own script, will never volunteer the answer to a question you didn't ask. This piece is ten of those questions, the ones that separate a system that performs well on stage from one that performs well on a Friday night with fifteen tables full.
Most of these questions take under a minute to ask and cost the vendor nothing to answer honestly if the product is genuinely solid. That asymmetry is worth sitting with for a second: a good vendor loses nothing by being asked hard questions, and a struggling one loses the sale either way — either now, cleanly, or three months in, expensively, after you've already trained your staff on a system that doesn't do what you assumed it did.
1. "If an order comes in through the QR flow, does it appear in billing automatically — or does someone retype it?"
This is the single most revealing question you can ask, and it should be the first one out of your mouth. A lot of "complete" restaurant platforms are actually two products — an ordering layer and a billing layer — stitched together at the sales page, not at the database level. If a customer's QR order requires a staff member to manually re-key it into the POS before it can be billed, you haven't removed a manual step, you've just moved it later in the process, and you're now paying for software that promised to eliminate exactly that.
Ask the salesperson to walk through this specific handoff, step by step, rather than accepting "yes, it's all connected" as an answer. If they can't show you the moment an order becomes a bill without anyone typing it in twice, assume it doesn't happen automatically.
Here's a concrete way to pressure-test this in the room: ask them to place a QR order on a demo phone, then immediately turn the laptop or POS screen toward you and ask "show me that order right now, exactly as it looks on the billing side." If there's a pause, a "let me just refresh," or a moment where someone has to manually create a new bill and copy the items over, you've just watched the real answer happen in front of you — regardless of what was said moments earlier.
2. "What happens to my data if I want to leave or switch systems?"
Nobody signs a contract planning to leave. Ask this question anyway, because the answer tells you more about how the vendor thinks about you as a customer than almost anything else they'll say in the demo.
A vendor confident in their product will answer this plainly: here's how you export your menu, your sales history, your customer data, and here's roughly how long that takes. A vendor who gets vague, changes the subject, or implies you won't need to worry about that is telling you, indirectly, that switching away is designed to be painful — which is a red flag regardless of how good the product looks today, because your restaurant's needs in two years may not match what you're being sold right now.
Think of this less as planning to leave and more as checking whether you're being treated as a customer with genuine choice or as a captive one. A vendor who's built their retention on making the product worth staying for will answer this question comfortably, because they're not relying on switching friction to keep you. A vendor who's built retention on switching friction alone tends to reveal that in exactly this moment.
3. "What does the pricing actually include, and what costs extra?"
Demo pricing conversations tend to quote the headline number and leave the asterisks for the contract. Ask directly: does this price include support, or is that a separate tier? Does it include hardware, or is a POS terminal, printer, or tablet a separate line item? Is there a setup or onboarding fee on top of the subscription? Does the price change if you add a second outlet, or is it a flat per-outlet cost from day one?
None of these are unreasonable things for a vendor to charge for. What's unreasonable is finding out about them after you've signed. Get the full cost stack — subscription, hardware, setup, support tier, per-outlet scaling — in writing before you commit, not as a follow-up email after the demo has already built momentum toward a yes.
A useful trick here: ask for the pricing breakdown as a line-item list, the way you'd want an invoice formatted, rather than a single bundled number. Vendors who price transparently will produce this without friction. Vendors who've built their margin into vague bundling tend to resist itemizing it, because the itemized version is exactly what makes comparison shopping against a competitor possible.
4. "How long does onboarding actually take, from signing to going live?"
Every vendor will tell you onboarding is fast. Push past that and ask for specifics: how many days, on average, for a restaurant your size and complexity? What does the restaurant need to provide on their end — a full menu with photos and pricing, staff availability for training sessions, WiFi setup? What's the single biggest reason onboarding runs long when it does?
That last question is the useful one. A vendor who's honestly answered it many times before will have a real answer — usually something like "restaurants that don't have their menu digitized yet" or "outlets that need new WiFi infrastructure." A vendor who says "it's never a problem" either hasn't onboarded enough restaurants to know, or isn't being straight with you.
5. "What happens when the internet goes down mid-service?"
This is not a hypothetical for most Indian restaurants, particularly outside metro cores. Ask specifically: does the ordering system stop working entirely, or is there some offline fallback? Does an in-progress order get lost, or does it sync once connectivity returns? Can the kitchen still see and complete orders that were placed just before the connection dropped?
A vendor with a real answer to this will describe a specific fallback behavior. A vendor without one will say something reassuring but vague, like "that's very rare with us" — which isn't actually an answer to what happens when it occurs, rare or not.
This matters more for dine-in restaurants than owners often expect, because an internet drop during service doesn't just pause new orders — it can strand orders that were already placed, mid-preparation, with no record on the kitchen side if the system relies entirely on a live connection to display them. Ask specifically whether the kitchen display caches already-received orders locally, or whether it goes blank the moment connectivity drops. That distinction is the difference between a five-minute hiccup and a genuinely lost order during your busiest hour.
6. "Do I need to buy new hardware, or does this work with what I already have?"
Some platforms are hardware-agnostic — customers use their own phones to scan and order, and you use your existing printer or tablet for the kitchen side. Others require you to buy specific proprietary hardware, sometimes at a markup, sometimes locked to that vendor so you can't shop around for a cheaper terminal.
Ask this directly, and ask what happens if that hardware fails — is a replacement covered, or is that another out-of-pocket cost and a support ticket that takes days to resolve. A hardware dependency you didn't know about going in can turn a reasonable monthly subscription into a much larger first-month bill.
It's also worth asking whether the hardware, if any is required, is genuinely necessary for the software to function, or whether it's being sold alongside the software as a bundled upsell you could technically skip. Some vendors are upfront that a specific printer or tablet is optional but recommended; others present it as mandatory when it isn't, simply because hardware margins are better than software margins. A direct question — "would this work without buying that from you specifically" — usually surfaces the difference quickly.
7. "Can I see this handle ten orders in five minutes, not just one clean demo order?"
Every demo shows you one order, placed calmly, with nobody else touching the system at the same time. That tells you almost nothing about how it behaves during your actual Friday dinner rush, when multiple tables are ordering, modifying, and cancelling within minutes of each other.
Ask the salesperson to simulate volume — several orders in quick succession, an item modified after being added, one order cancelled entirely. Watch what happens to the kitchen display, watch whether the interface starts lagging or the order sequence gets confusing. This is where thin or bolted-on ordering modules usually show their limits first, and it's a limit you will never see in a single, unhurried demo order.
If the vendor pushes back on this request or seems thrown by it, treat that reaction itself as data. A platform genuinely built to handle real restaurant volume should be able to demonstrate that volume on request — it's not an unusual ask, it's the single most realistic thing you could ask to see.
8. "What's the support model when something breaks at 9 PM on a Saturday?"
Software fails at the worst possible time — that's not cynicism, it's just when restaurants are busiest and systems are under the most load. Ask specifically: is support available on evenings and weekends, or only during business hours? Is it a phone call, a chat, a ticket system with a promised response time? What's the actual average response time, not the best-case one quoted in marketing material?
If the answer is "you'll have a dedicated account manager" but that account manager works Monday to Friday, nine to six, you don't have weekend support — you have a slower version of business-hours support with an extra title attached. Get specific about after-hours coverage before you need it, not during an outage.
9. "Is this the same system across all my outlets, or a different product stitched in?"
If you have, or plan to have, more than one outlet, this question matters more than almost anything else on this list. Some vendors offer a genuinely unified multi-outlet dashboard — one login, consolidated reporting, consistent menu management across locations. Others sell you a single-outlet product and bolt on multi-outlet functionality later as a workaround, which often means separate logins, inconsistent reporting formats, and menu changes that have to be made outlet by outlet instead of once.
Ask to see the actual multi-outlet dashboard, not a description of it. If they can show you real consolidated reporting across two or more locations live in the demo, that's a strong signal it was built in from the start rather than added on.
This one is easy to skip if you currently run a single outlet and multi-outlet growth feels distant — but it's worth asking anyway if expansion is even a vague possibility in your plans. Switching platforms later specifically because your current one can't scale past one location is a disruptive, expensive move to make mid-growth, and it's far cheaper to ask this question now than to relearn it the hard way once you've already opened outlet number two.
10. "What's in the contract that I'd only find out about later?"
This is a deliberately blunt question, and it's meant to be. Ask about the lock-in period, the notice period required to cancel, whether there's an auto-renewal clause, what the penalty is for early termination, and whether pricing is locked for the contract term or can be revised. Ask whether there are any exclusivity clauses — some vendors require you not to run a competing platform alongside theirs, which matters if you ever want to test something new without fully switching.
A vendor confident in their contract terms will walk you through this without hesitation, because there's nothing to hide. A vendor who gets uncomfortable or says "your account manager will cover all that during onboarding" is deferring a conversation that should happen before you sign, not after.
What a Good Vendor's Answers Sound Like
There's a pattern worth noticing across all ten questions above: a vendor with genuinely good answers gives you specifics — numbers, named processes, a live walkthrough — without you having to push for them. A vendor without good answers reaches for reassurance instead of specifics: "don't worry about that," "that's rarely an issue," "we'll sort that out during onboarding." Reassurance is not information. If you're getting a lot of the former and very little of the latter, that's worth weighing as heavily as anything you saw on the actual screen during the demo.
Red Flags at a Glance
A quick reference for the reaction patterns worth noticing during any demo, regardless of which of the ten questions triggered them:
If more than two or three of your answers land in the left column, that's worth treating as a real signal, not a coincidence of one awkward demo.
Turning This Into an Actual Demo Request
Rather than asking these ten questions as a rapid-fire list at the end of a scripted demo, it's worth sending a version of this list to the vendor beforehand and asking them to build the demo around it. A vendor who's happy to structure the demo this way — showing you a simulated rush, walking through the contract terms, demonstrating the multi-outlet dashboard live — is signaling they're comfortable being evaluated properly. A vendor who insists on sticking to their standard script and treats these questions as an inconvenience at the end is telling you something too.
It's also worth asking to speak to an existing customer, ideally one running a restaurant similar in size and format to yours. A reference call rarely happens spontaneously in a demo, but almost every vendor worth working with can arrange one if you ask directly, and an honest fifteen-minute conversation with another owner tends to surface exactly the kind of specifics a sales demo is built to smooth over.
One more practical tip: take notes during the demo, specifically noting which of the ten questions got a specific answer and which got a reassuring one. It's easy to walk out of an hour-long demo with a warm overall impression and no clear memory of which individual answers actually held up. A simple checklist, filled in as you go, turns a vague gut feeling into something you can actually compare across two or three vendors side by side — which is usually a more useful comparison than remembering which demo simply felt the smoothest.
Where AhaarScan Stands on These
We'd rather you ask us all ten of these directly than take our word for any of it, but here's the short version. Orders placed through AhaarScan's QR flow reach the kitchen and the bill without manual re-entry. Menu and order data exports are straightforward if you ever decide to leave — we'd rather earn a renewal than lock one in. Pricing is commission-free and laid out without hidden hardware markups, since the flow runs on the customer's own phone. Onboarding for a single outlet typically takes days, not weeks, and the biggest variable is how quickly a restaurant can hand over a complete menu. We're happy to run a rush simulation in any demo, because that's exactly the moment worth seeing before you commit, not after.
The Short Version
A demo is optimized to show you the best version of a product's easiest moment. These ten questions exist to pull the conversation toward its hardest moments instead — the busy Saturday, the dropped connection, the day you might want to leave, the fine print in the contract. Ask them before you sign, not after your first bad Friday night, because that's exactly when you'll wish you had.