About
About DataRestro
DataRestro is built by Data Doodles Tech Private Limited in Baluwatar, Kathmandu. We make restaurant software where the till, kitchen, stock and reports share the same records.
Why one set of records matters
Walk into most restaurants and count the logins. A till. A kitchen screen from the till vendor. A back-office tool for stock and recipes. A website built by someone else. An ordering page, a reservation book, a loyalty app, a delivery tablet for each platform and, in Nepal, separate certified billing software for the tax invoice.
Each one keeps its own copy of the menu. When the kitchen runs out of buff momo, someone has to tell six systems. When the day ends, someone reconciles three versions of the sales.
DataRestro starts from the other end. The menu, the stock ledger and the order records are kept once, and the POS, the guest’s phone and the profit and loss all read from them.
The usual stack
one restaurant · many logins
- 01POS terminal + processing contractown menu, sales
- 02Kitchen display, per screenown menu
- 03Inventory & recipe costingown menu
- 04Website builderown menu
- 05Online orderingown menu
- 06Reservations / waitlistown guests
- 07Loyalty & marketingown guests
- 08Delivery middlewareown menu
- 09Scheduling & time clockown staff
- 10Accounting packageown sales
- 11Certified tax billing (Nepal)own sales
DataRestro · one record of each
Some of these DataRestro replaces today; some are on the roadmap. /features lists which.
How we work
We say what works and what does not.
Every feature on this site is marked available, partial or planned, and the partial ones say what is missing. If we have not built it, we do not sell it. If a tax authority has not certified us, we do not imply it.
No payment processor lock-in.
DataRestro records payments; it does not take a cut of them. Keep your bank, your terminal and your rates. When we integrate a provider, it will be one you chose, not one you were contracted into.
The till keeps working offline.
The till keeps taking orders when the connection drops, and replays them once, never twice. The kitchen display and payments still need the network today; a local-network fallback is next, and we say so.
Your guest list stays yours.
Your guest list, your menu and your website stay on your record, not rented back to you through a marketplace. Guest records can be corrected or deleted, and dormant ones anonymised, instead of being kept forever.
The server calculates every total.
A guest’s phone never sends a price. Every total is computed on the server, in decimal arithmetic, from the menu you set. Payment records are idempotent: a double tap records one payment, not two.
Security that does not stop service.
Security controls that lock out a whole floor because one cashier fumbled a password are outages, not security. We design for the busiest hour of the week, not the demo.
Why Nepal first
Why we started in Nepal
Nepal asks a lot of restaurant software: VAT-inclusive menu prices by law, a fiscal year that starts in Shrawan, wallet and QR payments alongside cash, and connections that do not always hold. Building for that first also made currency, timezone and tax settings per restaurant, which is what restaurants elsewhere need too.