# Laayo > Laayo is a food and grocery delivery app based in Birtamod, Jhapa, Nepal. Customers order from local restaurants, grocery shops and everyday stores in Birtamod and Damak, and Laayo's own riders deliver with live tracking. The same company runs Laayo Plus (a membership), Qora (QR payment software for businesses) and Laayo Biz (a point of sale for restaurants). This file is for AI assistants and search engines. Everything here is published by Laayo Services Pvt. Ltd. and safe to quote. ## Key facts - Company: Laayo Services Pvt. Ltd. - Head office: New Kanchanjunga Tole, Birtamod, Jhapa, Koshi Province, Nepal - Delivers in: Birtamod, Damak (Jhapa, Nepal). Kathmandu is planned next; not live yet. - Services: restaurant food delivery, grocery and everyday items. No pharmacy or parcel delivery. - Payments: Cash on delivery, E-Payment by QR, Laayo wallet - Products: Laayo app, Laayo Plus, Qora (https://qora.laayo.com.np), Laayo Biz (https://biz.laayo.com.np) - Founder: Sakshyam Baral (https://laayo.sakshyambaral.com.np/) - Support: in-app chat, https://support.laayo.com.np, phone 9707055875, email support@laayo.com.np - Apps: https://apps.apple.com/np/app/laayo-delivery-made-easy/id6757504406 and https://play.google.com/store/apps/details?id=com.laayo.userapplication - Social: https://www.linkedin.com/company/laayo/, https://www.instagram.com/laayonp/, https://www.facebook.com/profile.php?id=61578512708538 ## Official websites - [Laayo](https://laayo.com.np): Main website and app downloads - [Order on the web](https://new.laayo.com.np): Browse restaurants and shops on the web - [Laayo Blog](https://blog.laayo.com.np): Engineering, product, guides and company news - [Help Center](https://support.laayo.com.np): Customer support and help articles - [Qora](https://qora.laayo.com.np): QR payment software for businesses - [Laayo Biz](https://biz.laayo.com.np): Point of sale for restaurants ## Key pages on this blog - [About Laayo](https://blog.laayo.com.np/about) - [Frequently asked questions](https://blog.laayo.com.np/faq) - [Investors](https://blog.laayo.com.np/investors) - [Laayo's tech stack](https://blog.laayo.com.np/tech-stack) ## Frequently asked questions ### About Laayo **What is Laayo?** Laayo is a food and grocery delivery app based in Birtamod, Jhapa, Nepal. Customers order from local restaurants, grocery shops and everyday stores in Birtamod and Damak, and Laayo's own riders deliver with live tracking. The same company runs Laayo Plus (a membership), Qora (QR payment software for businesses) and Laayo Biz (a point of sale for restaurants). **Which company runs Laayo?** Laayo is run by Laayo Services Pvt. Ltd., a company based in New Kanchanjunga Tole, Birtamod, Jhapa, Nepal. **Where is Laayo based?** Laayo is based in New Kanchanjunga Tole, Birtamod, in Jhapa district, Koshi Province, Nepal. **Who founded Laayo?** Laayo was founded by Sakshyam Baral. More about the founder is on https://laayo.sakshyambaral.com.np/. **What products does Laayo run?** Four: the Laayo delivery app for food and groceries, Laayo Plus (a membership for regular customers), Qora (QR payment software for businesses, at qora.laayo.com.np) and Laayo Biz (a point of sale for restaurants, at biz.laayo.com.np). **What are Laayo's official websites?** Laayo: https://laayo.com.np. Order on the web: https://new.laayo.com.np. Laayo Blog: https://blog.laayo.com.np. Help Center: https://support.laayo.com.np. Qora: https://qora.laayo.com.np. Laayo Biz: https://biz.laayo.com.np. ### Ordering and delivery **Where does Laayo deliver?** Laayo delivers in Birtamod and Damak in Jhapa, Nepal. Kathmandu is the next city we are preparing for, and we will announce it when it is ready. **Does Laayo deliver in Kathmandu?** Not yet. Laayo is live in Birtamod and Damak. Kathmandu is planned next. **What can I order on Laayo?** Food from local restaurants and groceries and everyday items from local shops. Laayo does not offer pharmacy or parcel delivery. **Who delivers Laayo orders?** Laayo's own riders. One support team looks after the whole order, from the restaurant to your door. **How do I order?** Download the Laayo app from the App Store or Google Play, set your delivery location, pick a restaurant or shop, add items and place the order. You can also browse restaurants on the web at new.laayo.com.np. **Can I track my order?** Yes. The order screen shows each step and the rider on a live map once the order is picked up. **Can I order for someone else?** Yes. You can deliver to another address, send a Laayo gift card, or use Send a Treat where it is available in your app. ### Payments **How can I pay on Laayo?** With cash on delivery, e-payment by qr or the laayo wallet. E-Payment works by scanning a QR code with your bank or wallet app. **Is paying by QR on Laayo safe?** Yes. You pay inside your own bank or wallet app by scanning a QR code, so Laayo never sees or stores your card or bank login. **What is the Laayo wallet?** A balance inside the app that you can top up, receive refunds and gift cards into, and use to pay for orders. **What is Laayo Plus?** A monthly membership for regular customers with delivery benefits and priority support. The current terms are shown on the Plus page in the app. ### Help and support **How do I contact Laayo support?** Chat with support inside the Laayo app, visit the Help Center at support.laayo.com.np, call 9707055875 or email support@laayo.com.np. **What if something is wrong with my order?** Open the order in the app and report the problem from there. Support sees the order details straight away, and refunds are tracked on the same screen. **How do refunds work?** Report the problem from the order in the app. Support reviews it, and the order screen shows what was decided and the status of any refund. ### Restaurants, shops and riders **How can my restaurant join Laayo?** Apply from the Laayo partner app or contact the Laayo team. Our team reviews every application and helps you get your menu live. See /joining-laayo-as-a-restaurant-partner. **How do I become a Laayo rider?** Sign up in the Laayo rider app or contact the team. Our team reviews every application, and the app has a training area to practise before real orders. See /becoming-a-laayo-rider. **What is Qora?** Qora is QR payment software for Nepali businesses at qora.laayo.com.np. Merchants are paid directly into their own account; Qora never holds customer money. **What is Laayo Biz?** Laayo Biz is a point of sale system for restaurants at biz.laayo.com.np, covering billing, tables, staff and kitchen tickets, connected to the orders a restaurant receives on Laayo. ### Investors and press **How can I invest in or partner with Laayo?** Use the contact form on https://blog.laayo.com.np/investors. Someone from the leadership team replies personally. **Where can I get the Laayo logo?** The wordmark files are on https://blog.laayo.com.np/investors under Brand assets. --- # Hey Siri, reorder from Laayo > The next iPhone update adds Laayo to Siri and the Shortcuts app. You can reorder a favourite meal, check where your order is and jump straight to a restaurant by voice. Payment stays in the app, on purpose. - Source: https://blog.laayo.com.np/order-with-siri - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 22, 2026 - Topics: iOS, Siri, Swift, Voice Some of the most common things people do in Laayo are also the most repetitive. Order the same thing from the same place on a weeknight. Check where the rider is. Open a favourite restaurant. Each of these is a few taps, but they are taps you make with greasy hands, a child on your lap, or your phone propped up in the kitchen. With the next iPhone update, Laayo works with Siri and the Shortcuts app. This post explains what you can do, what we deliberately left out, and how we built it so that saying something to Siri behaves exactly like tapping the same thing in the app. ## What you can ask for The first version covers these actions: - **Reorder** a past order. Siri reads back which order it is about to repeat and asks you to confirm. - **Track** your current order. Siri answers right there, with the same status line you see at the top of the tracking screen. - **Order from a restaurant**, which opens that restaurant's menu. - **Search** Laayo for a dish or a restaurant. - **Open your cart.** - **Open your Laayo Wallet.** These show up in the Shortcuts app as Laayo actions too, so you can build your own routine. For example, a "Dinner" shortcut that opens your usual place, or a home screen button that tells you where your order is without opening anything. ![Siri hands the request to the same code the app already uses](https://blog.laayo.com.np/media/seed/siri-intents.svg) ## Why payment stays in the app The obvious next step would be "Hey Siri, order my usual and pay". We decided not to do that, at least for now. Paying for food involves choices you should see: the address, the delivery fee right now, whether a dish is out of stock, which payment method, a tip for the rider. E-Payment also needs you to scan or confirm a QR in another app. A voice conversation is a poor place to check all of that, and a wrong order is worse than a slow one. So for a reorder, Siri does the part that voice is good at. It finds the order you mean, reads it back and asks you to confirm. Then the app opens with your cart already filled, and you place the order with the normal checkout. You still save most of the taps, and nothing is charged without you looking at the bill. ## Building it on what already works iOS lets an app describe its actions through a system framework called App Intents. Each action is a small piece of Swift that declares what it needs (an order, a restaurant, a search phrase), how Siri should phrase the question, and what to do when it runs. The important design rule was: **Siri should never have its own version of a feature.** If voice and touch take different code paths, sooner or later they drift. Siri reorders something the app would not, or reports a status the tracking screen does not show. So every intent is a thin layer over code the app already runs: - **Reorder** calls the same reorder routine as the "Reorder" button on your order history. It fills the cart the same way the button does, and if part of the old order can no longer be repeated, you get exactly the same handling as when you tap the button. - **Track** reads the same tracking data and produces its sentence with the same function the tracking screen uses for its headline. Siri and the screen always say the same thing. - **Restaurant, search, cart and wallet** use the same deep links as our notifications, so they land on exactly the screens you already know. That also made the feature cheap to test. The interesting logic was already covered. What we tested for Siri was the hand-off: does the right intent run, does it find the right order, and does the app open in the right place when it is already running in the background. ## Things that are not there yet - **Android.** Google is retiring the older way for apps to plug into Assistant, and the new way is still settling. We would rather wait than build on something that is going away. - **Nepali.** Siri does not support Nepali, so the phrases are in English. Restaurant and dish names work as you would type them in search. - **Placing an order by voice alone.** As explained above, this is a deliberate choice. If we ever revisit it, it will most likely start with cash on delivery, where there is no payment screen to skip. ## What's next Once this is in people's hands, we will watch which actions are actually used. If "where is my order" turns out to be the favourite, it is a strong case for a Live Activity on the lock screen, so the answer is there before you ask. --- # Laayo's tech stack, part five: seeing what happens > The dashboards, metrics and crash reports we use to know how Laayo is doing right now, and what is planned next for the backend. - Source: https://blog.laayo.com.np/tech-stack-part-five-observability - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 22, 2026 - Topics: Observability, Prometheus, Grafana, Crash reporting Every earlier part of this series ends with some version of "and then we measured it". Shadow mode in part two only works because we can see how often Go and Laravel agree. The realtime work in part three only counts if events really arrive in under a second. A smoother native app in part four is only smoother if it does not crash more. For a long time, our answer to "is Laayo healthy right now?" was a mix of server logs, the admin panel and messages from riders and partners. That works when you are small. It stops working when you change the backend every day and need to know within minutes whether a change made things better or worse. This last part covers how we watch the system today, and the backend work that is planned next. ![What we watch and where it goes: metrics from Go services, servers, MariaDB, both Redis roles and PHP-FPM are scraped by Prometheus and shown in Grafana, while crash reports from the apps, Laravel and Go go to a self-hosted GlitchTip that emails on new crashes.](https://blog.laayo.com.np/media/seed/tech-stack-observability.svg) ## Metrics: Prometheus and Grafana We run **Prometheus** to collect metrics and **Grafana** to show them. Both are self-hosted, run in containers next to the rest of the stack and are not reachable from the public internet. Prometheus keeps enough history to compare this Friday's dinner rush with the last few. Prometheus pulls metrics from a set of exporters, each a small program that turns one system's internal numbers into metrics: - **Server.** CPU, load, memory, disk and network. - **MariaDB.** Queries per second, connections and slow queries. Its exporter logs in with its own limited account, separate from the app. - **Redis, twice.** One exporter for the live Redis and one for the cache Redis from part one, so we can see memory and evictions for each role separately. - **PHP-FPM.** How many Laravel workers are busy and how many requests are waiting for one. This is the most honest early warning we have: when waiting requests climb, customers feel it a few seconds later. ## Metrics from our own Go services The Go services from parts two and three expose their own metrics. We wrote the metrics output by hand instead of pulling in a library. The format is simple text, and keeping the services free of extra dependencies was worth a few dozen lines. The API service counts every request with three labels: the **route**, the **status code**, and **served_by**, meaning whether Go answered, Go served a saved copy or Laravel handled it. Next to the counters is a latency histogram per route, which gives us **tail latency by route**: how long the slowest requests take, not just the typical ones. Averages hide the slow requests that customers remember, so the tail is what we set targets on. The realtime service reports open connections, channels, subscribers and live trackers, so we can see dinner time arrive as a wave of sockets. ## One dashboard first We resisted building many dashboards. There is one main dashboard, **Laayo Overview**, and it tries to answer "is something wrong right now?" in a single screen: | Panel | Why it is there | | --- | --- | | CPU, load, memory, disk | the machine itself | | Laravel workers busy and waiting | the first sign of slowness | | Requests per second, Go versus Laravel | how much traffic the fast path carries | | Tail latency by route | which endpoint got slower, not just that something did | | 5xx responses | errors, by route | | Open sockets | realtime health | | MariaDB queries and connections | database pressure | | Redis memory | both roles, side by side | When we ship a change, we watch this dashboard for the next few minutes. Most bad deploys show up here as a step change in one panel before anyone files a complaint. ## Crash reports: GlitchTip Metrics tell us that something is wrong. Crash reports tell us **what** went wrong, with a stack trace. We self-host **GlitchTip**, an open-source crash tracker that speaks the same protocol as Sentry, so standard Sentry SDKs work with it. Self-hosting keeps costs predictable and keeps crash data on our own infrastructure. We have one project per source: - **Customer app**, iOS and Android, using the standard Sentry SDKs. Personal data, screenshots and view hierarchies are turned off. Reports are tied to the exact app version and build, so we know which release a crash belongs to. - **Rider and partner apps**, with a small reporter written in pure Dart. It only runs in release builds and keeps a short offline queue, because riders often lose signal between drops. Being pure Dart means it can ship as an over-the-air patch. - **Laravel**, reporting from the framework's error handler. Reports are sent after the response has gone back to the user, so reporting never slows a request down. Email addresses and long digit runs such as phone numbers are masked before anything leaves the server. - **Go**, where we again skipped the SDK. A small package catches panics, wraps every handler and turns error-level logs into reports, with de-duplication and a rate limit so one broken loop cannot flood the tracker. Every project has the same alert rule: a **new** kind of crash sends an email right away. Repeats of a known crash do not, which keeps the inbox meaningful. It paid off quickly. In its first day the tracker caught a layout loop in a native screen during internal testing, and it confirmed that a short database blip early one morning touched only a handful of requests and nothing else. Knowing the blast radius of an incident is often more useful than knowing it happened. ## Habits that keep the signals clean Tools only help if the signal stays clean. A few habits we hold ourselves to: - **Test noise is labelled.** Every report carries its environment, and work on our tests server is never mistaken for production. - **Measure before and after.** Every speed change in this series has a before and after number, taken the same way. If we cannot measure it, we do not claim it. ## What's next for the backend We set ourselves clear targets: fast API answers even for the slowest requests, an app that feels open almost instantly, order status and rider pins on screen in well under a second, and store and menu changes visible within moments. Parts two and three got us most of the way. Here is what is live now and what is planned. **Live: dedicated search.** Dish and store search now runs on **Meilisearch**. A sync job regularly sends only changed items and stores. It understands the spellings people actually type, so "briyani" still finds biryani and "mo:mo" finds momo. Search has a strict time budget: if Meilisearch is slow or down, the app falls back to the previous database search instead of waiting. **Planned: H3 for location.** Today, delivery areas and nearby riders are worked out with polygons and radius queries. We plan to add H3, a hexagonal grid system, so questions like "which riders are near this restaurant" or "how busy is this neighbourhood" become cheap lookups. That matters most for dispatch and for understanding demand across a town. **Planned: Redis Streams for order events.** Today, features react to order changes on their own. We plan to publish every order event to a durable stream, so dispatch, notifications and analytics each read the same ordered log at their own pace, and nothing is lost if a consumer restarts. **Planned: a database read copy.** Reports and heavy admin pages read from the same database that takes orders. A read copy on a second server will move that load away from the order path. This needs new hardware, so it comes after the next server is in place. We will write about each of these when it ships, with numbers. ## Thanks for reading That is the end of the series. We started with a monolith on a small footprint, put Go on the hot paths without a rewrite, made the important things realtime, moved the customer app to native code, and built ways to see whether any of it worked. If you are an engineer in Nepal who likes this kind of work, building fast software for towns that are usually last in line, we would love to hear from you. *This is part five of our series on Laayo's tech stack.* --- # Laayo at a glance > The short, reliable answer to "what is Laayo?" Who runs it, where it delivers, what it offers, where to find it online and how to reach the team. - Source: https://blog.laayo.com.np/laayo-at-a-glance - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 22, 2026 - Topics: Laayo, Birtamod, Damak, Jhapa, Company This page is our fact sheet. If you want one place that explains what Laayo is, who is behind it and how to reach us, this is it. We keep it up to date as things change. ## What Laayo is **Laayo is a food and grocery delivery app in Birtamod and Damak, Jhapa, Nepal.** You order from local restaurants and shops in the Laayo app or on the web, and Laayo's own riders bring the order to your door while you follow them live on the map. Laayo is run by **Laayo Services Pvt. Ltd.**, a Nepali company based in **Birtamod, Jhapa, in Koshi Province**. Our office is at **New Kanchanjunga Tole, Birtamod**. Birtamod is sometimes written "Birtamode"; both spellings mean the same town. Laayo was founded by **Sakshyam Baral**, a full-stack developer from Nepal. You can read more in [Who founded Laayo](https://blog.laayo.com.np/who-founded-laayo). ## Where Laayo delivers Laayo delivers in **Birtamod**, the towns around it in **Central Jhapa**, and **Damak**. These are the places where Laayo is live today, with its own riders and local restaurant and shop partners. Laayo does **not** deliver in Kathmandu yet. Kathmandu is the next city we are preparing for, and we will announce it when it is ready. Read why we began in smaller towns in [Why we started Laayo in Birtamod and Damak](https://blog.laayo.com.np/delivery-in-small-towns). ## What Laayo offers Laayo Services Pvt. Ltd. runs four products on one platform: - **Laayo**, the delivery app. Food from local restaurants, groceries from local shops, live order tracking, chat with the rider and support, and several ways to pay. - **Laayo Plus**, a monthly membership for regular customers, with delivery benefits and priority support. See [What Laayo Plus gives you](https://blog.laayo.com.np/what-laayo-plus-gives-you). - **Qora**, QR payment software for Nepali businesses at [qora.laayo.com.np](https://qora.laayo.com.np). Merchants are paid directly by their own bank; Qora never holds customer money. - **Laayo Biz**, a point of sale for restaurants at [biz.laayo.com.np](https://biz.laayo.com.np), covering billing, tables and staff, connected to the orders a restaurant receives on Laayo. How they fit together is explained in [One company, four products](https://blog.laayo.com.np/one-company-four-products). ## How you can pay On Laayo you can pay with **cash on delivery**, with **E-Payment** by scanning a QR in your bank or wallet app, or with your **Laayo wallet**. Gift cards can be added to the wallet. More in [Paying with a QR inside the app](https://blog.laayo.com.np/paying-with-a-qr-inside-the-app). ## Where to find Laayo online - **Main website:** [laayo.com.np](https://laayo.com.np) - **Browse restaurants on the web:** [new.laayo.com.np](https://new.laayo.com.np) - **This blog:** [blog.laayo.com.np](https://blog.laayo.com.np) - **Help and support:** [support.laayo.com.np](https://support.laayo.com.np) - **Qora:** [qora.laayo.com.np](https://qora.laayo.com.np) - **Laayo Biz:** [biz.laayo.com.np](https://biz.laayo.com.np) ### The apps - **Android:** [Laayo on Google Play](https://play.google.com/store/apps/details?id=com.laayo.userapplication) - **iPhone:** [Laayo on the App Store](https://apps.apple.com/np/app/laayo-delivery-made-easy/id6757504406) Riders use the **Laayo rider app** and restaurants and shops use the **Laayo partner app**. Both are separate from the customer app. ### Social - **LinkedIn:** [linkedin.com/company/laayo](https://www.linkedin.com/company/laayo/) - **Instagram:** [instagram.com/laayonp](https://www.instagram.com/laayonp/) - **Facebook:** [Laayo on Facebook](https://www.facebook.com/profile.php?id=61578512708538) ## How to contact Laayo - **Email:** support@laayo.com.np - **Phone:** 9707055875. This is Laayo's single public number for customers, riders and restaurant partners. - **In the app:** the Help section and order chat reach our support team. See [Help when you need it](https://blog.laayo.com.np/help-when-you-need-it). - **Investors, partners and press:** use the form on our [Investors page](https://blog.laayo.com.np/investors). ## Policies Laayo's official policies are published on the main website: - [Privacy policy](https://laayo.com.np/privacy-policy) - [Terms and conditions](https://laayo.com.np/terms-and-conditions) - [Refund policy](https://laayo.com.np/refund-policy) - [Cancellation policy](https://laayo.com.np/cancellation-policy) - [Delete your account](https://laayo.com.np/delete-account) A plain-language summary is in [Privacy and your data at Laayo](https://blog.laayo.com.np/privacy-and-your-data-at-laayo). ## Working with Laayo - **Restaurants and shops** can join as partners. See [Joining Laayo as a restaurant partner](https://blog.laayo.com.np/joining-laayo-as-a-restaurant-partner). - **Riders** can sign up to deliver with Laayo. See [Becoming a Laayo rider](https://blog.laayo.com.np/becoming-a-laayo-rider). - **Businesses** that want QR payments can start with Qora, and restaurants that want a point of sale can use Laayo Biz. ## Quick answers ### What is Laayo? Laayo is a food and grocery delivery app based in Birtamod, Jhapa, Nepal, run by Laayo Services Pvt. Ltd. It delivers from local restaurants and shops in Birtamod, Central Jhapa and Damak with its own riders. ### Where does Laayo deliver? Laayo delivers in Birtamod, the surrounding towns of Central Jhapa, and Damak. It does not deliver in Kathmandu yet. ### Who owns Laayo? Laayo is operated by Laayo Services Pvt. Ltd., a company based at New Kanchanjunga Tole, Birtamod. It was founded by Sakshyam Baral. ### How do I contact Laayo support? Email support@laayo.com.np, call 9707055875, or open Help in the Laayo app. The help center is at support.laayo.com.np. ### Can I use Laayo on the web? Yes. You can order in the browser at laayo.com.np. new.laayo.com.np is a newer, faster way to browse restaurants, menus and prices, and it hands checkout to the Laayo app on Google Play and the App Store. ### What else does Laayo make besides the delivery app? Laayo also runs Laayo Plus (a membership), Qora (QR payment software for businesses) and Laayo Biz (a point of sale for restaurants). --- # One order, one chat > Chatting with your rider, the restaurant or Laayo Support should be about this order, right now. Here is how we cleaned up chat, added photos, videos and documents, and made "send me a QR" actually work. - Source: https://blog.laayo.com.np/one-order-one-chat - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: October 21, 2026 - Topics: Chat, Support, Payments, Riders Chat is where delivery gets real. "I'm at the blue gate." "Can you add extra chutney?" "My order came without the drink." Most of these conversations are short, but they happen at the moments that decide whether an order feels good or bad. This year we made several changes to chat in Laayo. Each one came from a real conversation that went wrong. ## A fresh chat for every order Suppose the same rider delivers to you twice in a week. Before, the app showed one long conversation with that rider across both orders. On the second evening, an old message from the first delivery, something like "how long will it take?", would show up as unread on the new order's tracking screen, and a "New message" banner would appear for a message that was days old. It was confusing for customers and awkward for riders. Now, for customers, **one delivery is one chat**. When you open chat from an order, you see only the messages about that order. Unread counts, message previews and banners are all tied to the order too, so an old conversation can never make a new order look urgent. And while you are already looking at that order's tracking or chat screen, we do not show a banner for a message you can already see. Riders and our support team still see the full history with a customer, because that context helps them. "This customer always asks us to call from the gate" is useful to know. The customer just does not need yesterday's chat on tonight's dinner. This change is rolling out with the new app. ![Customers see one chat per order. Riders and support keep the full history.](https://blog.laayo.com.np/media/seed/order-chat-scope.svg) ## Show us, do not just tell us When something is wrong with an order, a photo explains it faster than any message. Laayo Support chat already accepted photos, but sometimes a short video of a spilled package, or a receipt saved as a PDF, explains it better. The support chat composer now has a plus button with four choices: photos, camera, video and document. Photos open full screen with pinch to zoom, videos play inside the chat, and documents open in the phone's own viewer. The server checks every attachment before storing anything: the type has to be one we accept, and each file has a size limit. If something does not fit, you get a clear message instead of a silent failure. Alongside this, the Help screens now show a small badge when Support has replied and you have not read it yet. It clears as soon as you open the chat. The new attachment options arrive with the app update. ## "Please send me a QR" Many customers decide to pay by E-Payment after the order is on its way. Some type it straight into chat, often in Nepali: "malai QR pathaidinus", please send me a QR. Before, that message waited for a person to read it, and a rider on a bike cannot generate a payment QR. Now the server understands that request, in the support, rider and restaurant chats alike. When a customer asks for a QR for an unpaid order, Laayo creates the order's E-Payment QR, the same one the checkout would show, and posts it into the chat as an image with a short "Scan to pay" line and the amount. The customer can save it and scan it from their banking app. The most important rule in this feature is about trust: **"I paid" is never taken at face value.** When someone writes that they have paid, the server checks the payment record and asks the payment network for the latest status, then answers from what it finds. If the money arrived, the chat says "Paid. Thank you!" and the order is marked paid. If it has not arrived yet, the chat says so politely. A rider never has to decide whether to believe a screenshot. There are a few deliberate limits. In the rider chat, if no online payment was ever started for the order, the assistant stays quiet, because cash and the rider's own arrangements are the rider's call. And the QR message contains no link, only the image, so there is nothing to tap on that could be faked by someone else. This works on the server, so it already works in the current app. The new app adds a large "Save QR" button on the image, so you can save it to your gallery in one tap. ## Messages that arrive straight away Chat is only pleasant when it is instant. Order status and chat messages now arrive over a live connection from our realtime service, so a reply from the rider shows up while you are looking at the screen, instead of on the next refresh. Each conversation has its own private channel, and the app falls back to checking periodically if the connection drops, so nothing is lost on a weak signal. We also learned a small but painful lesson about long messages. On some iPhones, a very long latest message in the rider chat could break the layout of the tracking screen. The automatic messages from the QR feature now put the long explanation first and end with a short closing line, and a recent app version handles long text properly. ## What's next We want to bring photos and documents to the rider and restaurant chats too, with sensible limits so a rider is not asked to download a video on the road. We are also working on quick replies for common moments, such as "I'm at the gate" or "Please call when you arrive", in both English and Nepali. --- # Search that understands "chicken momo" and "chiken momo" > People type the way they talk. We rebuilt Laayo search so briyani, chaumin and panir find the dishes you meant, without letting the noise in. - Source: https://blog.laayo.com.np/search-that-understands-momo - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 21, 2026 - Topics: Search, Meilisearch, Go Open any food app in Nepal and watch someone search. They type fast, with one thumb, often while walking. They write the dish the way it sounds at home, not the way the restaurant spelled it on the menu. Biryani becomes briyani. Paneer becomes panir. Chowmein becomes chaumin. Sekuwa becomes sekwa. Momo sometimes becomes mo:mo, because that is how half of the menus in town write it. For a long time our search treated each of those as a different word. If the restaurant wrote "Chicken Biryani" and you typed "briyani", you got an empty screen and a polite message telling you nothing matched. You did not think "the spelling was off". You thought "Laayo does not have biryani", closed the app and called someone. That is the most expensive empty screen we have. This post is about how we fixed it. ## What search used to do Laayo search started as a database query. It matched the words you typed against dish names, store names and categories, gave each match a score, and sorted by that score. For exact words it worked well, and it was fast enough. The trouble was everything that was not exact: - **Spelling variation.** Nepali dish names written in English have no single correct spelling. The menu and the customer rarely agree. - **Small typos.** "chiken", "piza", "buger". One wrong letter and the match was gone. - **Two languages.** Some dishes have names in Nepali and English, and people search in whichever comes to mind first. We did not want to throw the old search away. It knew a lot about our catalog: which store is open, which zone you are in, which items are available right now. What it lacked was a sense of what you *meant*. ## Adding a search engine next to the database We added [Meilisearch](https://www.meilisearch.com/), an open source search engine built for exactly this kind of forgiving, typed-as-you-go search. It runs on our own servers and keeps a copy of the parts of the catalog that matter for search. ![How a search request flows: the app asks the API, the API asks the database and Meilisearch in parallel, and merges the two answers](https://blog.laayo.com.np/media/seed/search-flow.svg) Each dish in the search index carries its name, any alternate names and translations, the store name, its category and parent category, tags, whether it is vegetarian, which zone the store serves and whether the store is active. Each store carries its name, alternate names, its tags and the names of the dish categories it sells. That last one matters more than it sounds: a store that never put "momo" in its name but has a whole Momo section should still show up when you search for momo. ### Keeping the index fresh A search index is only useful if it agrees with the menu. A small Go program checks the catalog regularly and sends only what changed. It keeps a fingerprint of every document it sent last time, so a quiet check costs almost nothing, and when a store edits one dish, one document moves. Items that were removed are deleted from the index in the same pass. ### Typos and spellings Meilisearch handles typos on its own. We tuned it so longer words forgive more mistakes than shorter ones. Short words stay strict, because "dal" and "dahi" are both real and very different lunches. Typo tolerance does not cover spelling families, though. "Chaumin" is not a typo of "chowmein", it is a different, equally valid way to write the same dish. For those we keep a synonym list: | You type | We also look for | |---|---| | briyani | biryani | | mo:mo | momo | | chaumin | chowmein | | chiken | chicken | | panir | paneer | | sekwa | sekuwa | The list is a mix of common spellings we wrote by hand and ones our team adds when they spot a pattern in what people search for. It keeps growing. ## The hard part: not letting the noise in Making search more forgiving is easy. Making it forgiving without becoming useless is the real work. The first version we tried was too generous. A search for "biryani" returned every dish from a store whose *name* contained Biryani, including its soft drinks. It returned fried rice, because a restaurant had filed fried rice under its Biryani category. A search for "panir" found a pharmacy item, because the word was close enough to something on a medicine label. Three decisions fixed this: 1. **The database still decides what exists.** Meilisearch suggests matching dish and store IDs. Our API takes those IDs and adds them to the normal database query, which still applies every real rule: the store must be in your zone, open or scheduled, the item must be available, the module must be right. Search can never show you something the rest of the app would hide. 2. **A confidence floor.** Meilisearch gives every match a ranking score, and anything below a cut-off we tuned is dropped. In our testing, that line separated "you meant this" from "this shares some letters with what you typed" almost perfectly. 3. **Exact still wins.** Rows that matched your exact words keep their place at the top. Fuzzy matches fill in after them, ordered by how confident the search engine is. If you type the dish exactly as the menu has it, nothing about your results changes. ## Built to fail quietly Search is on the path to every order, so we treated the new engine as a helper, not a dependency. The API gives Meilisearch only a fraction of a second to answer. If it is slow, down or returns something odd, the API carries on with the old database search and you get the results you would have had last month. Answers are cached briefly, because everyone searching "momo" at lunch does not need a fresh lookup each. ## What changed The difference is easiest to see on the searches that used to fail. "Briyani" used to return nothing. It now returns dozens of biryani dishes across the stores near you. "Panir", "chaumin" and "sekwa" went from a handful of results to the full set of dishes people were actually looking for. Searches that were already spelled the way the menu spells them return the same results they always did, which was the point. ## What is next The main search screen is done. Two places still use the old matching and are next on our list: the live suggestions that appear as you type, and the combined "dishes or stores" suggestion list. We are also looking at learning new synonyms automatically from searches that end in an empty screen followed, a few seconds later, by a different spelling that works. Every one of those is a person telling us how they spell their dinner. We should listen. --- # Laayo's tech stack, part four: going native > Why we rebuilt the customer app in Swift and Kotlin, how we moved screen by screen without logging anyone out, and why the rider and partner apps stay on Flutter for now. - Source: https://blog.laayo.com.np/tech-stack-part-four-native-apps - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 21, 2026 - Topics: iOS, Android, Swift, Kotlin, Flutter For most of Laayo's life, all of our apps were built with Flutter. One codebase, two platforms, a small team. It was the right choice when we needed to ship quickly, and the rider and partner apps are still Flutter today. The customer app is different. It is the app people judge us by, opened at lunch on a mid-range Android phone on mobile data, compared in their heads with the biggest apps on their home screen. We wanted it to feel as fast and smooth as the best food apps in the region, and we kept hitting the same limits: start-up time, scrolling on lower-end devices, how transitions and gestures feel, and how much work it took to use new platform features. So the customer app is now fully native: **Swift on iOS and Kotlin on Android**. This post covers how we did it, and what we chose not to do. ![The native customer app in layers: iOS screens in Swift and Android screens in Kotlin sit on a shared Core design with Api and Session, Zone and Config, ApiCache, Realtime, Motion and Prefs. The rider and partner apps stay on Flutter with over-the-air patches. All apps use the same API.](https://blog.laayo.com.np/media/seed/tech-stack-native-apps.svg) ## Two codebases, on purpose The first decision was whether to share code between iOS and Android. Kotlin Multiplatform, which lets both apps share a data layer, was a serious option. We chose two separate native codebases, with one shared **design**. Every core piece exists once in Swift and once in Kotlin, with the same names, the same API shape and the same behaviour, written from one spec. The reasons: - Each app uses its platform's own tools, debugger and libraries with no bridge in between. - A bug on one platform cannot ship to the other by accident. - Anyone who knows Swift or Kotlin can work on the app without learning a third toolchain. The cost is writing core logic twice. We accept it because the core is a small part of the app, and keeping both versions behind the same spec makes the second one fast to write. ## Moving without a big bang We did not stop and rewrite. The app moved in stages, and customers had a working app at every step. 1. **Native screens inside the Flutter app.** We rebuilt screens natively one at a time and showed them from inside the existing Flutter app. Store pages, cart, checkout, tracking and the rest moved across while Flutter still handled start-up, navigation and data. 2. **A native data layer.** Next came the core underneath the screens: API client, session, location and zone, configuration, cart, payments and realtime. For a while both the Flutter code and the native code could load data, and a switch on the server let us choose which one each module used. If a native module misbehaved, we could flip it back without an app update. 3. **A native shell.** Then app start, routing, deep links and the tab bar became native too, so screens no longer needed Flutter to open them. 4. **Removing Flutter.** Finally, the Flutter engine came out of the customer app entirely. The hardest part of the last step was making sure nobody noticed it. Flutter apps store their data, such as the login token, saved address and cart, in their own format. The native app reads that data on first launch and carries it over, so customers updating from the old app stay logged in with their cart intact. ## The Core The **Core** is the set of shared building blocks every screen relies on. A few of them: - **Api and Session.** One client that sends the right headers for your zone, module, language and login on every request. - **Zone and Config.** Where you are, which services deliver there, and the server settings the app needs. - **ApiCache and Prefetch.** When you scroll the home screen and a store card has been visible for a moment, or you start to touch it, the app quietly starts loading that store page. If you tap, the page is often ready before the transition finishes. Prefetched answers are used once and expire quickly, so you never see stale data. Prefetching turns itself off when your phone is in Low Data or Data Saver mode. - **Realtime.** The shared WebSocket client described in part three. - **Prefs.** Local settings storage, including the migration from the Flutter app. Server work supports this. The home bundle from part two lets the home screen load in one request instead of many, and images come as WebP copies sized for how they are shown. ## Motion and feel "Feels native" is mostly about motion, so we treated it as a feature with its own spec rather than polish for later. A shared **Motion** module in Core gives every screen the same spring curves, so nothing moves on its own timing. On top of that: - **Interactive swipe-back.** On iOS you can swipe back from anywhere on the screen, and the gesture follows your finger. On Android the app supports predictive back. - **Shared transitions.** When you open a store, the card lifts and the page grows out of it. The header is drawn from the card's data on the first frame, so only the dish list shows a loading skeleton. - **Sheets.** Bottom sheets open on a spring and can be dragged down to close. - **Quiet feedback.** Rows dim slightly when pressed and buttons change opacity. We deliberately avoided bouncy scale effects, and haptics stay calm. - **Respect the system.** Reduce Motion is honoured, high refresh rate screens get high refresh rate animation, and dropped frames are logged so we can find janky screens. ## Type and colour Both apps share one set of design tokens: Laayo yellow and charcoal, spacing, corner radii and a type scale. The typeface is **Lexend**, an open-licence font designed for readability. We compared a range of open-licence fonts against the look we wanted and Lexend came out on top. Because our sizes were first tuned with a narrower font, a single size factor in Core keeps the visual sizes consistent across every screen. ## Crash reports from day one Native code fails differently from Flutter code, so the native app shipped with crash reporting built in from its first release. Reports go to our own crash tracking server, covered in part five, with personal data turned off and no screenshots. Within hours of our first internal native builds it caught a layout loop on one screen that made the app hang for a few seconds. It was fixed before release. ## Rider and partner apps stay on Flutter The rider and partner apps are tools people use all day for work. They change often, and they matter more for reliability than for smooth animation. Flutter suits them well, so they stay on Flutter. For those apps we use **Shorebird** for over-the-air updates. When a fix only touches Dart code, we can publish a patch that reaches riders' phones without a store release: first to a staging track for our own devices, then promoted to everyone. Native changes, new plugins and version bumps still go through the stores. Going fully native means the customer app gave up over-the-air patches. Every customer app fix is now a store release. That trade-off was made with our eyes open, and it is one reason we invest in server-side switches. Much of the app's behaviour can be adjusted from the server without a new build. ## What's next With the native shell in place, the next work is the remaining performance items on the list: faster first open for brand-new users, and more screens served by a single combined request. In part five, the last part of the series, we look at how we watch all of this in production, from dashboards and per-route latency to crash reports, and at what is planned next for the backend. *This is part four of our series on Laayo's tech stack.* --- # Laayo for developers, APIs, engineering notes and reporting a security issue > Where developers can build with Laayo today, what we share about how we build, and how to tell us about a security problem responsibly. - Source: https://blog.laayo.com.np/laayo-for-developers - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 21, 2026 - Topics: Developers, Qora, Security, Guides Developers find Laayo for different reasons. Some want to accept payments, some want to connect a restaurant's systems, some are curious how a delivery app for smaller towns is built, and a few have spotted something that looks wrong. This page answers each of those. ## Does Laayo have a public API? The Laayo delivery app does not have a public API for placing or managing orders. Customers order through the Laayo app and website, and partners manage orders in the Laayo partner app. Where developers can build with us today is **payments**, through Qora. ## What is the Qora API? Qora, made by Laayo Services Pvt. Ltd., lets a business take QR payments and know right away when a customer has paid. For developers it offers: - **A REST API** to create payments and check their status. - **Signed webhooks** that tell your server when a payment succeeds, which your server can verify came from Qora. - **Documentation with a live console**, where you can use your own key to create a real payment from the docs page and watch it complete. - **Payment links and counter QR posters** for the parts of a business that do not need code. Qora never holds customer money. Payments go straight to the merchant's own account. The documentation is at **qora.laayo.com.np**, and there is a plain explanation in [what is Qora](https://blog.laayo.com.np/what-is-qora). ## Can a restaurant connect its own system to Laayo? Restaurants on **Laayo Biz**, our point of sale, are connected to Laayo already: delivery orders arrive in the POS and kitchen, and the kitchen's progress goes back to the customer. See [what is Laayo Biz](https://blog.laayo.com.np/what-is-laayo-biz). If your restaurant uses another system and you want to connect it, talk to our team through the partner app or support@laayo.com.np. ## Where can I read about how Laayo is built? This blog is where our engineering team writes. Good places to start: - [Laayo's tech stack](https://blog.laayo.com.np/tech-stack), a five part series from the servers up to the apps. - [Search that understands momo](https://blog.laayo.com.np/search-that-understands-momo), on typo-tolerant dish search. - [How we estimate delivery time](https://blog.laayo.com.np/how-we-estimate-delivery-time). - [Rider GPS that never gets stuck](https://blog.laayo.com.np/rider-gps-that-never-gets-stuck). - The full [Engineering section](https://blog.laayo.com.np/category/engineering). We write about decisions and trade-offs, not about internal details that would put our systems or partners at risk. ## How do I report a security issue? If you think you have found a security problem in a Laayo app, website or Qora, please tell us privately. 1. **Email support@laayo.com.np** with "Security" at the start of the subject. 2. **Describe what you found** and the steps to see it, with the date and time you tested. 3. **Give us time to fix it** before telling anyone else. Please do not access, change or keep other people's data, run tests that slow down or break our services, or try social engineering on our team, riders or partners. Test only with your own accounts. A person on our team will reply, and we will tell you when the issue is fixed. We are grateful to anyone who reports a problem responsibly. ## Does Laayo hire developers? Laayo is a small team that builds its apps, backend, payments and point of sale in-house. If you would like to work with us, send a note through the contact form on our [Investors page](https://blog.laayo.com.np/investors) with "Something else" and tell us what you would like to work on. ## Quick answers ### Does Laayo have a public ordering API? No. Developers can build with Laayo through the Qora payments API today. ### Where are Qora's API docs? At qora.laayo.com.np, with a live console that creates a real payment using your own key. ### Does Qora send webhooks? Yes. Qora sends signed webhooks when a payment succeeds, and your server can verify them. ### How do I report a security vulnerability to Laayo? Email support@laayo.com.np with "Security" at the start of the subject, describe the steps, and give us time to fix it before sharing. ### Where can I learn about Laayo's tech stack? Read the five part tech stack series at blog.laayo.com.np/tech-stack and the Engineering section of this blog. --- # Laayo for families and gifts > Ordering for parents back home, sending a treat to a friend, giving a gift card or ordering together as a group. How to use Laayo for the people you care about. - Source: https://blog.laayo.com.np/laayo-for-families-and-gifts - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 20, 2026 - Topics: Guides, Gifts, Families, Group orders Many Laayo orders are not for the person holding the phone. Students order lunch for their parents. Someone working in another city or abroad sends dinner home. Friends treat each other on birthdays. This guide shows the ways Laayo helps you look after people. ## Can I order food for my family from another city or abroad? Yes. Laayo works from anywhere, as long as the delivery address is in an area we cover, such as Birtamod or Damak. 1. **Install the app** on your phone and sign in with your mobile number. 2. **Set the delivery pin** to your family's home. Save it as an address, for example "Home in Birtamod", so it is ready next time. 3. **Add their phone number** in the delivery details, so the rider calls them, not you. 4. **Pay online**, with E-Payment or your Laayo wallet, so nobody needs cash at the door. You can follow the order live from wherever you are, and share the tracking link with them so they know when the rider is close. See [Tracking your order](https://blog.laayo.com.np/tracking-your-order). ## What is Send a Treat? Send a Treat is a way to order food as a gift. You choose the food, set the recipient's location and number, add a message, and pay in advance. The recipient gets a message with a link to follow their treat, and the rider calls them on arrival. Send a Treat is rolling out. Read [Gift cards and Send a Treat](https://blog.laayo.com.np/gift-cards-and-send-a-treat). ## How do Laayo gift cards work? A Laayo gift card is a present the other person spends on whatever they like. 1. Choose a design, such as birthday, thank you or anniversary. 2. Choose the amount and enter the recipient's name with their phone number or email. 3. Add a message and pay. 4. The recipient gets a code by SMS or email, claims it in the Laayo app, and the value goes into their Laayo wallet. Gift cards work well when you do not know what someone wants to eat, or when you want them to be able to order more than once. ## How do group orders work? A group order lets several people add their own food to one order from one restaurant. The host starts the group, shares a link, and everyone adds what they want from their own phone. When everyone is done, the host checks out and pays, and the food arrives together. It is perfect for office lunches, family dinners and hostel nights. Read [Ordering together with group orders](https://blog.laayo.com.np/ordering-together-with-group-orders). ## Can I order for an elderly parent who does not use smartphones? Yes. Order from your own phone with their address and their phone number as the contact, and pay online. If they have hearing, vision or mobility needs, you can mention them in the delivery instructions so the rider knows how to hand over the food. See [Designing for everyone](https://blog.laayo.com.np/designing-for-everyone-accessibility). ## What do festivals look like on Laayo? During big festivals like Dashain and Tihar, Laayo often adds festive touches and offers in the app, and families use it to send food to relatives. Read [Dashain on Laayo](https://blog.laayo.com.np/dashain-on-laayo). ## Quick answers ### Can I order Laayo for my parents from abroad? Yes. Set the delivery pin to their address in an area Laayo covers, add their phone number as the contact, and pay online. ### What is Send a Treat on Laayo? Send a Treat lets you order food as a prepaid gift for someone else, with a message and a tracking link for them. It is rolling out. ### How do I send a Laayo gift card? Pick a design and amount in the app, enter the recipient's phone or email, and pay. They get a code to claim into their Laayo wallet. ### Can several people order together? Yes. Start a group order, share the link, let everyone add their food, then check out once. ### Does the person receiving the food need the Laayo app? No. The rider calls the phone number on the order, and a tracking link works in any browser. --- # One restaurant card, everywhere > Home, search, categories, offers and collections each had their own restaurant card. We replaced all of them with the one people liked best, and learned a lot about consistency on the way. - Source: https://blog.laayo.com.np/one-store-card-everywhere - Section: Design - Author: Laayo Design (Laayo Services Pvt. Ltd.) - Published: October 20, 2026 - Topics: Design system, Native apps, UX If you count the places a restaurant can appear in a food app, the number is surprising. The home feed. Search results. A category page like Biryani or Momo. An offers page. A curated collection. "See all" lists. In our app each of those had grown its own restaurant card, built at a different time by a different person for a slightly different reason. None of them was bad on its own. Side by side, they told you the same facts in different places, with different photo crops, different badges and different ways of saying "closed". Customers do not compare cards, but they feel the difference: the app stops feeling like one product. So we did the obvious, slightly painful thing. We picked the best card, the one on the home screen, and made it the only one. ![One shared restaurant card feeds every list in the app: home, categories, search, item lists, offers, collections and see-all pages. A few places keep their own layout on purpose.](https://blog.laayo.com.np/media/seed/one-card.svg) ## What the home card does well The home card earned its place because it answers the questions people actually have, in the order they have them: 1. **What does the food look like?** A large photo, and for many restaurants a slow loop through their popular dishes, each with a small label showing the dish and its price. 2. **Is it good?** A rating chip in the corner. 3. **How long, how far?** Delivery time and distance on one line, separated by a thin divider. 4. **Is there a reason to pick it today?** An offer line or a free delivery ribbon, only when one actually applies. 5. **Can I order right now?** If not, a clear line under the name: "Closed now", with the time it opens, and a greyed photo. It also carries the small things: a bookmark, a Laayo Plus badge where it applies, a Pure Veg mark for vegetarian kitchens, and a quiet "Near and fast" flip for restaurants that are both close and quick. Every one of those is a fact about the restaurant, not decoration. ## One component, many pages Technically, the change was to lift the card out of the home screen and turn it into a shared component, on both iPhone and Android. Each page now only has to say two things to it: here is a restaurant in whatever shape my data comes in, and here is what should happen when someone taps or bookmarks it. That first part, translating each page's data into the card's shape, turned out to be the real work. Search results, offers and collections all come from different endpoints, and some had fields the home card expects, like distance or a vegetarian flag, while others did not. Where a page was missing something, we added it to the data rather than letting the card guess. Where a page has nothing to show, like dish prices on the offers list, the card simply leaves that part out. Some behaviour had to be shared carefully: - **Animations in step.** Cards that loop through dish photos or flip their badge all read from one shared slow clock, so every card on screen moves together instead of each one flickering on its own rhythm. Off screen, they stop. - **Bookmarks that do not fight.** Tapping the bookmark updates the card immediately, and the page confirms it when its own data refreshes. If the page already manages bookmarks itself, the card waits for it, so you never see the heart turn on, off and on again. - **Opening feels the same everywhere.** Tapping any card starts loading the restaurant before the page appears, and the photo and name carry over into the restaurant page. That used to be a home-only nicety. - **Accessible everywhere.** The spoken labels and actions we built for the home card now come along for free on every list. ## Saying "closed" one way The most useful side effect was consistency in bad news. Before, one page said "Closed", another "Currently not delivering", a third showed the card dimmed with no explanation. Now a closed restaurant looks the same wherever you meet it: grey photo, a clear line under the name, and when we know it, the time it opens next. That matters because "closed" is the moment a customer is most likely to give up. If we are going to disappoint them, we can at least be clear about it and tell them when to come back. ## Where we kept a different card We did not force the home card into every corner. A few places keep their own layout on purpose: - **Grocery** uses compact product tiles, because you are choosing items, not kitchens. - **The restaurant page itself** has its own header, since you are already inside the restaurant. - **Order details** show a small store summary, because the question there is "what did I order", not "where should I order". - **Small rails** like "Recommended for you" use a compact version so several fit across the screen. The rule is simple: any full-width list of restaurants uses the shared card. Anything else needs a good reason. ## The same thinking in Your Orders We applied the same idea to order history earlier this year. Each past order shows the restaurant and area, the items you had with veg or non-veg marks, the status and total, and a single main action: Reorder if the restaurant is delivering now, or a plain "Currently not delivering" if it is not. You can rate right from the card, and orders still on their way sit at the top of the same list with a Track order button, instead of hiding in a separate tab. ## What it cost, and what it saved Replacing all those cards with one was not free. Every page had to be tested again, and a few small features that only one card had, like a swipeable photo strip in search, were dropped because the home card does not have them. We think that trade is right: one excellent card is better than eight decent ones. It also makes the future cheaper. When we improve the card, every list improves at once. When we fix a bug in it, it is fixed everywhere. The shared card is rolling out across the app with the next update. --- # Rating your food should be quick > Ratings help you pick a good meal and help kitchens get better, but only if people leave them. Here is how we made rating an order quick, kind and impossible to get stuck in. - Source: https://blog.laayo.com.np/rating-your-food-in-one-sheet - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: October 20, 2026 - Topics: Ratings, Reviews, Restaurants, Orders A star rating looks like the smallest feature in a food app. It is also one of the most important. When you choose between two biryani places you have never tried, the stars and a few honest words from other people are most of what you have to go on. And for the kitchens, a rating is often the only feedback they get from anyone who did not call to complain. The problem is that very few people rate their orders. Not because they do not care, but because by the time the food arrives, the app is the last thing on their mind. And when they do open the rating screen, it asks for too much. ## Ask at the right moment The best moment to ask is not while the food is still hot. It is the next time you open Laayo after a delivery. You have eaten, you have an opinion, and you are already holding the app. So that is when we ask. The next time you open the app after an order is delivered, a sheet slides up: **Rate your food**. It shows the restaurant's logo, the date and the amount, so you know straight away which order it is about. We set firm rules about when this sheet is allowed to appear, because nothing is more annoying than a rating popup that will not take no for an answer: - It only asks about an order you **received recently**. - It asks about one order at a time, the most recent one you have not rated. - It gives up after **a few** tries. If you skip it, it stays skipped. - It never appears on top of another sheet, a dialog or a screen you are in the middle of. It waits for you to be on the home screen. - If you have already **reported a problem** with that order, it does not ask you to rate it. You have told us enough. ## Stars, a few taps, done The sheet is built so that one tap is a complete rating: 1. **Tap the stars.** That alone is enough. 2. **Tap a reason or two**, if you like. The choices match the stars you picked: good things for four or five stars, like *Tasted good* or *Well packed*, and problems for one to three, like *Arrived cold* or *Small portion*. Reasons are a fixed list on purpose: a restaurant can act on "lots of people said it arrived cold" in a way it cannot act on a pile of different sentences. 3. **Write a line**, if you want. The comment box is one line that grows as you type, not a big empty box that makes you feel you owe us an essay. If the order came with one of our riders, a second short step asks about the delivery. Then the sheet says thanks and closes itself. If you give one or two stars, a small link appears: **Something went wrong? Report an issue.** A low rating often means something we should fix for you, not just record. The link takes you straight to the order report, where our support team can actually help. There is always a **Skip** at the top. Nobody should have to rate a meal to get back to their app. ## Where your rating goes Your rating does not live in a separate box that only we read. It is written into the same reviews that restaurants and other customers already see. The store's stars update, the dish ratings update, and your order history shows the rating you gave. The restaurant gets **one** notification per rated order, not one for every dish in it. A kitchen with a big lunch rush does not need their phone buzzing six times for one customer. ## One sheet, everywhere Until now, there were several ways to rate an order, and they did not look alike: the prompt, a button on the order page, a link in your order list, and the link in the notification. Each one was a little different. In the next update, all of them open the same sheet. You can rate each dish on its own, tell us how the packaging held up, and submit once. If your connection drops halfway, the parts that already went through are remembered, so pressing Submit again does not send your review twice. On the order page, a delivered order shows **Rate your order** with five empty stars. Once you have rated it, the card shows *Your rating for* the restaurant, with your stars filled in, so you can see what you said. ## What we chose not to do - **No rating walls.** We never block reordering, tracking or anything else behind a rating. - **No reminders by notification.** The prompt appears in the app a few times at most, and that is it. - **No tip request inside the rating.** Tipping your rider has its own place on the tracking screen. Mixing money into a feedback form makes both worse. - **No photos in the quick sheet, for now.** Photos make reviews richer but slow the sheet down. We kept the fast path fast. ## What's next The single rating sheet is rolling out in the next app update. If a restaurant you love has few ratings, the kindest thing you can do for them takes a few taps. --- # Motion that feels native, and stays cheap > How we build transitions that follow your finger, festival skins that do not drain the battery, and floating buttons that let the photo behind them shine through. - Source: https://blog.laayo.com.np/motion-that-feels-native - Section: Design - Author: Laayo Design (Laayo Services Pvt. Ltd.) - Published: October 20, 2026 - Topics: Motion, iOS, Android, Performance, Design system Good motion is mostly invisible. You notice it only when it is missing: a screen that slides in from the wrong side, a back gesture that does not follow your thumb, a page that stutters while something decorative spins in the corner. Moving the customer app to native Swift and Kotlin gave us direct access to the system's own physics. This post covers three things we learned while using it: how we keep transitions consistent, how we keep always-on animation from eating the frame budget, and how we chose the look of our floating buttons. ![The motion budget: one shared slow clock drives every decorative layer at a gentle, lower frame rate, static parts are drawn once and cached, and only short, user-driven transitions run at the full refresh rate.](https://blog.laayo.com.np/media/seed/motion-budget.svg) ## One motion library, not forty screens of opinions When every screen animates itself, you get forty slightly different slide curves. Some pages ease in, some spring, one bounces. Individually each looks fine. Together the app feels stitched together. So we wrote one shared motion module per platform and every native screen uses it. It covers: - **Springs.** A small set of named spring settings for pushes, sheets and small reveals. A new screen picks a name, not a number. - **Swipe back.** On iPhone you can swipe back from anywhere on the screen, not only the very edge, and the previous page follows your finger. On Android we support predictive back, so you can peek at where you are going before you let go. - **Sheets.** Bottom sheets open with a spring and can be dragged down to dismiss, with the background dimming in step with your finger. - **Shared elements.** When you tap a restaurant card, the photo and name carry over into the restaurant page instead of the page appearing from nowhere. - **Cross-fades from skeleton to content.** When real content replaces a placeholder, it fades in place rather than popping. - **Press feedback.** A row dims slightly when touched and a button fades a little. Nothing shrinks or bounces. Every one of these respects the phone's accessibility settings. If you have Reduce Motion turned on in iOS, or animations switched off in Android's settings, transitions become simple fades or happen instantly. ## The first frame matters most The moment that makes an app feel fast is the first frame after a tap. If that frame is empty, the user waits, no matter how quickly the rest arrives. Our rule for opening a restaurant is that the page should already look like the restaurant on frame one. The card you tapped already holds the name, photo, rating and delivery time, so the new page draws its header from that data immediately. Only the dish list, which really does need the server, shows a placeholder. The new treatment for this, where the card lifts slightly as you press and the page pushes in while home slides back, is rolling out with the next app update. ## Always-on animation is expensive Some motion is not tied to a tap at all. During festivals, the home screen gets a seasonal skin with gently moving decorations. These are lovely, and they are also the easiest way to make a phone run hot. We learned this the direct way. During one festival skin, an iPhone with a high refresh rate screen felt laggy on the home page while an Android phone next to it was fine. The cause was a pile of small decisions: - Several separate animation timers, some of them covering the whole screen, each asking for a new frame on every screen refresh. - A masking effect that forced a full redraw of a large layer. - A shadow being drawn again on every frame for a badge that never moved. On a high refresh rate iPhone, that meant the whole page was being repainted at full speed, over and over, just for decorations. The fix was not to remove the skin. It was to draw it more cheaply: 1. **One slow clock.** Every decorative layer now reads its progress from a single shared timer that ticks at a slower, steady pace. All the layers land on the same frame, and the system has a fraction of the work to do. 2. **Static parts drawn once.** Anything that does not move, like a badge with its shadow, is drawn into its own cached layer that is never repainted. 3. **No expensive effects inside anything that moves.** Fades are done with the colour of the stroke instead of a mask, and blur or shadow effects are kept out of animated layers. 4. **Off when not visible.** The clock stops when the screen is not on top, and it never starts when the user has asked for reduced motion. Short, one-off moments that you trigger, like a page push or a sheet opening, still run at the full refresh rate. That is where smoothness is felt. Decorations that just drift can run slower without anyone noticing, and the battery notices the difference. We also log dropped frames during development, so a new animation that is too heavy shows up as a number before it shows up as a complaint. ## Glass that shows the photo Restaurant and store pages open with a large photo or video at the top, with a few floating buttons over it: back, search, share, more. For a while, those buttons were small dark frosted circles. They worked, but they read as grey blobs sitting on top of the food. On recent iPhones we now use clear glass for every floating button. The image behind shows through, with a thin bright rim to keep the button visible, and no dark fill. On older iOS versions the same buttons fall back to a very light frosted material. Bars, search fields, sheets and toasts keep a slightly stronger glass, because they hold text that needs to be read. Android does not have the same live blur behind views, so there we use a frosted fill tuned to look as close as we can. The goal on both platforms is the same: the button should feel like part of the photo, not a sticker on it. ## What we keep asking Before any new motion ships, we ask three questions: - **Does it follow the user?** A transition that responds to a finger beats one that plays on its own. - **Does it say something?** Motion should show where something came from or where it went. Decoration that says nothing should be cheap or absent. - **What does it cost?** We check it on the most demanding screen we have, not just the newest phone in the office. Most of what is described here is in the native customer app already, and the rest is rolling out with the next update. If an animation in Laayo ever feels slow, rushed or out of place, we would genuinely like to hear about it. --- # Making the Laayo app open fast, even the very first time > We timed a brand new install from tap to home screen and found a chain of small waits. Here is how we cut them, from GPS and duplicate calls to images and one bundled home request. - Source: https://blog.laayo.com.np/making-the-app-open-fast - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 20, 2026 - Topics: Performance, Mobile, Go, Images Speed in a delivery app is measured in two places. The first is obvious: how fast your food arrives. The second is how fast the app gets out of your way when you are hungry. If the home screen takes long enough that you start wondering whether the app is broken, you have already had a bad experience before you have seen a single restaurant. We set ourselves a simple goal: the app should feel open almost instantly for someone who uses it every day, and a new user who has just installed it should never stare at a spinner long enough to give up. This post walks through what we measured and what we changed. ## Following one new user We started with the hardest case: a phone that has never had Laayo installed. We went through every step between tapping the icon and seeing restaurants, and timed each one. What we found was not one slow thing. It was a chain of small waits, each reasonable on its own, that added up. - **GPS asked for perfection.** The app asked for a high accuracy location with a long time limit and ignored any recent location the phone already knew. Indoors, that often meant waiting until the limit ran out. - **The same question, again and again.** After getting a location, the app asked the server which delivery zone it was in. Then it asked again, and again from a different screen. Each answer was the same. - **Loading before deciding.** The app picked the food section only after the home screen appeared, so the first loading pass ran without knowing what to load, and then threw the result away and loaded again. - **A new connection for every call.** Each API request opened a fresh connection to the server, with its own security handshake. The home screen makes a lot of requests as it opens. - **A false alarm.** On a brand new install there is no saved app configuration yet. The app treated that empty cache as "no internet" and briefly flashed an error screen, even on a perfect connection. ![Where the time went on a first open, before and after](https://blog.laayo.com.np/media/seed/first-open-timeline.svg) ## Fixing the chain Each fix was small: - **A fast first fix.** If the phone has a recent location that is close enough, we use it straight away. If not, we ask for a medium accuracy fix first and only then for high accuracy. The worst case stays the same, but the usual case is much faster. - **Ask once, remember briefly.** Zone lookups are now remembered for a short time per location, and if a lookup is already in flight, everyone waits for that one instead of starting their own. Finding the address and the zone now happen in parallel. - **Decide first, then load.** The app chooses the food section before it navigates home, so the first load is the right one. - **Reuse connections.** All requests now share one HTTP client that keeps connections open, so the handshake happens once instead of on every call. - **No more false alarm.** An empty configuration cache on first launch is no longer treated as a network error. We also looked at the human steps. A new user used to be sent to a login screen before seeing anything. Now they land on the home screen as a guest and are asked to sign in only when they need to, such as when placing an order. The notification permission prompt moved from the very first frame to a moment where it makes sense. ## Images were the real weight When we measured what the home screen downloads, the API responses were not the biggest cost. Images were. Restaurant logos and dish photos were often uploaded as very large PNG files, and the app downloaded them at full size to show them as small cards. Rather than ask every partner to re-upload their photos, we fixed it on the server. A background job finds every store and dish image, creates a WebP copy resized for how that kind of image is actually shown, and keeps it next to the original. The web server then quietly serves the WebP copy to apps that ask for the original, whenever a copy exists. If a WebP copy would not be meaningfully smaller, we keep the original. New uploads get their copies soon after. Nothing changed in the apps for this to work, and nothing broke for older app versions. They just started receiving smaller files. ## One request for the home screen The home screen shows several rails at once: popular restaurants, newly added ones, recommendations, offers and more. Each rail was its own request, and the app fired them one after another. Our Go service now offers a single home bundle request that builds all of those rails in one go, running the individual parts side by side inside the server. Each part is exactly what the separate request would have returned, so the app can use the bundle without any change in what it shows. In our measurements the whole bundle comes back far faster than the rails did one by one. ## Getting there before you tap The last trick is to do work before it is needed. The app now starts fetching the home bundle as soon as the home screen begins to load, and it starts fetching a restaurant's page when a card is about to be tapped, for example when your finger touches it. When the real request is made a moment later, the answer is often already waiting. These prefetched answers are carefully scoped. Each one is tied to the exact request, your location, your language and whether you are signed in, it can be used only once, and it expires quickly. If anything does not match, the app simply makes the normal request. On Low Data or Data Saver mode, store prefetching is switched off so we never spend data you did not ask us to spend. The app side of these changes is rolling out with the new customer app. The image copies and the home bundle are already live on the server. ## What's next Next we are trimming the data itself. Many API responses include fields the app never reads, and a store object can be much larger than what the screen needs. Smaller responses mean less to download on slow networks and less work for older phones, which matter a lot in the towns we serve. --- # What comes next for Laayo > Our plans for what comes next, from deepening service in Birtamod and Damak to preparing for Kathmandu, exploring Laayo Supply and finishing the move to native apps. Plans, not promises. - Source: https://blog.laayo.com.np/what-comes-next - Section: Investors - Author: Laayo Leadership (Laayo Services Pvt. Ltd.) - Published: October 20, 2026 - Topics: Roadmap, Strategy, Kathmandu, Laayo Supply People who follow Laayo often ask what we are working on next. This post is our honest answer. Everything here is a plan, and plans change as we learn. We will only share dates when we are confident in them. ## 1. Be excellent where we already are Our first priority has not changed: make Laayo genuinely excellent in Birtamod and Damak. That means faster deliveries, mainly by cutting the time food waits at restaurants for a rider. It means food that arrives the way it left the kitchen, through better packaging and order checks with partners. It means payments that never leave anyone unsure, support that reaches a real person quickly and refunds that customers can follow step by step. These are not new features. They are the basics done very well, and they are what earns a town's trust. Everything else on this list depends on getting this right. ## 2. Finish the move to native apps We are rebuilding the customer app in Swift for iPhone and Kotlin for Android. Native apps open faster, scroll more smoothly and feel more at home on each phone. We are moving screen by screen so nobody is logged out or loses their cart along the way. Many improvements described on this blog arrive with these new builds, including faster first opens, a simpler rating sheet, clearer refund timelines and a smoother QR payment flow. You can read about the approach in [part four of our tech stack series](https://blog.laayo.com.np/tech-stack-part-four-native-apps). ## 3. Prepare for Kathmandu Bringing Laayo to Kathmandu is our main expansion plan. We are not sharing a date; we will announce it here when we are ready. Kathmandu is a very different market from our home towns: bigger, busier and more competitive. We do not intend to arrive as a smaller copy of what is already there. We plan to bring what makes Laayo different: close relationships with partners, honest delivery estimates, transparent statements and payouts, and a product shaped by real local knowledge. We will launch only when we are confident we can deliver the same standard of care there as at home. ## 4. Explore Laayo Supply Restaurants spend a lot of time buying supplies: rice, oil, flour, gas, packaging. We are exploring Laayo Supply, a way for restaurant partners to order kitchen supplies in the partner app, receive them the next morning before opening and pay from their next Laayo payout or by E-Payment. If we build it, we would start with non-perishable items, where reliability is easiest to guarantee, and add fresh items only once supply is steady. Laayo Supply would make our partners' days easier, give riders useful morning work and deepen our relationship with every restaurant we serve. ![What comes next: excellence at home, native apps, Kathmandu preparation and Laayo Supply exploration, built on a stronger platform](https://blog.laayo.com.np/media/seed/investor-roadmap.svg) ## 5. A stronger platform underneath Some of our plans are invisible to customers but important for growth. We plan to adopt a hexagon-based map grid, known as H3, for smarter dispatch and pricing by area. We plan to move order events onto streams so different parts of the system can react to an order without slowing it down. And we plan to add a read copy of our database so reports and heavy queries never compete with live orders. These changes prepare the platform to handle more towns and more orders without a matching rise in cost. We explain them at the end of [part five of the tech stack series](https://blog.laayo.com.np/tech-stack-part-five-observability). ## 6. Grow Qora and Laayo Biz Qora and Laayo Biz already serve businesses in our towns and beyond. We plan to keep improving both, connect them more tightly with the marketplace, and offer them to more businesses as we expand. Every restaurant that uses Laayo for delivery, Laayo Biz for its counter and Qora for payments is a stronger partner for us. Read more in [one company, four products](https://blog.laayo.com.np/one-company-four-products). ## How we decide When we choose between priorities, we ask three questions: 1. Does it make life better for customers, partners or riders in a way they will notice? 2. Does it strengthen the trust that keeps people with us? 3. Can a small team build it well and keep it running? If the answer to all three is yes, it goes on the list. If not, it waits. We will keep sharing progress on this blog, including what goes well and what takes longer than planned. If you would like to talk to us about any of this, visit our [investors page](https://blog.laayo.com.np/investors). --- # Loading without lying > A loading screen makes promises. Here are the rules we use so that what you see while Laayo loads is never wrong, never jumpy and never thrown away for no reason. - Source: https://blog.laayo.com.np/skeletons-not-spinners - Section: Design - Author: Laayo Design (Laayo Services Pvt. Ltd.) - Published: October 19, 2026 - Topics: Loading, UX, Design system Most of the time you spend looking at a delivery app is spent waiting for it. The menu is loading, the fee is being worked out, the order list is refreshing. We used to treat those moments as gaps between real screens. They are not. A loading state is a screen too, and it can be right or wrong just like any other. Earlier this month we wrote about how loading looks in the new Laayo: the outline of the page with a short food line and our two-arc loader above it. This post is about the less visible half: the rules that stop a loading state from telling you something untrue. ![Three rules for loading: a first load shows the page outline, a refresh keeps the old content until new content lands, and an unknown value is never shown as a bad one.](https://blog.laayo.com.np/media/seed/loading-rules.svg) ## Rule one: a placeholder is not data When you tap a restaurant, the app often knows only a little about it: its id, maybe its name from the card you tapped. To open the page instantly, we build a lightweight stand-in for the store and fill in the rest when the server answers. That stand-in caused one of the strangest bugs we have fixed. Items in your cart would flash a "Temporarily unavailable" overlay for a moment, then recover. Nothing was unavailable. Part of the app had looked up the store, found the stand-in, read its opening status, and since the stand-in did not know whether the store was open, the check concluded it was closed. The fix was small, but the rule behind it matters more: **unknown is not the same as no.** Any code that reads a store now checks that the opening status has actually arrived before trusting it. If it has not, the app falls back to the last real answer, or simply waits. It never turns "I don't know yet" into "closed", "unavailable" or "out of range". We apply the same idea to money. A delivery fee that has not been calculated yet shows as calculating, not as zero and not as an old fee from a different restaurant. ## Rule two: refresh never tears the page down Pull to refresh is a request for *newer* content. It is not a request to watch the current content disappear. For a while, pulling down on the home screen did exactly that. The refresh cleared the banners, categories and restaurant rails first and then fetched them again. For a second or two you saw the top of the page sitting above a column of empty grey cards, as if the app had forgotten everything it knew. Now every section keeps what it has until fresh data arrives, then swaps in place. You pull, a small gap opens under the top of the page with the Laayo loader in it, and the gap stays open for at least a short moment so it never flickers. When the new data lands, it replaces the old without a blank frame in between. Two small details came from the same work: - On iPhone, the page no longer bounces past the top. The pull opens the gap instead, which feels more deliberate. - Pull to refresh looks the same everywhere in the app. We replaced every stock refresh spinner with the same round Laayo badge, so you never wonder whether a screen belongs to a different app. ## Rule three: never show something just to take it away There is a pattern we now actively hunt for: a panel appears, sits on screen for half a second, then gets replaced by the next step. It usually starts with good intentions, a confirmation like "Found your business", followed by a timer so the user can "see" it. Nobody can read something in half a second. What people actually see is a flicker, and the flow feels slower because it is literally waiting on a timer. Our rule is to ask which step the information is needed on and put it there, permanently. If a confirmation matters, it stays visible on the next screen, next to the thing it confirms. The same goes for warnings. A real warning that flashes and disappears is worse than no warning, because people notice something went wrong but cannot tell what. Warnings stay on screen as a quiet line until they no longer apply. And only an unambiguous result may move you forward on its own. If there is exactly one match, we can advance. If there are two, that is a real decision, and the screen waits for you. ## Rule four: skeletons in the right places only We do not use skeletons everywhere. For a whole page or a whole list loading for the first time, the page outline with the loader works best, because it tells you both the shape of what is coming and that something is actively happening. Inside a page that is already showing, a small section that is still loading, such as one rail of restaurants or the suggestions under the search box, gets a quiet skeleton in the shape of the cards it will become. A separate spinner for each section would make the page look broken, with half a dozen things spinning at once. A spinner on its own is reserved for buttons. When you tap Place order, the button itself shows that it is working, and the rest of the screen stays exactly as it was. ## Getting the shimmer right in dark mode Skeletons have a soft light sweep that moves across them. In dark mode, ours used to paint that sweep over the whole area, including the gaps between the cards, so a grey band slid across the background. Some placeholders also used a fixed pale grey that glowed against the dark page. Now the sweep is masked to the shapes of the placeholders, and placeholder colours are worked out from the surface they sit on, in both themes. It is a detail you only notice when it is wrong, which is exactly the kind of detail we want to get right. ## How we check it Loading bugs are hard to catch because they live for a fraction of a second. A few habits help: - **Slow it down.** We test on a throttled connection so every loading state stays on screen long enough to look at. - **Screenshot the in-between.** When reviewing a change, we capture the frames between tapping and the final screen, not just the final screen. - **Test the unhappy path.** A request that times out, a store that has no opening hours yet, a refresh that fails halfway. A loading state that only works when the network is fast is not finished. Most of these changes are already in the app, and the rest are rolling out with the next update. None of them add a feature you can point at. They just remove small moments where the app was quietly wrong, and that is most of what makes an app feel calm. --- # Dashain on Laayo, kites, dakshina and feast mode > Dashain is the biggest festival of the year in our towns. This year the Laayo app dressed up for it, with kites you can fly, dakshina envelopes on your orders and a switch that turns it all off when the festival ends. - Source: https://blog.laayo.com.np/dashain-on-laayo - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 19, 2026 - Topics: Festivals, Dashain, Customers There is a week in autumn when the whole of Birtamod and Damak changes. Schools close. Families come home from Kathmandu, from abroad, from wherever work has taken them. The sky fills with kites. Kitchens work harder than at any other time of year, and the smell of mutton curry drifts out of every second house. Dashain is the biggest festival of the year here, and this year we wanted Laayo to feel like part of it rather than just a way to order dinner. This post is about what we built for Dashain 2083, and a few things we learned along the way. ## Feast mode is ON The first thing most people saw was the home screen banner: a bright yellow card with the words **Feast mode is ON**, and two real dishes cut out against the colour. Getting there took a few attempts. Our first ideas were cartoon mascots and a dark, moody food photo. Neither felt right. What worked was simple: one bright colour, one big headline and real food. The two dishes were deliberate. One is a bowl of mutton, because for many families Dashain is unthinkable without it. The other is paneer. Plenty of our customers are vegetarian, and a festival banner that only shows meat quietly tells them the celebration is not for them. So every Dashain visual we made shows a veg dish too, with the green and red marks that people already recognise from menus. ## Kites on the home screen Flying kites, *changa*, is one of the great joys of Dashain. Rooftops are full of children and adults shouting *changa chet* as one kite cuts another loose. So we put kites in the app. On the food home screen, a small *lattai*, the wooden kite spool, sits in the corner. Tap it, and a kite flies up across the page. Kites also drift through the header at the top of the home screen. They were designed to be light and quick, and they step aside for things that matter: the kite spool moves up out of the way when you have an order on its way, and holding your finger on it hides it for the rest of your visit. And when it rains, the kites stay grounded. Nobody flies a kite in a downpour. ## Dashain dakshina During Dashain, elders give *dakshina* along with tika: a small gift of money, often in an envelope, with their blessing. We borrowed the idea. During the festival, a food order could earn a Laayo **dakshina envelope**, with a fair limit so everyone gets a turn. The envelope appears on your order screen a moment after you place the order. Open it, and you see what is inside: a coupon for a future order, free delivery, days of Laayo Plus, or money straight into your Laayo Wallet. The prize is locked until your food arrives. As soon as the order is marked delivered, the envelope unlocks, and the next time you open the app a sheet shows you what you won and how to use it. If an order is cancelled, its envelope quietly disappears, so dakshina always rewards a real meal shared, not just a tap. ![How Dashain dakshina works: place a food order, an envelope appears on the order screen, the prize unlocks when the order is delivered, and you use it on a future order.](https://blog.laayo.com.np/media/seed/dashain-dakshina.svg) ## A bonus for your wallet Many families top up their Laayo Wallet before the festival so that ordering for a full house is one tap. During Dashain, larger wallet top-ups came with a little extra from Laayo, our small dakshina to everyone feeding a crowd. ## One switch for the whole festival Festivals come and go, and the worst thing a festival theme can do is overstay its welcome. Nobody wants to see Dashain kites in the middle of Tihar. So everything festive in the app is controlled from one place, a **festival switchboard** our team can change from the admin panel. It decides which theme is on, which effects are switched on, for example the kites, the header and the special touches on the order screen, which banners belong to the festival and whether dakshina is running. It even sets the festival accent colour, a warm marigold for Dashain, which the app blends in gently. When the festival is over, a single button turns everything off at once. The app goes back to its usual yellow, the kites land, and the banners step aside. ## What we learned Building for a festival is different from building a feature. It has a hard deadline, everyone in the company has an opinion, and it only matters for a short stretch of the year. A few things stayed with us: - **Real food beats illustration.** Customers respond to dishes they could actually order. - **Include everyone.** A veg dish next to the mutton is a small thing that says a lot. - **Reward the meal, not the tap.** Tying dakshina to delivered orders kept it fair. - **Make it easy to switch off.** A festival that ends cleanly is part of doing it well. From all of us at Laayo, *Shubha Dashain*. We hope your plates were full, your kites flew high, and your rider got there before the curry went cold. --- # Open, closed, or somewhere in between > "Is this restaurant open?" sounds like a yes or no question. In a delivery app it has at least five answers. These are the rules we use so every screen gives the same, honest one. - Source: https://blog.laayo.com.np/store-open-or-closed-the-truth - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 18, 2026 - Topics: Restaurants, UX, Notifications, Reliability Ask a customer what "closed" means and they will tell you: I can't order from there right now. Ask the system and you get a longer list. A restaurant can be outside its opening hours. It can be inside its hours but paused by the owner because the kitchen is swamped. And every restaurant in a town can be paused at once by our operations team. And a restaurant can be perfectly open but not delivering to *your* address at this hour. Each of those used to be handled a little differently on different screens. The result was the worst kind of bug: not a crash, but an app that contradicts itself. A restaurant that shows up as recommended, then turns out to be closed when you tap it. A menu that vanishes entirely because the kitchen paused for twenty minutes. This post describes the rules we settled on. The plumbing that pushes open and close changes to phones in real time is covered in part three of our tech stack series; this is about what the app should *say* once it knows. ![What a customer sees for each kind of closed: home only lists restaurants that can deliver to you right now, a closed restaurant's menu stays readable with ordering switched off, and Notify me sends one message when it opens.](https://blog.laayo.com.np/media/seed/open-closed.svg) ## Rule one: closed means "can't order", not "doesn't exist" Early this year, a partner paused their restaurant for a short while and something strange happened: menu items disappeared everywhere. Customers opening any restaurant saw "No items available right now", even restaurants with dozens of dishes. The cause was a filter that hid items whenever restaurants were paused, applied far more broadly than intended. The deeper problem was the idea behind it. Hiding the menu treats "closed" as "gone". But a customer browsing a closed restaurant is often planning dinner, checking a price, or deciding whether to schedule an order. So the rule is now explicit for all three kinds of closed (outside hours, paused by the partner, or everything paused by us): - **The menu stays visible.** You can scroll, read and look at photos. - **Ordering is switched off.** The Add buttons are disabled and a clear banner above the menu says the restaurant is closed. - **Placing an order is blocked on the server too.** The app's disabled button is a courtesy. The real gate is the order endpoint, which refuses an order for a closed restaurant no matter what the app shows. That last point is what makes the first two safe. Because the server enforces it, the app is free to show menus generously. ## Rule two: home only shows what you can order now The home screen is the opposite case. It is a list of suggestions, and suggesting something you cannot order is worse than suggesting nothing. So the home rails, such as Recommended, Popular, Top offers and Visit again, are strict: a closed restaurant or an unavailable dish never appears on them. We had an old exception that relaxed this when every restaurant seemed to be paused, meant for the rare all-paused case. In practice it leaked into ordinary evenings when a few restaurants were closed, and closed cards started appearing in Recommended. We removed it. When every restaurant near you is genuinely closed, home does not pad the page with grey cards. It shows a short, honest empty state that kitchens are taking a break. We think that is more respectful of your time than a page full of things you cannot order. ## Rule three: open is not the same as delivering to you Some restaurants deliver to a smaller area late at night than during the day. Late at night a restaurant can be open, cooking and taking orders, yet not delivering to your street. We used to count those restaurants under "restaurants delivering to you" because they were open, while their own card said "Out of delivery area". The list and the card disagreed. Now "delivering to you" means open *and* covering your address right now. Restaurants that are open but outside your area at this hour move to a separate "not delivering right now" group, listed ahead of the ones that are closed, because they are the closest to being available. ## Rule four: when you want it, tell me when it opens A closed restaurant page used to be a dead end. Now the bottom bar, where the cart button normally sits, offers two actions: - **Schedule for later.** If the restaurant accepts scheduled orders, you can pick a time slot right there. If it does not, the button stays visible but dimmed, so the option is never mysteriously missing. - **Notify me.** Tap it and we send you one notification when the restaurant opens, which takes you straight back to its page. Notify me sounds simple, but "exactly one notification" took some care. A restaurant can open in several ways: its scheduled opening time arrives, the partner taps reopen after a pause, a timed pause runs out on its own, or our team lifts a city-wide pause. We handle these through two paths: 1. **Instant.** When a partner reopens from their app, a job runs right after their request completes and notifies everyone waiting. 2. **Backstop.** A small task regularly checks for anyone still waiting on a restaurant that is now open. This covers scheduled openings and timed pauses, which have no button press to react to. When nobody is waiting, it finishes almost instantly. Both paths can race. To make sure nobody gets two messages, each waiting request is *claimed* in a single database update before its notification is sent. Whichever path claims it first sends it; the other finds nothing left to send. Nothing is sent while a city-wide pause is on, and tapping Notify me again later re-arms it. ## Rule five: a fee you are not sure about is not a fee The last rule is about the delivery fee shown at the top of a restaurant page. Customers told us that if they opened one restaurant, went to another and came back, the fee sometimes sat on "Calculating" forever. There were two causes. First, the app kept only one live fee quote at a time, shared across restaurant pages. Opening a second restaurant replaced the first restaurant's quote, and nothing asked for it again when you came back. Second, when a quote failed, because of a timeout or a busy moment on the network, the app remembered that it had already asked and never tried again. The fix: - **Remember the last good fee per restaurant**, valid for the same delivery address and for a limited time. Coming back to a restaurant shows its fee immediately. - **Retry a failed quote** a couple of times, a few seconds apart, and only for the page you are still looking at. - **If it still fails, show the delivery time without a fee** rather than a spinner that never ends. Checkout always calculates the final fee before you pay. These changes are rolling out with the next app update. ## The common thread All five rules come from one principle: **every screen should give the same answer, and the answer should be what the customer can actually do.** Can I see it? Can I order it? Will it come to me? When will it open? How much will delivery cost? When the answer is "not right now", we say so plainly, show what we can, and give you a next step. That turns out to matter more than any single feature on the restaurant page. --- # Laayo's tech stack, part three: realtime > Order status, chat, rider positions and store open or close now reach phones in a fraction of a second. Here is the Go hub behind it and the fallbacks that keep it honest. - Source: https://blog.laayo.com.np/tech-stack-part-three-realtime - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 18, 2026 - Topics: Go, WebSockets, Realtime, Redis A delivery app is a realtime app pretending to be a shopping app. The moment you place an order, everything that matters is live: has the restaurant accepted it, has a rider picked it up, where are they now, did they send a message? For a long time, most of that reached your phone by polling: the app asked the server every few seconds whether anything had changed. Polling is simple and robust, and we still keep it as a fallback. But it is slow to notice changes, wasteful when nothing has changed, and expensive at dinner time when every open app is asking at once. Our goal is that order status, a rider's pin and a new order on a partner's tablet show up in well under a second, and that a store opening or closing is visible in the app within moments. This post is about how we got there. ![Realtime, one hub with many channels: Laravel publishes events after the database commit, storelive publishes store changes, rider GPS flows through the live Redis, and one Go hub fans everything out to order, store, rider, chat and zone channels.](https://blog.laayo.com.np/media/seed/tech-stack-realtime-overview.svg) ## Why we replaced our WebSocket server Our apps already spoke the **Pusher protocol**, a simple and widely supported WebSocket protocol for publishing events to named channels. On the server side, that protocol was handled by a PHP package running as several processes behind a load balancer. That setup had two problems. The package had been abandoned upstream, which blocked us from upgrading Laravel. And it had a quieter bug: each PHP process kept its own list of who was subscribed to which channel, but the server published each event to only one of the processes. With several processes, an event reached only some of the people listening. Chat and the support desk mostly worked because they also polled, which hid the problem. We replaced it with **one Go process** that speaks the same protocol, frame for frame. Because the frames are identical, no app update was needed. We built a checker that runs the full protocol end to end, from connecting and subscribing through pings, publishing and rider location frames, and ran it against both servers until they matched. Then we pointed the load balancer at Go, kept the old processes ready for a day as a rollback, and retired them. One process holding every subscription fixes the missed-subscriber bug by design. Go handles large numbers of idle connections cheaply, so a single process is plenty for our scale, and it is easy to reason about. ## Events after the commit The Laravel side publishes events whenever something meaningful changes. The most important is `OrderStatusChanged`. It fires when an order's status or assigned rider changes, and only **after** the database transaction commits. Publishing before the commit is a classic bug: the app gets the event, fetches the order, and sees the old status because the write has not landed yet. Each event goes to every channel that cares about it: - the **order** channel, for the customer watching that order, - the **store** channel, so a new order rings on the partner's device, - the **rider** channel, including the previous rider if an order is reassigned. Laravel used to publish events through the public internet and back in to our own server, which added a noticeable delay to every event. It now publishes to the Go hub directly, which is many times faster. Channel names are signed. Instead of a guessable name built from an order number, each channel name carries a short signature generated on the server. The server hands the right name to the app that is allowed to listen, and nobody can subscribe to someone else's order by counting upward. ## Store open and close in a fraction of a second A complaint we heard from partners: "I closed my store, but customers could still see it as open." The cause was not one bug but a stack of caches, each reasonable on its own: store lists cached for a while, search cached for longer, saved copies from part two, and apps that only refreshed when you reopened them. Scheduled opening and closing was worse, because a store crossing its closing time changes no row in the database at all. We built **storelive**, a small Go service whose only job is to know which stores are open right now, and to say so the moment that changes. ![Closing a store end to end: the partner taps close, Laravel saves and bumps the zone version, storelive reads the new open state, publishes stores.changed on the zone channel a fraction of a second later, and the app updates its lists in place.](https://blog.laayo.com.np/media/seed/tech-stack-storelive-timeline.svg) - When a store, its schedule or its settings change in Laravel, the zone's **store version** goes up and every cached list for that zone is dropped. Laravel also sends storelive a notice. - storelive works out the effective open state with the same rules the API uses, including schedules, temporary closes and city-wide closes. It checks on a short interval, wakes immediately on a notice, and also wakes exactly at the next opening or closing time in the zone. - On any change it publishes `stores.changed` on the zone's channel, listing which stores changed and whether they are now open. On our tests environment the event reached a phone on the public internet a fraction of a second after the partner saved, and scheduled closes landed right on time. City-wide closes are sent once more shortly afterwards as a safety net, and apps still refresh when they come back to the foreground, in case a socket was asleep. The server side is live, and the app side reaches phones with the next customer app release. The same path now carries offers. When menuwatch from part two sees a discount or coupon change, storelive pushes it out, so a new offer shows up as soon as it starts. ## Rider positions Live tracking is the most demanding realtime feature we have, because data flows in constantly, not just when something changes. Riders send their position every few seconds, over a WebSocket where possible and over plain HTTP otherwise. Both paths now land in Go, which checks the rider's token, acknowledges the update and does three things with the newest point: 1. **Redis GEO index.** Each zone has a geospatial index of online riders, plus a freshness score per rider. Questions like "which riders are near this restaurant" become one fast Redis query instead of a scan of a database table. Riders who stop reporting fall out of the index on their own. 2. **Last known point.** A small record per rider keeps the latest position, so every screen that asks "where is this rider" sees the newest point without touching the database. 3. **Fan out.** The point is published to the customers tracking that rider's order, who see the pin move. The database still gets the position, but far less often than on every ping. Readers that load a rider from the database get the fresher Redis point laid over the stored one automatically, so the many places in the code that read rider positions got fresher data without a single change. ## Apps: realtime with a seatbelt On the phone, the native customer app has one shared realtime client, written once in Swift and once in Kotlin with the same design. Screens subscribe to channels and get events. The client handles everything else: - **Shared connections.** If the tracking screen and the chat both need the same order channel, they share one subscription, counted by reference and closed when the last screen leaves. - **Heartbeats.** Regular pings, and a connection that has been silent for too long is treated as dead and replaced. - **Backoff.** Reconnects wait a little longer after each failed try, so a server restart does not cause a stampede. - **Resubscribe and catch up.** After a reconnect, screens are told so they can fetch anything they might have missed. Polling has not gone away. It runs more slowly as a safety net. Realtime makes the app fast, and polling makes sure it is never wrong for long. When an event arrives, the app usually fetches the fresh order rather than trusting the event alone, so the event says "something changed" and the API stays the source of truth. ## What's next The next step is moving order events onto Redis Streams, so dispatch and notifications can be driven by a durable log of what happened instead of each feature reacting on its own. That work is planned and we will write about it when it is live. In part four we move to the phone itself: why we rebuilt the customer app in native Swift and Kotlin, and how we did it without logging anyone out. *This is part three of our series on Laayo's tech stack.* --- # Why we ask you to type a cancel reason > A list of preset reasons is easy to tap and almost useless to read. We replaced it with one honest question, and a gentle check that keeps "aaaa" out. - Source: https://blog.laayo.com.np/why-we-ask-you-to-type-a-cancel-reason - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: October 17, 2026 - Topics: Orders, Cancellations, Riders, UX Nobody likes cancelling an order. If you are doing it, something went wrong: the wait got too long, you ordered from the wrong address, plans changed, or the restaurant called to say an item was out. Whatever it was, it is the single most useful thing you can tell us, because it points straight at what we need to fix. For a long time, we asked in the least useful way possible. ## The trouble with presets When you cancelled an order, the app showed a short list of reasons with round buttons next to them. Pick one, tap Cancel, done. It looked tidy. It produced tidy charts. And the charts were mostly fiction. When people are in a hurry, they tap the first option that is close enough, or simply the first option. A list of three or four choices cannot hold "the restaurant said the chicken is finished, so I'll order later" or "I put the wrong landmark and the rider can't find the lane". Those end up as "Other", or worse, as whichever reason sat at the top of the list. We saw the same thing on the rider side first. Riders cancelling an order picked from a list that included things like "insufficient fuel" and "customer refused the order". When we looked closely, the reasons did not match what had really happened. The list made it easy to give an answer and hard to give the true one. ## One question instead of a list We changed the rider app first. To cancel an order, a rider now types a short reason in their own words. "Bike puncture near Dhulabari chowk" tells our operations team far more than a radio button ever did, and it reaches every screen they use to review that order. Our next customer app update does the same for you. The cancel sheet asks one question: > Why do you want to cancel? There is a text box, a Cancel order button and a Keep order button. That is all. It is the same sheet whether you cancel from the live tracking screen or from the order details page, on iPhone and on Android. ## Keeping "aaaa" out, politely A free text box has an obvious weakness. If someone just wants to get through the screen, they will type "hhh" or "jjjj" or mash the keyboard. That is no better than a random preset. So the app checks the reason before it is sent. It is not trying to judge your reason, only to make sure it is a real sentence. A reason is turned away if it: - has no letters at all, - is mostly the same letter repeated, - is the same word over and over, - is a run of keys from one keyboard row, like "asdf" or "qwerty", - is a single word, or too short to say anything. Reasons written in Nepali are welcome and skip the checks that only make sense for English letters. We tried hard to make the check feel calm rather than strict. While you are typing a short reason, the app shows a quiet hint with how many more characters are needed. It only shows an error if what you typed looks like keyboard mashing, and only after you pause for a moment, so it does not flash red at you mid-word. If you tap Cancel order with a reason that is too short, the box gives a small shake and tells you what is missing. And one rule we did not bend: **Keep order is never blocked.** You can always change your mind and keep your food. ## Why we did not make the server strict You might expect the server to reject short reasons too. We decided not to. Older versions of the app still send preset reasons, and some of those are short. If the server suddenly demanded a long typed reason, people on an older app would be unable to cancel at all, which is much worse than a short reason. The check lives in the app, and everyone gets it as they update. ## What we lose, and why it is fine Free text is harder to count than a list of five buttons. Some of our internal charts that grouped cancellations by reason are messier now. That is a trade we made on purpose. Our main view of cancelled orders already groups them by *who* cancelled and *when*, which does not depend on the reason text at all. The typed reasons sit on top of that, one order at a time, and they are true. A tidy chart of guesses was never going to help us make deliveries faster or restaurants more reliable. One honest sentence per order will. ## What happens to your reason Your reason is attached to the order and read by our support and operations team. When the same kind of reason keeps appearing for a restaurant, an area or a time of day, that is where we look first. If something went wrong on our side, the reason is also what lets support follow up with you properly instead of guessing. So the next time you cancel, and we hope it is rare, a sentence or two is all we ask. We do read them. --- # How Laayo uses AI, and the rules we keep > Where artificial intelligence helps at Laayo, from support chat to menus, notifications and ratings, and the guardrails that keep people in charge. - Source: https://blog.laayo.com.np/how-laayo-uses-ai - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 16, 2026 - Topics: AI, Support, Product, Privacy Laayo is a food and grocery delivery app in Birtamod and Damak, Jhapa, run by Laayo Services Pvt. Ltd. Like many teams, we use AI where it saves people time. Unlike the hype, we use it in a few specific places, with clear rules about what it may and may not do. This post is the overview; each section links to the full story. ![Where AI helps at Laayo: support chat, menus, notifications and ratings, each with a person or a hard rule in charge of the final step.](https://blog.laayo.com.np/media/seed/laayo-ai-map.svg) ## Support chat: an assistant that knows when to hand over When you open support chat in the Laayo app, an AI assistant answers first. It can explain where an order is, how refunds work, how to change an address and most of the everyday questions people ask. It understands English, romanized Nepali and Nepali script, and replies in the language your app is set to, or in the language you write in. The most important thing it does is **know its limits**. When a chat needs a person, such as a refund dispute, an item it cannot verify or a customer who simply asks for a human, the assistant hands the chat to our support team for real, with a short brief so the person who picks it up does not have to ask everything again. It never pretends that help is on the way when it is not. The full story is in [The support assistant that knows when to hand over](https://blog.laayo.com.np/support-assistant-that-knows-when-to-hand-over). ## Menus: from a photo to a digital menu Typing a restaurant's whole menu by hand is slow and full of mistakes. When a new partner joins, our team can take a photo or PDF of the printed menu and let AI read the dish names, sizes and prices into a table. **A person checks every line** before the menu goes live, and the restaurant sees it before customers do. AI also suggests short descriptions for dishes, which the team can edit or throw away. We do not use AI to generate food photos; a dish on Laayo looks like the real dish. See [A menu from a photo](https://blog.laayo.com.np/a-menu-from-a-photo). ## Notifications: words from AI, facts from our system Some Laayo notifications, such as a reminder about a dish you might like, are written with the help of AI. The split of work is strict: - **Our own code picks the facts**: a real dish, from a real restaurant, that is open and delivering to you. - **AI only writes the words** around those facts, in a friendly and short way. - **AI may not invent anything**: no made-up discounts, no prices that do not exist, no promises about delivery times. - Messages respect the time of day, and campaigns are limited so your phone is not buzzing all day. More in [Notifications that are worth opening](https://blog.laayo.com.np/notifications-that-are-worth-opening). ## Ratings: a score that fits your taste Next to a restaurant's overall rating, Laayo can show a **"for you" rating**, tuned to what you tend to enjoy. It learns from signals like your reviews and the places you order from again. You can switch between "For you" and "Overall" at any time, and the overall rating is never hidden. See [Ratings that mean something](https://blog.laayo.com.np/ratings-that-mean-something). ## The rules we keep Across all of these, a few rules do not change: 1. **People stay in charge of anything that matters.** Refunds, account changes, menus that go live and anything to do with money are decided or checked by a person, or by our own system following fixed rules. 2. **AI does not invent facts.** Prices, discounts, delivery times and order details come from Laayo's own data, never from a model's imagination. 3. **Always a way to a human.** In support, asking for a person always works. 4. **Privacy first.** We send AI only what a task needs. Payment details are never part of it, and personal details are kept out wherever the task allows. 5. **No fake images.** Food photos on Laayo come from restaurants, not from image generators. 6. **We measure outcomes, not hype.** In support, what matters is whether your problem was solved and how quickly a person joined when needed, not how many chats AI handled alone. ## Where AI is not used Some things at Laayo deliberately do not use AI. Payments, payouts to restaurants and riders, refunds and the price you pay are calculated by our own system with fixed rules that can be checked line by line. Dispatch decisions follow clear rules too. These are areas where being predictable matters more than being clever. ## Quick answers ### Does Laayo use AI in customer support? Yes. An AI assistant answers support chats first and hands the chat to a person on Laayo's support team when needed, or whenever you ask for a human. ### Can Laayo's AI give me a discount or a refund? No. The assistant can explain how refunds and offers work, but refunds are handled by Laayo's system and support team, and AI never invents discounts. ### Are the food photos on Laayo made by AI? No. Food photos come from restaurant partners. Laayo does not use AI to generate dish photos. ### Does AI choose what I see in notifications? Laayo's own system picks real dishes and restaurants that are open for you. AI only helps write the message, and it may not add discounts or claims. ### Can I talk to a real person at Laayo? Yes. Ask for a human in support chat, email support@laayo.com.np or call 9707055875. --- # Getting paid, and knowing you have been paid > For a restaurant, a payout is only real when the money is in the account and the owner knows why it is that amount. How we tell partners about every payout by text, email, a clear statement and a quick phone call. - Source: https://blog.laayo.com.np/getting-paid-on-time-as-a-partner - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 16, 2026 - Topics: Partners, Payouts, Restaurants When a restaurant joins Laayo, it trusts us with something important: the money its customers pay for its food. Customers pay us by cash at the door or by E-Payment, and we pass the restaurant's share on to them. How well we do that, and how clearly we explain it, decides whether a partner stays with us for years or quietly drifts away. This year we rebuilt the way partners hear about their payouts. The money was always being sent. What was missing was the feeling of certainty that it had arrived, and an easy way to understand the amount. ## How payouts work On a regular schedule, the orders a restaurant has completed are gathered into a payout. Each payout is a list of orders with, for each one, the food value, any discount the restaurant chose to fund, the commission and what the restaurant receives. Partners choose how they want to be paid when they sign up: a bank transfer to their account, a Fonepay QR, or in some cases cash handed over by our team. Whichever way it goes, the moment a payout is marked as paid, the restaurant hears about it. ![The journey of a payout: orders are gathered into a payout, money is sent, then the partner gets a text, an email with the statement and a confirmation call, with a ticket raised if anything is wrong.](https://blog.laayo.com.np/media/seed/payout-journey.svg) ## A text that reads like good news The first thing a partner gets is a text message. We rewrote it more than once, because the first version read like a bill. Owners would see "Laayo" and an amount and assume they owed us money. The message now starts with the words that matter: **PAYMENT SENT**. It says that Laayo has paid the restaurant for its Laayo orders, how much, and the payout number they can match in the partner app. If more payouts are still on their way, it says how much is pending. And it ends with a short link to the full details. A few details we were careful about: - **Everyone who needs to know, hears.** The text goes to every number linked to the restaurant: the owner, the shop line, the preferred contact and active staff. Duplicates are removed, so nobody gets the same text twice. - **One message for a batch.** When several payouts are sent at once, the restaurant gets one text with the total, not a pile of separate ones. - **It keeps trying.** If a text does not go through, it is retried automatically for a while, so a busy network on payout day does not mean a partner never hears. - **Partners can opt out.** Some restaurants prefer not to get these messages. They can turn them off, and we respect that. ## A statement anyone can read Accountants love a ledger. Restaurant owners in Birtamod, understandably, mostly do not. Our first statement was accurate and complete, and almost nobody outside our finance team could follow it. So the link in the text now opens a statement that looks like an invoice from the customer app. It shows: - the restaurant's name, address and PAN, - the payout number and date, in both the Gregorian and Bikram Sambat calendars, - how it was paid, - a simple table: each order, its value, any discount, the commission, and the column partners care about most, **You get**. Every statement carries a QR code. Scan it, and our verification page confirms that the document really came from Laayo. That matters when a partner hands a statement to their own accountant or a bank. The same statement is also sent by email as a PDF, so partners who keep their records on a computer have a copy without asking. For partners who do want every detail, our team can produce a **full statement** covering many payouts at once: the money trail from the menu price down to the amount transferred, a summary of items sold and every order with its line items. ## A call to make sure A text can be missed. An email can sit unread. And sometimes, rarely, a bank transfer takes longer than it should. We did not want a partner to discover a missing payment much later, after it had already become a worry. So after the text goes out, the restaurant also gets a short automated call. In Nepali, it tells them the amount that has been paid and asks a simple question: - **Press 1** if you have received it. - **Press 2** if you have not. If the owner presses 2, a support ticket is raised straight away, our team is alerted, and the call is put through to someone who can help. If the owner is busy and cannot check right now, they can simply call Laayo back later, and the same question is waiting for them. We learned one small lesson building this. The call reads the amount out loud, and the first version read numbers digit by digit, which sounded strange. Amounts are now spoken as words, the way a person would say them. ## What we hope partners feel None of these pieces are complicated on their own. A text, an email, a readable statement, a short call. Together they change how a payout feels: from "I think the money came, I should check" to "I know it came, and I know why it is that amount". If you are a Laayo partner and anything about a payout does not look right, do not wait. Raise a ticket in the partner app as soon as you notice, or press 2 when we call. We would always rather fix it early. --- # Support calls that reach a human, faster > We run our own phone line for customers, riders and partners. When we timed it, too many callers hung up before any phone rang. Here is how we cut the dead air. - Source: https://blog.laayo.com.np/support-calls-that-reach-a-human - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 16, 2026 - Topics: Support, Telephony, Realtime Most of our support happens in chat. But when food is late, a rider cannot find a house, or a restaurant has a problem with an order that is already cooking, people want to talk to someone. In the towns we serve, a phone call is still the most natural way to ask for help. So Laayo has one public support number for everyone: customers, riders and restaurant partners. Behind it is our own phone system, connected to our backend. This post is about what happens when you call it, what we learned when we measured it, and how we made it reach a human sooner. ## What happens when you call A support call moves through a few stages: 1. **A short greeting in Nepali.** It tells you that you have reached Laayo and that calls are recorded to improve service. 2. **A simple menu where needed.** Restaurant partners can press a key to reach the team that handles partner issues. Keypad tones are passed through reliably again, so menus are back on the table. 3. **Ringing the team.** The call rings our support staff first inside our Admin App, where they can answer over the internet with one tap, and then on their regular phones. 4. **Joining.** When a team member picks up, they hear a short cue so they know it is a Laayo call, and you hear a message telling you someone has joined. Our backend knows about every call. It knows who called, whether they are a known customer or partner, which orders they have open, who answered and for how long. Recordings are stored so a manager can listen back when something went wrong, and they are converted into a compact format that plays instantly on phones. ![A support call from first ring to a human, before and after we removed the waits](https://blog.laayo.com.np/media/seed/support-call-flow.svg) ## Timing the dead air The system worked, but it felt slow. So we pulled the timing of every recent call out of our logs and lined up what the caller heard against what our team's phones were doing. The results were humbling. Callers waited far too long before talking to anyone, and too many hung up before a single phone on our side had even started ringing. The waits were all individually reasonable: - A short pause before the greeting, then the greeting and the recording notice. - A transfer message, a short logo sound and a queue position announcement, even when there was nobody else in the queue. - Then the Admin App was given a head start to be answered before regular phones started ringing. Put together, the first phone on our side started ringing long after the caller dialled. From the caller's point of view, that is a long time to listen to recordings when your food is late. ## Ringing while we talk The biggest change was to stop waiting for the greeting to finish before we start looking for a person. The support team's apps now start ringing as soon as the call arrives, while the caller is still hearing the greeting. If someone answers early, the greeting finishes its current sentence and the caller is connected straight away, instead of sitting through the rest of the recordings. That last detail mattered. Our first version connected the call the instant a team member tapped answer, which cut the greeting off in the middle of a word. It was faster, but it sounded broken. Now the system waits for a natural break: the end of the current prompt. We also removed announcements that carried no information. A queue position message is useful when you are third in line. When you are first and only, it is just more waiting. Those prompts now play only when there is a real queue. ## When the app says yes but nothing happens Answering in the app exposed a different kind of problem. A team member would tap answer, the screen would say "connecting", and then "could not connect". We traced one of these to our own backend. When an app answers, the phone system asks our server to confirm who picked up, and it waits only briefly for the reply. During busy periods, the server was busy with rider location updates and app polling, and the confirmation arrived too late. The phone system gave up and dropped the app's leg of the call. We gave call handling more headroom on the server so these confirmations are answered quickly even at peak. Another case was on the phone itself: the app opened its connection to the phone system and then stalled while setting up audio, long enough for the connection to time out. Those fixes live in the Admin App and are rolling out with its next build. ## Not counting voicemail as an answer When a call rings a team member's regular phone, it can be "answered" by their voicemail. Early on, the system treated that as a successful answer and connected the caller to a voicemail greeting. Now, when a phone picks up, the system plays a short cue and listens for a moment. A human saying hello is connected. A long recorded greeting is treated as voicemail, that phone is skipped, and the next person is tried. We also learned to never leave a team member in silence while the system listens: an answering person who hears nothing says hello a few times and hangs up, which is exactly what we were trying to avoid. If nobody can take the call, it is not lost. A missed call becomes a callback task for the team, attached to the caller and their orders. ## Passing a call along Sometimes the first person who answers is not the right one. A team member can press a short key combination during the call to transfer it to a manager. The caller hears that they are being transferred, and the manager hears who is calling before they are connected. If the manager does not pick up, the call goes back into the normal flow instead of ending. ## What's next We are tracking time to a human for every call, and the next step is to make it visible to the whole team on the operations dashboard. We also want the person who answers to see the caller's open order on screen before they say hello, so the first sentence of every call can be "I can see your order" instead of "Can I have your phone number?" --- # Rider safety at Laayo, what we do and what we ask > Riders are on the road in rain, at night and in traffic. How Laayo builds safety into the rider app, how riders can report problems, and what we ask of everyone on the road. - Source: https://blog.laayo.com.np/rider-safety-at-laayo - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 15, 2026 - Topics: Riders, Safety, Guides No order is worth an accident. That sentence sits behind a lot of small decisions in the Laayo rider app and in how our team works with riders. This guide puts them in one place, for riders, their families and anyone who wants to know how we think about safety. ## Who is riding? Safety starts with knowing who is on the bike. - **A person reviews every rider.** Nobody rides for Laayo straight from a form. Our team checks documents and talks to every applicant. See [becoming a Laayo rider](https://blog.laayo.com.np/becoming-a-laayo-rider). - **Daily selfie.** Freelance riders confirm who they are with a quick selfie at the start of each day before going online. - **ID in the app.** Riders carry their Laayo ID and licence details in the app, ready to show at a checkpoint without digging for papers. - **Emergency contact.** Every rider gives us an emergency contact when they join, so we know who to call if something happens. ## How does Laayo handle bad weather? When it rains hard, riders can switch on **rain mode** for their zone from the app. Customers then see that it is raining and that deliveries may take a little longer, and delivery time estimates account for the weather. The goal is simple: no rider should feel pushed to ride fast on a wet road. More in [riding through the monsoon](https://blog.laayo.com.np/riding-through-the-monsoon). ## Does the app distract riders while riding? We work hard to make sure it does not. - **Spoken prompts** in natural Nepali explain key steps, such as when to pick up an order, so riders do not have to read long instructions. - **Automatic progress.** Arrival at the restaurant and at the customer is picked up from location, so riders do not need to tap while moving. - **Calm design.** Large buttons, clear cards and no unnecessary pop ups. Our rule for riders is the same as for anyone on the road: **stop before using your phone.** ## What about handovers at the door? Handovers should be quick and calm. The app gives riders the customer's landmark, notes, and call and chat buttons. We are rolling out an arrival message: when a rider reaches the door, the customer is told once and can answer "Coming", "Give me a moment" or "Call me", so riders are not left waiting outside without knowing what is happening. ## Can riders rate customers and handovers? Yes. Customers rate riders, and riders can rate the handover too, using simple tags such as a hard-to-find address or a long wait. That helps us spot addresses and situations that need fixing. See [reviews for riders too](https://blog.laayo.com.np/reviews-for-riders-too). ## How do riders report a problem? - **During an order:** chat or call through the order, or call Laayo support from the app. - **Afterwards:** raise a **grievance** in the app. It becomes a conversation with our team with a clear status, and riders can attach a photo. - **Disputing a deduction:** open it in the app and tap to dispute it. It goes into the same grievance thread. Every report is read by a person. ## What benefits support riders? Our team can set up benefits, such as insurance details, that riders can see in the app, including what is covered and how to claim. Benefits depend on the rider's arrangement with Laayo and are explained when a rider joins. ## What do we ask of riders? - Wear a helmet, every ride. - Follow traffic rules, even when an order is running late. - Stop before using the phone. - Use rain mode when the weather turns, and take shelter when it is unsafe. - Tell us about anything that felt unsafe, so we can fix it for everyone. ## Quick answers ### Does Laayo check who its riders are? Yes. A person reviews every rider before they start, and freelance riders confirm their identity with a selfie each day. ### What happens when it rains? Riders can switch on rain mode for their zone, customers are told to expect a little longer, and estimates account for the weather. ### How can a rider report a problem? Through the order chat, by calling Laayo support, or by raising a grievance in the rider app. ### Can riders rate customers? Riders can rate the handover with simple tags, which helps us fix hard-to-find addresses and other problems. ### Do riders have to use the phone while riding? No. Loud order alarms, spoken prompts and automatic location updates are there so riders can keep their eyes on the road. We ask riders to stop before using the phone. --- # Laayo's tech stack, part two: Go on the hot path > How we moved the busiest API calls from Laravel to Go one endpoint at a time, by running Go in the shadow first and comparing every answer before letting it serve. - Source: https://blog.laayo.com.np/tech-stack-part-two-go-hot-path - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 15, 2026 - Topics: Go, Performance, Laravel, Caching In part one we said the hardest thing to move in our Laravel backend is its fixed cost: the start-up price every API call pays before any real work starts. For an admin page that is fine. For a customer opening the app, which makes many calls as it starts, it adds up to a home screen that feels slow even when every query is fast. We wanted the speed of the best delivery apps in the world, with fast API responses even for the slowest requests and an app that feels open almost instantly. Rewriting thousands of routes is not a plan. Instead we did what is sometimes called a strangler migration: put a Go service in front of the busiest paths, move them across one at a time, and leave Laravel in charge of everything else. ## Rank by traffic, not by interest The first step was boring and important. We counted requests per route across our logs and sorted them. The list was not what we would have guessed. The busiest endpoint by far was **rider location updates**. Every online rider reports their position every few seconds for their whole shift. After that came small configuration and health calls that apps poll in the background, partner notification checks, and the lists of current orders that rider and partner apps refresh constantly. None of these are glamorous, but each one paid the full Laravel start-up cost for a few milliseconds of work. Porting even trivial endpoints removed that start-up cost from every call, and because they were simple, they were safe first candidates. The admin and partner web panels stay in Laravel for good. They are not on the customer's critical path, and they hold the most business rules. ## One endpoint, three modes Each Go endpoint is a small unit: how to match a request, how to answer it, and what differences are acceptable. On top of that sits a mode, set per endpoint in a config file that the Go service re-reads regularly. ![One endpoint, three modes: off sends the request to Laravel, shadow lets Laravel answer while Go computes the same response and compares, serve lets Go answer with Laravel as the fallback for anything unported or any error.](https://blog.laayo.com.np/media/seed/tech-stack-go-modes.svg) - **Off.** Go ignores the endpoint. Laravel answers. - **Shadow.** Laravel still answers the customer. In the background, Go computes its own answer to the same request and compares status and body byte for byte. Mismatches are saved for us to inspect. - **Serve.** Go answers. If anything goes wrong, Go hands the request back to Laravel. Shadow mode is the heart of the approach. It lets us test a port against real production traffic, with real data and real edge cases, while customers keep getting the proven answer. An endpoint only moves to serve when shadow shows it matching. For example, two rider payout endpoints matched on every shadowed request and answered many times faster in Go than in Laravel. They went to serve the same morning. Rolling back is a one-word change in the config file. No deploy, no restart. The service picks it up within moments. ## Matching PHP byte for byte "Byte for byte" is harder than it sounds when two languages encode JSON differently. A few things we had to get right: - **Key order.** PHP keeps object keys in insertion order. Go maps sort them. We built a small ordered-object type so Go emits keys in exactly the order Laravel does. - **Escaping.** Go escapes `&`, `<` and `>` in JSON by default. PHP does not. We turn that off. - **Numbers.** PHP prints floats in its own way. Go has a helper that prints them the same way, so a price or a coordinate looks identical. - **Dates.** Laravel formats some dates in UTC with a fixed pattern and others through model accessors. Each has a matching helper in Go. Where an exact match is impossible, the endpoint can declare a tolerance. Distances calculated with slightly different maths libraries differ far down in the decimals, and an age-in-seconds field changes between the two calls. Those are accepted explicitly, field by field, rather than by loosening the comparison for everything. ## Fall back, never fail The Go service only handles the happy path it has been taught. Anything else, like a missing or invalid token or a validation error, is handed back to Laravel so the error the app sees is exactly the one it always saw. There is also a safety net below the Go service. nginx sends native paths to Go, and if Go is unreachable or returns a gateway error, nginx retries the request against Laravel. We tested this by stopping the Go service on our tests environment in the middle of traffic. Apps kept working, just at Laravel speed. Go also connects to the database with a read-only account, apart from a couple of narrowly scoped writes like rider positions. A bug in a Go handler can show wrong data, which shadow mode is designed to catch, but it cannot change orders or money. ## Computing versus copying Some endpoints are easy to port because their logic is small. Others, like the store page and menu, carry years of rules about discounts, add-ons, schedules, translations and stock. Porting those in one step would be exactly the risky rewrite we wanted to avoid. For those we use **saved copies**: Laravel renders the response as usual, saves it in the cache Redis, and Go serves the saved copy to the next request with the same key. ![Saved copies that stay correct: Laravel renders and saves a copy keyed by the request and scope versions, Go serves it on the next request, and a watcher fingerprints the database and drops copies when anything they depend on changes.](https://blog.laayo.com.np/media/seed/tech-stack-go-copies.svg) The key includes everything that changes the answer: the path and query, zone, module, language and a rounded location. It also includes **scope versions**: small counters for config, catalog and offers. When something changes in a scope, its counter goes up and every copy built on the old version simply stops matching. For store lists on the home screen, Go goes one step further. It takes Laravel's saved list and applies the parts that depend on you: which stores deliver to your exact pin, using the same polygon check as Laravel, and the distance sort. We verified a wide range of request variants on tests and production. Every one matched, apart from float noise in distances, and public response times for those lists dropped sharply. We also added a combined home bundle. Instead of the app making separate calls for popular, latest, recommended and the other home sections, it makes one, and Go fills each part through the same handlers. Each part is identical to the single endpoint. The bundle is several times faster than making the same calls one after another. ## menuwatch: long copies that stay correct Copies only help if they live long enough to be reused. Our first menu copies were short-lived, and outside peak hours most stores do not get a second menu view before a copy expires. Measured hit rates were poor. Making copies live longer is easy. Making them live longer **and stay correct** is the real problem. A price change, a sold-out item or a discount that starts in the evening has to show up right away. So we wrote **menuwatch**, a small Go service that watches the database instead of waiting to be told about changes. Continuously, it takes a fingerprint of the rows each store's menu depends on: items, add-ons, discounts, schedules, store settings, categories, translations, flash sales and more. If a store's fingerprint changes, its copies are dropped. If something shared changes, like a category, a counter goes up and every menu copy goes stale at once. Time is a change too. A discount that starts at a set time does not edit any row at that time, so menuwatch also knows the clock boundaries in the data, such as discount windows, flash sale times, temporary closes and midnight, and treats each one as a change when it arrives. With that in place, menu copies now live for hours, and a repeat menu is served by Go almost instantly. The same watcher now covers offers and coupons, and when it sees a change it tells **storelive**, which pushes the update to apps. That part of the story is in part three. ## Measuring who answered Every response from the Go service is counted with its route, status code and a `served_by` label: Go, a Go copy, or Laravel. That gives us an honest picture rather than a hopeful one. It also told us where copies were not paying off. On some endpoints the copies missed most of the time, not because they were wrong but because traffic was too sparse for a short-lived copy to be reused. That is why we built menuwatch, and why our rule now is to prefer Go **computing** the answer from the database for heavy pages, and use copies mainly for endpoints that apps poll. ## What's next The next ports on our list are the cart with live pricing and the remaining store page parts, both computed in Go rather than copied. Both will go through the same off, shadow and serve path. In part three we cover realtime: how order status, store open and close, chat and rider positions reach your phone in a fraction of a second, and why we replaced our WebSocket server with one Go process. *This is part two of our series on Laayo's tech stack.* --- # How we measure progress > The signals our leadership team watches closely, why we chose them over vanity numbers, and how each one connects to a decision we can actually make. - Source: https://blog.laayo.com.np/how-we-measure-progress - Section: Investors - Author: Laayo Leadership (Laayo Services Pvt. Ltd.) - Published: October 14, 2026 - Topics: Metrics, Strategy, Quality, Growth It is easy to measure a delivery business by the biggest numbers it can find. Those numbers feel good, but on their own they say little about whether the business is healthy or whether customers will come back next week. We prefer signals that tell us something we can act on. This post explains which ones we watch and why. We do not share the values here. The point is the thinking behind them. ## Customers: do they come back? **Repeat customers.** The most important question for any consumer business is whether people come back. A customer who orders a second and third time has decided Laayo is worth it. We watch how many customers return, how soon and what happened on the orders before they stopped. **Time to second order.** The gap between a customer's first and second order tells us how well their first experience went. A long gap or no second order is a signal to look closely at what went wrong. ## Delivery: did we keep our promise? **Delivery time accuracy.** We care less about how fast the average delivery is and more about how often we arrive within the time we promised. A customer whose food arrives when we said it would is happier than one who was promised something quicker and kept waiting. We explain our estimates in [how we estimate delivery time](https://blog.laayo.com.np/how-we-estimate-delivery-time). **Time food waits at the counter.** Much of the delay in a delivery is not the ride but the wait between food being ready and a rider picking it up. This is where we look for the biggest improvements. ## Cancellations: why did it go wrong? **Cancellations and their reasons.** Every cancelled order is a broken promise to someone. We track how many orders are cancelled and, more importantly, why. That is why we moved from preset reasons to [typed cancel reasons](https://blog.laayo.com.np/why-we-ask-you-to-type-a-cancel-reason): a real sentence from a rider or customer tells us what to fix far better than a tick box. ## Partners: are restaurants better off with us? **Partner retention.** Restaurants and shops that stay with us, and grow with us, are the best evidence that Laayo works for them. We watch which partners stay active, which slow down and what we can do about it. **Payout reliability.** Partners should be paid on time with a statement they can trust. Late or confusing payouts damage relationships faster than almost anything else, so we watch them closely. ## Riders: is the work worth doing? **Rider earnings stability.** Riders need predictable income. We watch whether earnings are steady and fair across shifts and seasons, not just whether a few riders do well. **Rider retention.** Experienced riders know the town, deliver faster and take better care of orders. Keeping them is both a matter of fairness and good business. ![What we watch, grouped by who it matters to: customers, delivery, partners, riders and the product](https://blog.laayo.com.np/media/seed/investor-signals.svg) ## Payments: is paying easy? **Digital payment share.** We watch how many orders are paid by E-Payment or wallet rather than cash. A rising share means payments feel easy and safe, which reduces cash handling for riders and speeds up payouts for partners. **Payment issues.** Any payment that leaves a customer unsure whether they paid is a problem. We track how often that happens and how quickly it is resolved. ## Product: does the app just work? **Crash-free sessions.** An app that crashes loses trust instantly. We track crashes on every app and treat a new crash as urgent. Our monitoring is described in [part five of our tech stack series](https://blog.laayo.com.np/tech-stack-part-five-observability). **Speed of key screens.** How quickly the app opens and how fast the home screen and menus load shape every customer's first impression. We measure response times on our busiest requests continuously. ## Support: do problems get solved? **Time to a real answer.** When something goes wrong, how long does it take a customer, partner or rider to reach someone who can fix it? We watch how long that takes and how often the first answer actually solves the problem. ## Why these and not others Each signal on this list connects to a decision we can make: change how orders are offered to riders, work with a partner on packaging, fix a screen that is slow, adjust how support hands over to staff. If a number does not lead to an action, we do not spend much time on it. We also look at signals together rather than alone. Growth that comes with rising cancellations is not progress. Faster deliveries that come from overworked riders are not progress either. Real progress shows up across the whole list at the same time. These signals keep us honest with ourselves. We believe they are also the right way for anyone interested in Laayo to judge how we are doing. If you would like to talk with us, visit our [investors page](https://blog.laayo.com.np/investors). --- # The phone call that gets your food cooking > A notification is easy to miss in a busy kitchen. Here is how we decide when a restaurant hears about an order, and the automatic call that follows when cooking has not started. - Source: https://blog.laayo.com.np/reminding-restaurants-to-accept - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 14, 2026 - Topics: Restaurants, Notifications, Voice, Orders Picture a small kitchen at lunchtime. The tablet is propped against a jar of achar, the gas is roaring, someone is shouting an order through the window. A new order chimes once. Nobody hears it. From the customer's side, nothing happens. The order says the rider is on the way to the restaurant, the rider arrives, and the food has not been started. That one missed chime has just turned a quick meal into a long one. This post is about two changes that attack that problem from both ends: telling the restaurant at the right moment, and calling them when the message does not land. ## Tell the restaurant when a rider is coming It sounds backwards, but the restaurant used to hear about some orders **too early**. Prepaid orders rang the kitchen the moment payment went through, before any rider had agreed to deliver them. Cash orders could trigger automatic reminders to the restaurant while still waiting for a rider. Kitchens started cooking food that then sat on the counter going cold while we looked for someone to carry it. So we changed the rule. For deliveries made by our riders, the restaurant's new-order alert now waits until **a rider is on the order**. For prepaid orders, that is the moment a rider takes it. For cash orders, the restaurant hears once the rider has accepted. We are rolling out a further step that waits for the rider's final confirmation on cash orders. A few things deliberately skip the wait: - **Takeaway and self-delivery orders.** There is no rider to wait for, so the restaurant hears straight away. - **A manual nudge from our team.** If someone in operations sends a reminder, it goes through. - **A switch.** The whole rule can be turned off from settings in seconds if it ever causes trouble. There is a trade-off. A prepaid order that no rider picks up is not seen by the restaurant until someone assigns a rider. That is why our operations app raises an alert for any order waiting too long without a rider, and why assigning a rider from that app now moves the order forward properly. ## Then, if nothing happens, we call Even a well-timed alert can be missed. So when a rider is on an order and the restaurant has not moved it to cooking within a short time, Laayo **calls the restaurant**. The call comes from Laayo's own phone line. It rings every number the restaurant has given us at the same time, the shop phone, the owner and staff on duty, and plays a short message in Nepali: hello, this is Laayo, you have a new order, the last digits of the order number, the items, the rider's first name, and a request to start it in the app. We kept the message short on purpose. Early versions read the full order number and repeated the whole message. It was clear, but long, and a long call is both expensive and annoying to someone with their hands full. The current message plays once and says only what the cook needs to act. If cooking still has not started, the call comes again after a few more minutes. Every round also sends a loud alert to the partner app. ![When a rider is on the order, the restaurant gets a loud alert. If cooking has not started, an automatic call in Nepali follows, and our team is alerted if calls go unanswered.](https://blog.laayo.com.np/media/seed/accept-reminders.svg) ## The second kind of late Starting late is one problem. Finishing late is another. When a restaurant marks an order as cooking, it tells us how long it will take. If that time passes and the food still has not been handed to the rider, a similar call goes out: your order is ready to be picked up, the rider is waiting. ## Knowing whether anyone heard A call that nobody answered is not the same as a call that was ignored. The phone system can tell whether a person picked up or the call went to voicemail, and whether the whole message played. Every call is logged against its order with that outcome, so in the operations app we can see "picked up, heard the message" or "no answer" next to the order. If the last round goes unanswered and the order still has not moved, our operations team gets an alert to step in, usually by calling a person they know at that restaurant. ## What we did not build, yet - **Per-restaurant opt-out and quiet hours.** Some restaurants would like calls only at certain times. That is on the list. - **Calls for every order type.** Takeaway and self-delivery orders are skipped by design, because no Laayo rider is waiting. ## What's next The best reminder is the one we never have to send. We are working with restaurant partners on louder, clearer alerts in the partner app, and on spotting kitchens that regularly need a call, so our team can visit and help set things up. If you run a restaurant on Laayo and the calls feel too frequent or too late, tell us. We can tune the timing, and your kitchen is the one that has to live with it. --- # Order alerts riders cannot miss > An order that nobody sees is an order that gets cancelled. How we traced every way a new order alert could go silent, and the receipts that now tell us when one did. - Source: https://blog.laayo.com.np/order-alerts-riders-cannot-miss - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 13, 2026 - Topics: Riders, Notifications, Android, iOS There is a particular kind of cancelled order that hurts more than the others. The restaurant accepted it. The food was cooking. A rider was free and nearby. And yet nobody picked it up, because the rider whose phone should have rung never heard anything. When we went through those orders one by one, the answer was rarely "the rider ignored it". It was almost always "the rider never saw it". This post is about how a new order alert reaches a rider's phone, all the places it could quietly disappear, and how we made the alert hard to miss and easy to measure. ## The path of an alert When an order needs a rider, the server picks the riders who should hear about it and sends each of them a push notification. On the phone, that push can land in three very different situations: - **The app is open.** The app shows a full screen request with a ringing sound until the rider accepts or someone else takes it. - **The app is in the background or the screen is locked.** The operating system shows the notification and plays its sound. - **The app has been closed or killed.** The push has to wake the app up before anything can happen. Each of those paths had its own way of failing. ![The four places a new order alert could disappear, and the receipt we now record at each step](https://blog.laayo.com.np/media/seed/order-alert-receipts.svg) ## Four ways an alert went silent **The phone was never registered.** For a push to reach a phone, the app first has to tell our server its push token. The app did this only at one point during start up, and it waited for some slower setup steps to finish first. On iPhones those steps could fail right after launch, and with no internet they could hang. Either way the token was never sent, and there was no retry. Opening the app by tapping a notification skipped that start up step entirely. The fix: the app now registers its token first, retries with time limits, and checks again whenever it comes back to the foreground. If the server says it has no working token for a rider, the app is told to register again straight away. **The app switched itself off.** If the phone had blocked notifications, the home screen quietly turned off the app's own "receive orders" setting as well. When the rider later allowed notifications again, nothing turned it back on. That automatic switch off is gone, and riders who had been caught by it get their setting restored once. **The server skipped some riders.** Orders are offered to riders whose vehicle type matches the order. Riders without a vehicle type on their profile could see those orders in their feed, but the alert step filtered them out, so they were never rung. The server now includes them. **The sound played once, then stopped.** In the background, Android plays a notification sound one time. A single short chime is easy to miss on a busy road. We made the new order sound keep playing while the app is in the background or the phone is locked, until the order is accepted, taken by another rider or cancelled. When the rider opens the app, the in app ringer takes over and the background one stops, so they never hear two rings at once. ## Making the ring loud enough Hearing the alert is the next problem. Riders keep their phones on silent, in pockets, under rain covers. We added a dedicated alarm channel for new orders on Android. It uses the alarm volume rather than the media volume and a longer, clearer sound, and if a rider chooses to allow it, it can ring through Do Not Disturb. On iPhone we use a longer alert sound for the same reason. Some phones are aggressive about stopping apps in the background to save battery. There is no way to switch that off from inside an app, so instead we built a "Set up your phone for orders" sheet. It checks each setting that matters and sends the rider directly to the right screen to fix it: notification permission, location "all the time", battery and auto start settings for the major Android brands, Do Not Disturb access and whether the alarm volume is muted. We also said no to a few tempting tricks. Full screen takeovers, special alert permissions and call style notifications are reserved by the app stores for calling and alarm apps. Using them for delivery orders would put the whole rider app at risk in review, so we stayed inside the rules. ## Receipts: knowing instead of guessing All of the fixes above were based on reading code and reproducing problems on our own phones. That does not scale. We wanted every alert to report back. So the rider app now sends small receipts for each new order alert: - **Received**, when the push reached the phone, even in the background. - **Shown**, when the alert actually appeared to the rider, along with where: the in app request, the background alarm or the floating overlay. Receipts are cheap, sent once per order and stage, and written so they work even when the app is running only in the background. On the server they answer a question we could not answer before: for this order, which riders' phones really rang? They also feed the phone setup checks. If a rider has been sent several order alerts and none of them came back as received, the server tells the app that alerts are not reaching this phone, and the rider sees a clear "Order alerts are off" warning with the steps to fix it. Our operations team sees the same signal, so they know to call that rider before the dinner rush rather than after a cancelled order. Most of the changes in this post, including the looping background ring, the alarm channel, the phone setup sheet and the receipts themselves, are rolling out with the next rider app update and the server release that goes with it. ## Voices riders can understand Alerts are not only sounds. The rider app also speaks short prompts, such as asking for a photo of the packed order or telling a rider an order is ready to pick up. These used to be read out by the phone's built in voice, which made Nepali sound robotic and sometimes hard to follow. We now generate each prompt once on the server with a neural text to speech voice tuned for warm, natural Nepali, store the audio file and serve the same file to every rider. It costs almost nothing because each line is generated a single time. If the phone is offline, the app falls back to the on device voice, so a prompt is never skipped. ## What's next Receipts give us a delivery report for every alert. Next we will use them to spot patterns, such as phone models, app versions or areas where alerts arrive late, and to decide when an order should be offered to more riders because the first ones clearly did not hear it. --- # Why we started Laayo in Birtamod and Damak > Most delivery apps start in the capital and work their way out. We went the other way. What we have learned building food delivery for smaller towns in eastern Nepal, and where we go next. - Source: https://blog.laayo.com.np/delivery-in-small-towns - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 12, 2026 - Topics: Laayo, Birtamod, Damak, Riders, Restaurants Ask people in Birtamod where to get the best momo and you will get a different answer from everyone, each delivered with total confidence. Ask them how to order it to their door on a rainy evening, and until recently the answer was: call the shop, describe your house by the nearest landmark, and hope. Laayo exists because we think people in smaller towns deserve the same convenience people in big cities take for granted, built for the way their town actually works. ## Why start small The usual playbook for a delivery app is to launch in the biggest city, where there are the most restaurants and the most people with smartphones, and spread outwards later. We understand why. But it leaves towns like ours at the end of a very long queue, and when the apps finally arrive, they arrive built for somewhere else. We started in **Birtamod**, and then **Damak**, for a few reasons: - **It is home.** We know the roads, the lunch rush, the lanes that turn to mud in monsoon and the shops that close early on festival days. That knowledge does not fit in a spreadsheet, but it shapes every decision. - **Distances are short.** Most deliveries in our towns are a quick ride. Food can arrive hot, and a rider can do more trips in a shift. - **Restaurants are ready.** Local kitchens make excellent food and many have loyal regulars, but very few had a way to reach people beyond their phone line and their front door. - **People are ready too.** Smartphones and digital payments have become everyday tools in our towns. The demand was there. The service was not. ## What delivery looks like here Building for a smaller town changes the details in ways you only learn by doing it. **Addresses are landmarks.** Many homes do not have a street address anyone would use. People say "behind the school, the blue gate, second lane after the temple". So in the Laayo app you drop a pin exactly on your home, and your rider can call you if the lane is hard to find. We are also building a way for riders to ask you to share your live location when they are close. **Lunch is the big moment.** A large share of our orders come in the middle of the day: offices, shops and schools all ordering at once. That is when kitchens are busiest and every rider is on the road. A lot of our engineering work, from delivery time estimates to how orders are offered to riders, is about getting lunch right. **Weather is real.** Monsoon rain can turn a quick ride into a long one. Our delivery estimates take rain into account, so customers see a realistic time instead of an optimistic one. **Cash still matters, and so does E-Payment.** Plenty of people still prefer to pay cash at the door, and that is fine. But more and more people pay by E-Payment: scanning a QR code, using their mobile wallet or bank app, or topping up a Laayo Wallet. We have worked to make every one of those feel like one tap, including tipping your rider from the tracking screen. ## The people who make it work Laayo is riders, restaurants and customers working together, and we are only as good as the weakest link. ### Riders Our riders are the face of Laayo. They know every shortcut in town. We have built the rider app around their day: clear order alerts that are hard to miss, a run planner when they carry more than one order, a record of every tip they receive, and a typed reason when they need to cancel so we hear what really happened on the road. We keep working on the things riders tell us matter most, including fair, predictable pay and less time waiting at restaurant counters. ### Restaurants and shops Our partner restaurants range from small family momo shops to busy cafes. When a restaurant joins Laayo, it tells us its preparation time, opening hours, who on the team should receive calls, and how it wants to be paid, either by bank or by QR. Restaurants manage their menu and their orders from the Laayo partner app, and get paid on a regular schedule with a full statement. Beyond food, Laayo also delivers groceries and everyday items from local shops, so a forgotten packet of milk does not need its own trip. ### Customers And then there is you. People in our towns are generous with feedback, sometimes very loudly, and we are grateful for it. The things you tell us most often are exactly the things we are working on hardest. ## What we are working on We would rather be honest about where we can do better than pretend everything is perfect. - **Faster deliveries.** The biggest delay in most orders is not the ride. It is the time food waits at the restaurant for a rider to arrive. We are working on how riders are matched and when orders are offered, so food leaves the kitchen sooner and arrives hot. - **Food that arrives the way it left.** Cold food, spilled curries and missing items hurt more than a late order. We are working with partner restaurants on packaging and order checks, and we read every low rating. - **Payments that just work.** E-Payment should never leave you unsure whether you paid. We are making payment status clearer and tightening every step where a payment can get stuck. - **Support that answers quickly.** When something goes wrong, you should reach a real person fast. We are making it quicker to get from the in-app help to someone who can fix it. ## What comes next Our focus for now is clear: make Laayo genuinely excellent in Birtamod and Damak. A great service in a few towns is worth more than an average one in many. Looking further ahead, we want to bring Laayo to more places, including **Kathmandu**. It is a plan, not a promise, and we will only launch when we are confident we can deliver the same care there that we try to give here. When we have a date, you will hear it first on this blog. Until then, thank you for ordering, for riding, for cooking, and for telling us what to fix. Laayo is a small team building something big for small towns, and every order is a vote of confidence we do not take lightly. --- # Laayo's tech stack, part one: the foundation > The servers, edge, databases and deploy habits that every order on Laayo runs through, and why we chose a boring, well-understood base before anything clever. - Source: https://blog.laayo.com.np/tech-stack-part-one-foundation - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 12, 2026 - Topics: Infrastructure, Laravel, MariaDB, Redis When you open Laayo in Birtamod or Damak and tap a restaurant, a lot happens in the blink of an eye. The app asks for nearby stores, the server works out which ones deliver to your exact pin, prices are calculated, a rider's position streams in, and a partner's tablet starts ringing when you place the order. This series walks through the systems behind that, layer by layer. We are a small team building for towns that the big platforms tend to skip, so most of our decisions come from one question: what gives customers, riders and partners a fast, reliable app without needing a large operations team to keep it alive? Part one covers the foundation. Later parts cover the Go services we put on the hottest paths, realtime updates, the native apps and how we watch all of it in production. ![How a request reaches Laayo: clients go through the edge and nginx, hot paths are answered by Go, everything else by the Laravel monolith, backed by MariaDB, two Redis roles, search and analytics stores.](https://blog.laayo.com.np/media/seed/tech-stack-foundation-overview.svg) ## The shape of the system Laayo has five kinds of clients: - the **customer app** on iOS and Android, - the **rider app**, which riders keep open for their whole shift, - the **partner app** that restaurants and shops use to accept and prepare orders, - the **website** at laayo.com.np, - and the **admin panels** our operations team uses on the web and on their phones. All of them talk to one API. Behind that API sits a single Laravel application, a set of small Go services that take over the busiest requests, and a handful of data stores, each with one clear job. We run on a deliberately small footprint: a few well-provisioned machines, off-site backups and a separate staging copy. That sounds modest, and it is on purpose. Fewer moving parts means one place to look when something is slow, one set of logs and very few network hops between services. It also means we have to be disciplined about what runs on it, which shows up in almost every decision below. ## The edge Every request first reaches our edge provider. It terminates TLS close to the user, absorbs abusive traffic before it reaches us, and caches static files like images and app assets. For API calls it mostly passes traffic straight through, because almost everything in a food delivery app is personal or changes by the minute. Behind the edge, **nginx** is the front door on our own server. It does three jobs: 1. **Routing.** A small list of paths that we have rebuilt in Go goes to the Go services. Everything else goes to Laravel. 2. **Limits.** Per-IP and per-token rate limits protect endpoints that apps call often, such as rider location updates. 3. **Fallback.** If a Go service is down or returns a gateway error, nginx quietly retries the same request against Laravel. Customers never see the difference, which is what lets us move fast on the Go side. ## Laravel, the monolith we keep The core of Laayo is a Laravel application running under PHP-FPM behind nginx. It is big, with thousands of routes across the apps, the admin tools and the partner web panel. It owns orders, payments, coupons, wallets, rider payouts, support tickets and the admin tools that run the business day to day. We get asked why we have not rewritten it. The honest answer is that a monolith is a very good place to keep business rules. When a coupon, a delivery fee and an E-Payment refund all need to agree, it helps that they live in one codebase with one database transaction. Rewrites are where those rules quietly break. So Laravel stays, and we make it faster where it counts: - **Fewer queries per request.** One configuration step used to run a long list of queries on every app config call. It now runs one. Store lists need far fewer queries since we batched schedules, configs and modules. - **Cached schema checks.** The code checks whether optional tables and columns exist in many places. Each check was a database round trip. We now answer them from an in-memory cache, which made one of the rider's busiest screens several times faster. - **Slimmer responses.** The apps never read dozens of fields that store lists used to send. Dropping them made the biggest list responses about a third smaller. The one thing we cannot make much faster is the cost of starting the framework for each request. Even a trivial Laravel API call pays a noticeable start-up cost before it does any real work. That cost is the reason part two of this series exists. ## Data: one source of truth, two kinds of Redis **MariaDB** is our source of truth for everything that matters: orders, items, stores, users, payments. We keep the whole working set in memory, and in practice almost every read is served from the buffer pool rather than disk. Indexes get added when a slow query shows up in monitoring, not before. A customer list in the admin panel that took painfully long became near instant with one missing index, which is a good reminder that boring fixes still win. **Redis** runs in two separate roles, and the split matters more than it sounds. | Role | What lives there | When it is full | | --- | --- | --- | | Live | rider positions, presence, queues, locks, realtime bridges | must never silently drop data | | Cache | saved API responses, menu and store copies, computed lists | evicts the least recently used keys | Before the split, one Redis did both. A burst of cache writes during dinner could push out a rider's live position or a queue entry. Now a cache flood only ever evicts other cache entries. Positions and jobs are safe. We also run **Meilisearch** for dish and store search, so "briyani" still finds biryani and "mo:mo" finds momo, and **ClickHouse** for high-volume logs and metrics that do not belong in the main database. ## Queues with lanes Plenty of work does not need to happen while the customer waits: notifying riders about a new order, recording GPS trails in bulk, generating WebP copies of images, calculating fuel summaries. That work goes onto queues, and the queues have **lanes**. Order-critical jobs like rider notifications and reminders go on the default lane, which has dedicated workers. Heavy background jobs, mainly GPS ingestion that arrives in large batches, go on a low lane with its own worker. A flood on the low lane cannot delay an order notification, because the default workers never pick up low-lane jobs. Workers are long-running processes managed by the operating system. They restart automatically if they crash and recycle themselves regularly, so a slow memory leak in one job cannot build up over days. ## Images Restaurants upload photos straight from their phones, so we used to serve multi-megabyte PNGs to customers on mobile data. A background job now makes a resized WebP copy of every store, product, banner and category image, sized for how it is shown. nginx serves the WebP copy when one exists and falls back to the original when it does not. Apps did not need an update, and image-heavy screens got much lighter overnight. ## How a change ships The part of the foundation we are most strict about is not a technology. It is the path every change takes to production. ![How a change ships: build on tests, compare outputs, check on staging with real data and outgoing messages blocked, deploy with a script that backs up first, then watch production. Every deploy has a rollback script.](https://blog.laayo.com.np/media/seed/tech-stack-shipping.svg) 1. **Tests first.** We run a full second copy of the backend with its own database. Every change is built and checked there first. 2. **Compare, do not trust.** When we change how something is computed, we compare the old and new output, byte for byte where possible. "It looks right" is not a check. 3. **Staging with real shapes.** A separate staging copy runs on a recent copy of production data, with every outgoing channel blocked: no SMS, no email, no push notifications, no payment callbacks. Real data finds bugs that test data never will, and the block means a test can never message a real customer. 4. **A script, not a session.** Production changes go out through a deploy script that takes a backup, does a dry run, applies the change and runs checks. Each one comes with a matching rollback script. 5. **Watch it land.** After a deploy we watch the dashboards and crash reports described in part five. PHP on our server picks up new code after a short delay, so we wait for that before checking, instead of declaring victory on a half-updated server. Most of our changes can also be switched off without a deploy, through feature flags in the admin panel or per-endpoint modes on the Go side. Being able to turn something off in seconds is what makes it safe to ship often. ## Why boring None of this is exotic. A monolith, a relational database, Redis, queues and a careful deploy path are the same pieces many teams start with. That is the point. When an order is stuck at 9 pm in Damak, we want the problem to be in a place we understand well, with logs we know how to read. The interesting work happens on top of this base, where we have measured a real bottleneck and replaced one piece of it at a time. ## What's next In part two we look at the biggest bottleneck we found, the fixed cost of every Laravel request, and how we moved the busiest API calls to Go without a big-bang rewrite, by running Go in the shadow of Laravel and comparing every answer before trusting it. *This is part one of our series on Laayo's tech stack.* --- # Help when you need it, and a person when it matters > Our Help Center answers the common questions before you have to ask. When you do need someone, the chat should go to one person who owns it until it is solved. Here is how we built both. - Source: https://blog.laayo.com.np/help-when-you-need-it - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: October 11, 2026 - Topics: Support, Help Center, Customer care Most questions people bring to support are not emergencies. How do I change my address? Why was I charged a delivery fee? How long does a refund take? Those deserve a clear answer you can read in a minute, at any hour, without waiting for anyone. A few questions are different. The food arrived cold and half of it was missing. Money left your account and the order did not go through. For those, you should reach a person, that person should stay with you, and the problem should not quietly disappear when the chat goes quiet. This post is about building for both. ## A Help Center you can actually read **support.laayo.com.np** is our public Help Center. It is organised by topic, ordering, payments and refunds, your account, riders and restaurant partners, with short articles written in plain language. Every article ends with "Was this helpful?" so we can see which answers are not working and rewrite them. A few principles we held to: - **Only describe what is live.** If a feature is still rolling out, the Help Center does not promise it. A help article that describes a button you cannot find is worse than no article. - **Same words as the app.** If the app says "E-Payment", the Help Center says "E-Payment". - **Editable without a release.** Our support team can update articles from the admin panel, so a confusing answer can be fixed the same day. We are also rolling out **sign in with your Laayo account** on the Help Center, so you can see your recent orders, your open reports and your chats with us in one place, from any browser. ![Most questions are answered by the Help Center or the in-app chat. When a person is needed, the chat is claimed by one agent and becomes a ticket that stays open until it is solved.](https://blog.laayo.com.np/media/seed/help-paths.svg) ## Chats used to have no ending Support chat in the Laayo app is one long conversation per customer. That is nice for the customer, who can scroll back and see everything. It was bad for us. Our team had no clean way to tell "this person needs a reply right now" from "this person said thanks three days ago". Almost every conversation looked like it was waiting. So we split the long conversation into **sessions**. A session is one stretch of help: it starts when you write in, it can be waiting, active or resolved, and it ends when the problem is sorted. "Needs reply" now means one thing: a session where the customer is waiting and nobody has answered. ## One person owns the conversation When a chat needs a person, someone on our team **claims** it. The customer sees "(name) joined the chat", with the agent's first name, so they know a real person is reading. If that person needs to hand over, for example to someone who handles refunds, the chat is transferred and the customer sees the new name join. A few small rules make this feel human: - **No vanishing history.** Resolving a session never hides earlier messages from the customer. - **Notes stay internal.** Agents can leave notes for each other on a chat. Those notes live separately and can never be shown to the customer by mistake. - **Rating is just a reply.** When a session ends, we ask how it went. You can answer with a number or a few stars, right in the chat. No new screen, no app update needed. The new support desk is rolling out to our operations app, and our team is already using it as it arrives. ## When a chat becomes a ticket Some problems take longer than one conversation. A refund needs a payment check. A missing item needs the restaurant to confirm. Before, those problems lived only in someone's memory, and if that person went home, the customer waited. Now, a chat that needs a person **becomes a ticket** automatically. A ticket is not a second conversation, it is a view onto the same chat, so replies still go to the customer where they already are. The ticket stays open until it is truly resolved, even if the chat goes quiet, and it sits in the same queue as order problems reported from the app, sorted by who has waited longest. Tickets open for clear reasons: the customer asked for a person, the problem is about money, or the assistant promised to check something. When the only signal is a word, like someone writing "worst", the assistant reads the conversation first. A joke about the "worst" momo craving does not become a ticket. A message saying a rider took cash and the order never arrived does. Each ticket gets a short subject and summary, so the person who opens it understands the problem in seconds instead of scrolling through the whole chat. ## What's next We want the first answer to be right more often, so fewer people need a person at all. That means better Help Center articles, written from the questions we actually receive. And for the people who do need us, we want the wait to be short and the ending to be clear. If you ever feel a support chat was closed before your problem was solved, reply in the same chat and we will pick it up again. --- # Rider GPS that never gets stuck > A rider's dot on the map is a promise to the customer, the restaurant and our dispatch team. Here is how we found the ways it silently froze, and what we built so it heals itself. - Source: https://blog.laayo.com.np/rider-gps-that-never-gets-stuck - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 11, 2026 - Topics: Riders, GPS, Realtime, Flutter When you track an order on Laayo, the little helmet moving across the map is the most watched thing in the whole product. Customers stare at it. Restaurant partners use it to time the last minute of cooking. Our dispatch team uses it to decide who gets the next order. If the dot freezes, every one of those people makes a worse decision, and none of them can tell that the dot is lying. This post is about the ways a rider's location could stop updating without anyone noticing, and the three layers we built to stop that from happening: a sender in the rider app that cannot wedge, a server that knows when a rider has gone quiet, and automation that uses GPS to move the order forward even when a rider forgets to swipe. ## How a location point travels A rider's phone produces a GPS fix every few seconds. The rider app sends it over a WebSocket when one is open, and over plain HTTP when it is not. On the server, both paths land in the same place: the point is checked, written to the rider's location history, and pushed into a live index of riders per zone that lives in Redis. That index is what dispatch and the tracking screen read from. It is built to heal itself: every entry carries a "last seen" time, and stale riders drop out on the next read, with no cleanup job to forget about. That pipeline was healthy. When we looked at riders whose dots had frozen, the server was receiving points perfectly well from everyone else. The problem was on the phone. ![How a rider's location reaches the map, and where it used to get stuck](https://blog.laayo.com.np/media/seed/rider-gps-pipeline.svg) ## The lock that never let go The rider app sends one location update at a time. That is sensible: you do not want ten overlapping uploads when the network is slow. It used a simple flag for this. Set the flag, send, clear the flag. The catch is what happens between "set" and "clear". A send can involve opening a WebSocket, closing a half dead one, asking the phone for its current position, or turning coordinates into an address. Any of those can hang forever on a bad network or a confused phone. When one hung, the flag stayed set, and every GPS fix and heartbeat after it was quietly dropped until the rider restarted the app. From the outside it looked exactly like a rider who had gone offline. They were still accepting orders, still delivering, still chatting with customers. Their dot just did not move. The fix is small and boring, which is how we like fixes to be: - The flag became a timestamp. A lock that is held for too long is treated as abandoned and the next send goes ahead. - Every step that can hang got a time limit: connecting a socket, closing one, looking up an address and asking for the current position. ## The permission that started nothing The second cause hit more riders at once. Background tracking used to start only if the phone had granted location access "all the time". Phones, especially iPhones, regularly nudge people to downgrade that to "while using the app". A rider who had done that, then relaunched the app while already online, never started tracking at all. Now any granted location permission starts tracking. We still ask for "all the time", because it keeps the dot alive with the screen off, but we no longer refuse to work without it. Both of these fixes are in the rider app and are rolling out with the next rider app update. ## A server that notices silence Fixing the known causes is not enough. Phones will find new ways to stop sending, so the server now watches for silence on its own. A regular health check looks at each rider's last location point. A rider with an active order who has gone quiet for too long, or an online rider without orders who has been quiet for a while longer, is marked as stale. Two things happen: - The rider gets a push that says their location is not syncing, with a cap on how often it repeats so it never turns into noise. - Our dispatch team sees the rider flagged in the admin tools, so they stop trusting that dot for the next assignment. In the next rider app update, that push opens a fix sheet. It is a short checklist that looks at the things we have seen go wrong in practice: GPS switched off, the wrong location permission, battery saving that kills background work, no internet, and finally whether the server is actually receiving points. Each row tells the rider what to choose and has a button that takes them straight to the right settings screen. The last check uses the server's answer, not the phone's opinion, because the phone is the one that was wrong. ## Letting GPS move the order forward Once we trusted the location stream, we could ask more of it. Riders are busy. They forget to swipe "Arrived" at the restaurant, and they forget to slide "Picked up" when they leave. Every missed swipe makes the tracking screen less true and the delivery time estimate worse. So the server now does it from GPS, carefully: - **Arrived at the store** when the rider has stayed close to it for a short dwell. - **Picked up** when the order is ready for handover, the rider was seen at the store, and then two readings a few seconds apart show them clearly moving away. - **Arrived at your door** when the rider has stayed close to the drop point. The rules are deliberately suspicious. A fix with poor accuracy cannot prove an arrival. Points from mock location apps are ignored. Riding past at speed does not count as arriving. Points that arrive out of order or twice are dropped, so a delayed upload can never move an order backwards. Every write is conditional, so if the rider swipes first, the swipe wins. Automatic steps are labelled as GPS steps in the order timeline, so support can always tell what a person did from what the system inferred. Riders get a short notice when a step was marked for them, and an automatic pickup can be undone for a short while in case the rule guessed wrong. All of this has switches in the admin settings, so we can turn any part off in seconds without a release. ## When there is no signal at all The last piece is for the places in Birtamod and Damak where there is simply no network: basements, lifts and a few stubborn streets. Before, if a rider marked an order delivered in a dead spot, that tap was lost. The rider app now has an offline queue. Writes such as status changes and delivery photos are saved on the phone and replayed in order when the connection comes back. A few rules keep it honest: - **Strict order.** If the item at the front fails for a temporary reason, nothing behind it jumps ahead. Replaying "picked up" before the pickup photo would lose the photo, because the server refuses photos once an order has moved on. - **Photos are copied somewhere safe.** The phone's own image cache gets cleaned out, often exactly while the rider is offline. - **Login tokens are never stored in the queue.** They are added at send time, so a rider who signs in again does not end up with a queue that can never succeed. - **Permanent refusals are retired, not retried.** If the server says no for a reason that will not change, the item is set aside instead of blocking everything behind it. We checked the server side before building any of this: sending the same "delivered" update several times gives the same result as sending it once, so a replay can never pay a rider twice or collect cash twice. ## What's next The location stream is now good enough that we want to lean on it harder. Next we want to use the live rider index to offer new orders to the nearest suitable riders first, instead of everyone in the zone at once, once it proves itself in shadow mode. We are also feeding the cleaner arrival and pickup times back into our delivery time estimates. --- # The Laayo glossary, A to Z > Plain definitions of the words you meet on Laayo, from E-Payment and Laayo Plus to gigs, rain mode, Qora and the partner app, with links to the full stories. - Source: https://blog.laayo.com.np/laayo-glossary - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 10, 2026 - Topics: Laayo, Guide, Glossary Laayo is a food and grocery delivery app in Birtamod and Damak, Jhapa, Nepal, run by Laayo Services Pvt. Ltd. Like any app, it has its own words. This glossary explains them in one place. Where a feature is still rolling out, we say so. ## A **Accessibility profile.** An optional setting in the customer app where you can share a hearing, vision or mobility need. If you do, the rider delivering your order sees a short, practical card. It is never asked at checkout and you can skip it. See [Designing for everyone](https://blog.laayo.com.np/designing-for-everyone-accessibility). **Admin App.** The app Laayo's operations team uses to watch orders, help riders and partners and answer support, with the same access rules as the web admin panel. See [The ops team in your pocket](https://blog.laayo.com.np/the-ops-team-in-your-pocket). ## C **Cancel reason.** When an order is cancelled, Laayo asks for a short reason in your own words instead of a list of buttons, so we can fix the real problem. See [Why we ask you to type a cancel reason](https://blog.laayo.com.np/why-we-ask-you-to-type-a-cancel-reason). **Cash on delivery.** Paying the rider in cash when your order arrives. It is one of the ways to pay on Laayo, alongside E-Payment and the Laayo wallet. **Central Jhapa.** The towns around Birtamod where Laayo delivers, in addition to Birtamod itself and Damak. ## D **Damak.** The second town where Laayo operates, after Birtamod. **Delivery time.** The estimate shown on a restaurant card and on your tracking screen. It is calculated from the kitchen, the rider and the road, and updates while your order is on its way. See [How we estimate when your food will arrive](https://blog.laayo.com.np/how-we-estimate-delivery-time). ## E **E-Payment.** Paying online by scanning a QR code with your bank or wallet app. The order is confirmed once the payment arrives. See [Paying with a QR inside the app](https://blog.laayo.com.np/paying-with-a-qr-inside-the-app). ## F **For you rating.** A restaurant rating tuned to your own taste, shown alongside the overall rating. See [Ratings that mean something](https://blog.laayo.com.np/ratings-that-mean-something). ## G **Gift card.** A Laayo gift card with a code you can send by SMS or email. The person who receives it claims it into their Laayo wallet. See [Gift cards and Send a Treat](https://blog.laayo.com.np/gift-cards-and-send-a-treat). **Gig.** A delivery shift that a rider books in the rider app for a work area and time. Being online is tied to a gig. See [Gigs for riders](https://blog.laayo.com.np/gigs-for-riders). **Group order.** A shared cart where friends or colleagues add their own items from one restaurant through a link, and one host places the order. See [Ordering together with group orders](https://blog.laayo.com.np/ordering-together-with-group-orders). ## H **Help Center.** Laayo's help site at [support.laayo.com.np](https://support.laayo.com.np), with answers to common questions and a way to reach the support team. See [Help when you need it](https://blog.laayo.com.np/help-when-you-need-it). ## I **Invoice.** A PDF of your order you can download from the app, labelled "Invoice". Rolling out. See [Refunds you can follow](https://blog.laayo.com.np/refunds-you-can-follow). ## L **Laayo.** The food and grocery delivery app, and the brand of Laayo Services Pvt. Ltd. See [Laayo at a glance](https://blog.laayo.com.np/laayo-at-a-glance). **Laayo Biz.** A point of sale for restaurants, at [biz.laayo.com.np](https://biz.laayo.com.np), covering billing, tables and staff, connected to the orders a restaurant receives on Laayo. **Laayo Plus.** A monthly membership for regular customers, with delivery benefits and priority support. See [What Laayo Plus gives you](https://blog.laayo.com.np/what-laayo-plus-gives-you). **Laayo wallet.** A balance inside the Laayo app that you can pay with. Gift cards and refunds can be added to it. **Live tracking.** The map that shows your order's progress and, once your food is on its way, the rider's position. ## M **Menu from a photo.** A tool our team uses to turn a restaurant's printed menu into a digital menu with AI, checked by a person before it goes live. See [A menu from a photo](https://blog.laayo.com.np/a-menu-from-a-photo). **Multi-restaurant cart.** Ordering from more than one restaurant in a single checkout, delivered together. Rolling out. See [One cart, many restaurants](https://blog.laayo.com.np/one-cart-many-restaurants). ## O **Offers.** Discounts and deals that restaurants run on Laayo, such as buy one get one. Laayo picks the best offer that applies. See [Offers that add up](https://blog.laayo.com.np/offers-that-add-up). **Order chat.** One chat per order, where you can talk to the rider and support. See [One order, one chat](https://blog.laayo.com.np/one-order-one-chat). ## P **Partner.** A restaurant or shop that sells on Laayo. **Partner app.** The app restaurants and shops use to receive orders, mark them ready, manage their menu and see payouts. See [Joining Laayo as a restaurant partner](https://blog.laayo.com.np/joining-laayo-as-a-restaurant-partner). **Payout.** The money Laayo sends to a restaurant partner for its orders, with a statement and a confirmation. See [Getting paid on time as a partner](https://blog.laayo.com.np/getting-paid-on-time-as-a-partner). ## Q **Qora.** QR payment software for Nepali businesses, made by Laayo, at [qora.laayo.com.np](https://qora.laayo.com.np). Merchants are paid directly by their own bank; Qora never holds customer money. ## R **Rain mode.** When it rains in a zone, riders can switch rain mode on. Customers see a rain notice, a small rain charge goes to riders, and delivery times account for the weather. See [Riding through the monsoon](https://blog.laayo.com.np/riding-through-the-monsoon). **Refund timeline.** A view that shows where your refund is and when to expect it. Rolling out. See [Refunds you can follow](https://blog.laayo.com.np/refunds-you-can-follow). **Rider.** A person who delivers Laayo orders. Laayo uses its own riders. **Rider app.** The app riders use to accept orders, navigate, chat and see their earnings. See [How riders earn at Laayo](https://blog.laayo.com.np/how-riders-earn-at-laayo). ## S **Send a Treat.** Ordering food for someone else at their address, paid in advance, with a tracking link sent to them. Rolling out. See [Gift cards and Send a Treat](https://blog.laayo.com.np/gift-cards-and-send-a-treat). **Share tracking.** A link you can send so someone else can follow your order without the app. See [Share your order tracking](https://blog.laayo.com.np/share-your-order-tracking). **Support assistant.** The AI assistant in Laayo support chat. It answers common questions and hands over to a person when a chat needs one. See [How Laayo uses AI](https://blog.laayo.com.np/how-laayo-uses-ai). ## T **Tip.** An optional thank-you to your rider, paid by E-Payment or wallet. A limit of one tip per order is rolling out. See [Tipping your rider](https://blog.laayo.com.np/one-tip-per-order). ## Z **Zone.** An area where Laayo delivers, such as Central Jhapa or Damak. Restaurants, riders and offers are organised by zone. ## Quick answers ### What is E-Payment on Laayo? E-Payment means paying by scanning a QR code with your bank or wallet app. Your order is confirmed once the payment arrives. ### What is Laayo Plus? Laayo Plus is Laayo's monthly membership for regular customers, with delivery benefits and priority support. ### What is Qora? Qora is QR payment software for Nepali businesses made by Laayo Services Pvt. Ltd. Merchants are paid directly by their own bank. ### What is rain mode? Rain mode is switched on by riders when it rains in their zone. It shows customers a rain notice, adds a small rain charge for riders and adjusts delivery times. ### What is the Laayo partner app? It is the app restaurants and shops use to receive and prepare Laayo orders, manage their menu and see payouts. --- # Tracking your order, every status explained > What each order status on Laayo means, when you can see the rider on the map, what "delayed" means, and how to share live tracking with someone else. - Source: https://blog.laayo.com.np/tracking-your-order - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 10, 2026 - Topics: Guides, Tracking, Orders After you place an order, Laayo shows you where it is at every step. This guide explains what each status means in plain words. ![An order on Laayo moves through these statuses: placed, accepted, preparing, picked up, on the way, delivered](https://blog.laayo.com.np/media/seed/guide-order-statuses.svg) ## How do I track my Laayo order? After you tap Place order, the app takes you to the tracking screen on its own. You can also open it any time from your orders list. The tracking screen shows the current status, the estimated arrival time, the restaurant and rider details, and a map. ## What does each order status mean? | Status | What it means | |---|---| | Placed | We have your order and sent it to the restaurant. | | Accepted | The restaurant has confirmed it and will start cooking. | | Preparing | The kitchen is making your food. | | Ready for pickup | The food is packed and waiting for the rider. | | Picked up | The rider has your food and is on the way. | | Delivered | The order has reached you. | | Cancelled | The order was cancelled, by you, the restaurant or Laayo. Any online payment is refunded. | ## When can I see the rider on the map? You see the rider's live position once your food is on its way. Before that, the map shows the restaurant and your address. We keep rider locations private until they are carrying your order, which also means the map is always about your food, not about someone's whole day. ## What does "delayed" mean? Laayo shows an estimated arrival time that updates as your order moves, using how long the kitchen usually takes, where the rider is and the road distance to you. If the order falls behind what we expected, the app tells you it is delayed and gives a new estimate, instead of quietly showing a time that has already passed. Read [How we estimate delivery time](https://blog.laayo.com.np/how-we-estimate-delivery-time). ## How do I contact my rider or the restaurant? Open the order. You can chat with the restaurant and, once a rider is assigned, with the rider, all in one thread for that order. You can also call them from the order screen. Read [One order, one chat](https://blog.laayo.com.np/one-order-one-chat). ## Can I share my order tracking? Yes. From the tracking screen, tap Share to send a link. Anyone can open it in a browser to follow the order, without the app. The link shows only that order's progress and, once it is on the way, the rider on the map. It does not show your name or phone number. Read [Share your order, not your phone](https://blog.laayo.com.np/share-your-order-tracking). ## Can I cancel my order? You can usually cancel an order from the app while it is still early, before the restaurant starts preparing it. Once the kitchen is cooking, cancelling may not be possible, because the food is already being made for you. If something has gone wrong, use Help in the order and we will look at it. When you cancel, the app asks you to type a short reason in your own words, which helps us fix real problems. Read [Why we ask you to type a cancel reason](https://blog.laayo.com.np/why-we-ask-you-to-type-a-cancel-reason). ## Can I change my address after ordering? Small changes, such as a landmark or directions, can be sent to the rider through the order chat. For a different address, contact support quickly from the order, before the rider picks up the food. ## Quick answers ### How do I track my Laayo order? The app opens tracking after you place an order. You can also open any order from your orders list to see its status and the map. ### When does the rider appear on the map? Once your food has been picked up and is on its way to you. ### What does "delayed" mean on Laayo? It means your order is running behind the expected time. The app shows an updated estimate. ### Can someone else track my order? Yes. Tap Share on the tracking screen to send a link that anyone can open in a browser. ### Can I cancel a Laayo order? Usually yes, while it is early and before the restaurant starts preparing it. After that, use Help in the order and our team will look at it. --- # Working with Laayo as a business, advertising, partnerships and press > Beyond ordering food, businesses work with Laayo in several ways. Advertising inside the app, becoming a partner, using our software, ordering for an office and talking to us as press or an investor. - Source: https://blog.laayo.com.np/working-with-laayo-as-a-business - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 9, 2026 - Topics: Business, Advertising, Partnerships, Guides Laayo is a delivery app for customers, but a lot of the people who contact us are businesses. This guide lists every way a business can work with Laayo and where to start for each one. ## Can I advertise my business on Laayo? Yes. Businesses can put their brand in front of Laayo customers in Birtamod and Damak through placements inside the Laayo app, such as the order tracking screen that customers watch while their food is on the way. To start, go to **ad.laayo.com.np** ("Advertise with Laayo"). A short step by step form asks about your business, where you want to appear, when you want to start and whether you already have a design. If you do not, our team can design the ad for you from your headline and offer. Your phone number is verified with a quick code, and our team gets back to you to agree the details. ## How do restaurants and shops join? Restaurants, cafes, grocery stores and speciality shops can sell on Laayo and get delivery by Laayo riders. - Restaurants: [joining Laayo as a restaurant partner](https://blog.laayo.com.np/joining-laayo-as-a-restaurant-partner) - Shops: [how to list your shop on Laayo](https://blog.laayo.com.np/how-to-list-your-shop-on-laayo) - Day to day in the app: [a tour of the partner app](https://blog.laayo.com.np/laayo-partner-app-tour) ## What software does Laayo offer businesses? Laayo Services Pvt. Ltd. also builds software that any business can use, whether or not it sells on Laayo: - **Laayo Biz**, a point of sale for restaurants and cafes, at biz.laayo.com.np. See [what is Laayo Biz](https://blog.laayo.com.np/what-is-laayo-biz). - **Qora**, QR payment software that tells a business the moment a customer has paid, at qora.laayo.com.np. See [what is Qora](https://blog.laayo.com.np/what-is-qora). ## Can my office order together on Laayo? Yes. Teams can use **group orders**: one person starts a group order and shares a link, everyone adds what they want, and the host places one order. See [ordering together with group orders](https://blog.laayo.com.np/ordering-together-with-group-orders). For a large one-off order, such as an event, contact our team first so we can talk to the restaurant and plan riders. ## Can a business give Laayo gift cards? Laayo gift cards can be bought in the app and sent to someone by SMS or email, who claims them into their Laayo wallet. Some businesses use them as a thank you for staff or customers. See [gift cards and Send a Treat](https://blog.laayo.com.np/gift-cards-and-send-a-treat). ## How do I propose a partnership? If you run a business that could work with Laayo in another way, such as a brand promotion, a bank or wallet offer, a logistics or supply idea or a community event, send us a note through the contact form on our [Investors page](https://blog.laayo.com.np/investors) and choose "Business partnership". A person from the leadership team reads every message. ## I am a journalist. Who do I contact? Use the same contact form on the [Investors page](https://blog.laayo.com.np/investors) and choose "Press and media". Our brand assets, the Laayo wordmark for light and dark backgrounds, can be downloaded from the same page. ## How do investors get in touch? Read [why we are building Laayo](https://blog.laayo.com.np/why-we-are-building-laayo) and the rest of the investor posts on the [Investors page](https://blog.laayo.com.np/investors), then use the contact form there with "Investing in Laayo". ## How do I reach Laayo support as a business? For anything about an existing order, a partner account or a payout, our support team is the fastest route. The Help Center is at **support.laayo.com.np**, and email goes to **support@laayo.com.np**. ## Quick answers ### How do I advertise on Laayo? Go to ad.laayo.com.np and fill in the short "Advertise with Laayo" form. Our team contacts you to agree placement, timing and design. ### Does Laayo design ads for businesses? Yes. If you do not have a design, choose "design it for me" in the form and give us your headline and offer. ### Can a business use Laayo's software without selling on Laayo? Yes. Laayo Biz and Qora are available to any business. ### How does press contact Laayo? Use the contact form on the Investors page and choose "Press and media". ### What is Laayo's support email? support@laayo.com.np, and the Help Center is at support.laayo.com.np. --- # How we estimate when your food will arrive > A delivery time is a promise. Here is how Laayo turns kitchen history, rider GPS and road distance into an honest ETA that updates while your order is on its way. - Source: https://blog.laayo.com.np/how-we-estimate-delivery-time - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 8, 2026 - Topics: ETA, Machine learning, Maps, Riders The delivery time is the most important number in a delivery app. It is the first thing you look at on a restaurant card and the last thing you check before you put on your shoes to meet the rider at the gate. When it is wrong, everything else feels wrong too. For a long time, the number you saw on Laayo was a range the restaurant typed into its settings once. It never changed. It did not know whether the kitchen had a pile of orders waiting, whether it was raining, or whether you lived around the corner or across town. When we finally measured it against real deliveries, the typed range and reality were far apart. The range was a hope, not an estimate. So we replaced it, in two parts: an estimate before you order, and a live ETA after you do. ## Before you order: a range per store The delivery time on a store card is now computed, not typed. It adds up three pieces: 1. **Preparation.** How long this kitchen has really taken, measured from "accepted" to "picked up" on its recent orders. Using the time until pickup, rather than just cooking time, means the wait for the rider at the counter is already included. 2. **Getting a rider there.** For every rider in the zone we work out when they could reach the store, given where they are and how much of their current work is left. A rider who is almost at a customer's door is closer to free than one who just accepted an order. We take the best rider. 3. **The ride to you.** The road distance from the store to your address, turned into minutes. The result is rounded and shown as a range. It is shared for a short while per store and per small patch of the map, so the card, the store page, the cart and checkout all show the same number, and nobody's phone pays for a fresh calculation on every scroll. If something is missing, such as no rider online or a store without a map pin, the estimator steps aside and the restaurant's own text comes back. A plain honest fallback is better than a confident wrong number. ### A small model on top The formula gets the shape right. A small regression model, trained offline on our own past deliveries, corrects it. It looks at things the formula does not: time of day and day of week, lunch and dinner peaks, weekends, how busy the kitchen was when the order came in, whether it was raining, road distance, and how a given store tends to run compared to its own average. It is cheap enough to run on every request. We tried heavier models too. They were not better, so we kept the simple one. ## After you order: a live ETA Once you place an order, the question changes from "how long does this store usually take?" to "how long is left on *this* order?". The live ETA splits the order into stages: waiting to start, cooking, waiting for pickup, and the ride. ![The four stages of an order and the signals that drive each one](https://blog.laayo.com.np/media/seed/eta-stages.svg) For each stage we keep a curve of how long that stage has taken in the past, per zone. The trick is that we ask a conditional question. If an order has already been cooking for longer than usual, the answer is not "almost done". Some kitchens are slow today. The curve tells us the typical remaining time *given that the stage has already run this long*, and that is what we show. Cooking time is adjusted per store, per hour and per day of the week, because the same kitchen at a busy weekend lunch is a different kitchen from a quiet weekday afternoon. ### Trusting GPS over taps The ride is where live data helps most, and also where we learned the most humbling lessons. Riders mark their progress by swiping in the rider app: arrived at the store, picked up, arrived at the customer, delivered. We assumed those swipes were accurate. They often are not, and for understandable reasons. The app only unlocked the "Delivered" swipe after "Arrived", so many riders swiped "Arrived" while still standing at the restaurant, just to have it out of the way. Some marked "Picked up" at the customer's door. If we believed those swipes, your app would say "Rider has reached your location" while the rider was still waiting for your momo. So the live ETA now treats GPS as the truth and swipes as hints: - Arrival at your door counts when the rider's location is actually close to it, not when the swipe happens. - "Picked up" is confirmed by the rider having really been near the store. - A swipe that would have needed a superhero ride speed to be true is ignored. - Location fixes that are too old, or obviously broken, are left out. ### A promise, and a straight answer when we miss it When you place an order we save the time we quoted. If the live prediction later moves clearly past that promise, the app says so plainly: "Delayed by" and the minutes. An order that is badly stuck says "Taking longer than usual" instead of counting down a number nobody believes. ## Learning as we go Regularly, the system looks back at finished deliveries and refreshes its curves and its ride model. It learns on the older part of the history and tests itself on the most recent part it has not seen, so we always know how good the estimate really is instead of how good it looks on data it memorised. Two details make that learning honest. The arrival time it learns from comes from GPS, not from the "Delivered" swipe, which is often late. And road distance is used as road distance. An early version multiplied it again as if it were a straight line, which quietly padded longer rides. The estimate is least certain at the moment you place an order, and much of that uncertainty belongs to the kitchen. Once the rider has your food, it tightens a lot, and that is where the live ETA earns its keep. ## Smooth on the map, too An ETA that is right but a rider icon that jumps around still feels wrong. In our upcoming app update, the rider marker on the tracking map glides between location updates instead of hopping. The glide speed adapts to how often updates are arriving, so the marker is always moving. It follows the road line when it is close to the route, and the route line shrinks behind it as the rider gets closer. ## What we are working on The biggest source of error left is not the ride. It is the time food waits at the counter for a rider. That is a supply problem as much as a prediction problem, and it is where most of our effort is going next. A better estimate tells you the truth. A shorter wait changes it. --- # Joining Laayo as a restaurant partner, rebuilt from the counter up > Signing up a restaurant used to mean a long form and a lot of back and forth. We rebuilt it as eight short steps that ask the questions we would ask in person, with samples for every photo and document. - Source: https://blog.laayo.com.np/joining-laayo-as-a-restaurant-partner - Section: Company - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: October 8, 2026 - Topics: Partners, Restaurants, Onboarding Most of the restaurants on Laayo were signed up the same way: someone from our team stood at the counter, chatted with the owner between orders, and filled in the details together. That works, and it is still one of our favourite parts of the job. But it does not scale, and it does not help the restaurant owner who hears about Laayo from a friend late at night and wants to apply right then. So we rebuilt the **Partner with Laayo** sign-up in the customer app around a simple idea: ask the same questions we would ask at the counter, in the same order, in plain words. ## Eight short steps The new sign-up is split into eight steps. Each one fits on a phone screen and can be finished quickly. 1. **Your restaurant.** Name, address, whether you serve veg, non-veg or both, and a pin on the map. The pin works exactly like choosing a delivery address in the app, with search and nearby places, so you can drop it right on your door. 2. **Photos and preparation time.** A cover photo, a logo, a few photos of the shop and your menu. We also ask how long a typical order takes to prepare. You tell us the kitchen time, and we add a fixed allowance for the ride, because delivery is on us. 3. **Opening hours.** The same hours every day, or different hours for each day. Late night kitchens can set hours that run past midnight. 4. **Your team.** Who works at the shop and the numbers riders should call when they arrive, so the rider is not left ringing the owner's personal phone during service. 5. **PAN.** Your PAN or VAT certificate. Nepal PAN does not expire, so we no longer ask for an expiry date. 6. **Payouts.** Where you want to be paid: pick your bank from the full list of banks, add a Fonepay QR, or both. You can also choose to add this later. 7. **Commission.** The commission you are comfortable offering. It is a starting point for a conversation, not a final contract. 8. **The owner.** Your name and contact details. At the end you see a summary of everything, with an Edit button on each section, and then a short "what happens next" screen so you are never left wondering. ![The partner sign-up in eight steps: restaurant details, photos and prep time, opening hours, team, PAN, payouts, commission and owner, followed by a review by our team and going live.](https://blog.laayo.com.np/media/seed/partner-signup-steps.svg) ## Samples for everything The most common reason an application stalled used to be a photo. A blurry menu, a PAN certificate photographed at an angle, a cover photo that was actually a poster. So next to every upload there is now a **Show sample** button. It shows what a good photo looks like and a short list of do's and don'ts: - **Cover and logo** samples show how they will actually appear in the Laayo app, next to real dishes. - **Shop photos** show a clear counter, kitchen and seating area. - **Menu** samples show a flat, well lit page you can read from edge to edge. - **PAN certificate** and **Fonepay QR** samples are clearly stamped SAMPLE, so nobody uploads the example by mistake. For owners who prefer to watch rather than read, the first screen also links to a short video that walks through the application. ## Small details that mattered Some of the changes were tiny, and still made a real difference: - **The keyboard opens on letters.** On iPhones, one of our name fields used to open the number pad. It now opens the normal keyboard everywhere in the app. - **Leaving is safe.** If you start the form and tap back, a friendly sheet asks whether you want to keep going or leave, instead of quietly losing your progress. - **Menus can be files.** If your menu is a PDF or a set of pictures, you can upload those directly. - **Packaging charges are asked up front.** If you charge extra for packaging, once per order or per item, you can tell us during sign-up rather than finding out later that it was never set. ## What happens after you apply As soon as you submit, you get a text message and an email confirming that we have received your application. We were careful with the wording here. An earlier message said something close to "you're all set", which made some owners think they were already live. The new message says clearly that the application has been received and that our team will be in touch. On our side, the application lands in a review queue with all of your answers on one card: how many menu files you sent, whether opening hours and payouts are set, and how many staff you added. Your menu files are filed straight into your restaurant's documents, so our team can start setting up your menu without asking you to send them again on chat. ## Signing up in person still works Our field team still visits restaurants, and they now carry the same flow in the Laayo admin app. They stand at your door, the location comes from their phone's GPS, and they can create your account on the spot. The app even generates a strong password with a copy button, so nobody has to invent one at a busy counter. One rule we care about: before anyone types a word, the form says what the button will do. Depending on the person's role, a restaurant either goes live straight away or is sent to the office for approval. Those are different promises to make to an owner, and it is only fair that our team knows which one they are making before they make it. ## Rolling out The new sign-up is rolling out with the latest version of the customer app, and our team is already reviewing applications through the new queue. If you run a restaurant or shop in Birtamod or Damak and want to reach more customers, open the Laayo app, tap **Partner with Laayo**, and give it a few minutes. If you get stuck on any step, the samples are there, and so are we. --- # Building lean: how engineering choices stretch every rupee > A small team running several products has to be careful with money and time. The engineering habits that keep our costs low without cutting corners on reliability. - Source: https://blog.laayo.com.np/building-lean - Section: Investors - Author: Laayo Leadership (Laayo Services Pvt. Ltd.) - Published: October 7, 2026 - Topics: Engineering, Efficiency, Strategy, Infrastructure Capital efficiency is usually discussed in terms of marketing spend and headcount. For a technology company, engineering choices matter just as much. The wrong architecture can quietly eat money every month through cloud bills, third-party fees and the people needed to keep it running. We are a small team running a delivery marketplace, a membership, a payment platform and a point of sale. That only works because of a handful of deliberate choices. This post explains them for readers who are less interested in code and more interested in how the business stays efficient. ## Keep the core boring At the heart of Laayo is one well understood application that owns the business rules: orders, payments, payouts, support and the admin tools. We chose proven, widely used technology on purpose. Boring technology is cheap to run, easy to hire for and quick to debug. It means our engineers spend their time on features customers notice rather than on keeping an exotic system alive. We explain the details in [part one of our tech stack series](https://blog.laayo.com.np/tech-stack-part-one-foundation). ## Replace only what is slow When parts of the app needed to be faster, we did not rewrite everything. We measured which requests were used most and which were slowest, then rebuilt only those in Go, a fast and efficient language, while the rest stayed as they were. The new code runs in the shadow first, comparing its answers with the old code before it is trusted. If anything looks wrong, the old path answers instead. That approach gave us large speed gains on the busiest screens without a risky big-bang rewrite. You can read how in [part two of the series](https://blog.laayo.com.np/tech-stack-part-two-go-hot-path). ## Pay for value, not for convenience Third-party services are useful, but their bills grow with usage. We review what we pay for and ask whether each cost buys real value. One example: we found a single screen in the rider app that was asking a maps service for far more information than it used, and paying for all of it. Fixing it cut that cost dramatically without changing anything riders saw. The story is in [cutting maps costs](https://blog.laayo.com.np/cutting-maps-costs). The same habit applies elsewhere. We convert images to modern formats so they load faster and cost less to serve. We cache answers that do not change often. We reuse what we have already built across products. ## Own the tools that matter For monitoring and crash reporting, we run well established open source tools ourselves rather than paying per event to a hosted service. That gives us detailed visibility into every service and app at a predictable cost. It also means we see problems early, which is the cheapest time to fix them. [Part five of the series](https://blog.laayo.com.np/tech-stack-part-five-observability) shows what we watch. ![Where efficiency comes from: a boring core, targeted speed work, careful third-party spend, self-run monitoring and reuse across products](https://blog.laayo.com.np/media/seed/investor-lean-levers.svg) ## Build once, use many times Many of our tools serve more than one product. The payment handling we built for the Laayo app became the foundation for Qora. The billing flow serves both Qora and Laayo Biz. The same deploy scripts, monitoring and security practices protect every product. Every time we reuse something instead of building it twice, we save not just the build but years of maintenance. ## Habits that prevent expensive mistakes The most expensive engineering work is fixing something that broke in production. So we invest in habits that catch problems early: - **Test first, in a separate environment.** Every change is built and checked away from real customers before it ships. - **Ship with a way back.** Production changes go out through scripts that take a backup first, and every change comes with a way to undo it. - **Switch things off, not just on.** New features can usually be turned off in seconds without a new release. - **Think about security while building.** Each new feature is checked for the ways it could be misused before it goes live, not after. None of these are glamorous. Together they mean fewer late nights, fewer refunds and less time spent on repairs instead of progress. ## Small team, high leverage We do not measure ourselves by team size. We measure by what each person can ship and keep running. Clear ownership, good tooling and careful choices let a small team do work that would otherwise need a much larger one. That leverage matters for investors and partners because it means growth does not require costs to grow at the same rate. As we add towns and products, most of the platform comes with us already built, already monitored and already paid for. For the full technical picture, start with the [tech stack overview](https://blog.laayo.com.np/tech-stack). --- # Becoming a Laayo rider, from the first tap to the first order > We rebuilt how riders join Laayo. A short sign-up on the phone, a real person checking it, a practice order before a real one, and a selfie that keeps everyone safe. - Source: https://blog.laayo.com.np/becoming-a-laayo-rider - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 7, 2026 - Topics: Riders, Onboarding, Safety Most people who ride for Laayo find us the same way. A friend rides already, or they meet a Laayo rider waiting at a momo shop and ask how it works. The next step used to be a long form that felt like paperwork. We wanted joining to feel more like the app they would be riding with: short, clear and done on the phone. ## A sign-up that asks the right questions "Join as rider" in the Laayo app now opens a guided sign-up in a handful of short steps, with a progress bar at the top and a Back button that never loses what you typed. 1. **How you want to work.** Salary or freelance, and which town. People who want a salaried role can tell us the monthly salary they are hoping for. That is a starting point for a conversation, not a contract, and the real salary is always agreed with them directly. 2. **Your vehicle and time.** What you ride, whether you have a licence and a smartphone, which shifts suit you and how much delivery experience you have. 3. **Documents.** Photos of your ID and licence, with example pictures so you know what a clear photo looks like. 4. **Getting paid.** Your bank details for payouts, and an emergency contact in case anything happens on the road. 5. **Your account.** Phone number, password and a referral code if a friend sent you. The new sign-up is rolling out with the next customer app update. The server side is already live, so our team sees every answer on the rider's profile as soon as someone applies. ![From "Join as rider" to the first order: sign up, add payout details, wait for our review, practise in the training center, then take the first gig.](https://blog.laayo.com.np/media/seed/rider-onboarding.svg) ## A person reviews every rider Nobody rides for Laayo straight from a form. Someone on our team looks at each application, checks the documents, talks to the applicant and decides. For salaried riders, that conversation is also where we agree shifts and pay. For freelancers, it is where we explain gigs, work areas and how earnings show up in the app. This is slower than an automatic yes, and we think that is right. A rider walks up to customers' homes and carries their food and sometimes their cash. Customers and restaurant partners trust us to know who that person is. ## Practice before it is real The first order a rider ever sees should not be a hungry customer's dinner. The rider app has a **Training center** with a full practice order that runs through every step: the order request, checking distance and payout before accepting, waiting at the restaurant, checking items before pickup, collecting cash or confirming a digital payment, and marking the order delivered. Each step comes with a short note on what goes wrong when it is rushed. "Confirm the exact amount before handover." "A wrong final status is harder to repair than a short delay." These come from real support cases. Every one of them is a mistake someone made on a busy day, written down so the next rider does not have to learn it the hard way. ## A selfie at the start of the day Freelance riders take a quick selfie in the app before their first gig each day. The front camera shows an oval, waits until it sees a face inside it and captures it on its own after a moment. It takes a few seconds. It exists for one reason: the person on the road should be the person we approved. Accounts are personal, and lending one to a cousin for the evening is not allowed. The selfie makes that rule real without anyone standing at a gate checking IDs. Our team can review selfies later and follow up quietly if something looks wrong, without blocking a rider in the middle of a shift. Salaried riders, who we see in person every day, skip the selfie. ## The first day On the first day a new rider goes online, a few things help: - **The app explains itself.** The order card shows the restaurant, the drop area and the expected earning before you accept. - **GPS does some of the work.** When you reach the restaurant or the customer, the app can move the order forward for you, so a forgotten swipe does not leave a customer staring at the wrong status. - **Help is in the app.** Riders can chat with our team, raise a problem or check their payments without hunting for a phone number. ## What's next We want a rider's first week to feel supported, not sink or swim. We are working on checking in with new riders after their first few deliveries, and on clearer in-app tips for the questions new riders ask most. If you ride for Laayo and remember something that confused you on your first day, tell us. It will probably end up in the training center. --- # Refunds you can follow, and invoices you can keep > A refund is a promise, and promises about money need dates. A refund timeline on your order, and proper PDF invoices, are coming in the next update. - Source: https://blog.laayo.com.np/refunds-you-can-follow - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: October 6, 2026 - Topics: Refunds, Orders, Invoices, Support When an order goes wrong and we agree to refund you, there is a quiet stretch between "sorry, we'll refund you" and the money actually arriving. For a wallet refund that stretch is zero. For a refund to your bank or QR account it can be a few days. And during those days, the only way to know what is happening is to open a support chat and ask. That gap is exactly where people start messaging support with the same question: *has my refund gone?* Each of those messages is a customer who is already unhappy, waiting on hold to find out something we could have shown them. So we decided to show it. ## A refund timeline on your order In the next update, when a refund is agreed for one of your orders, the order page shows a small timeline above the rider details. ![The refund timeline: each step is marked with its time, and the expected date is shown from the start so you know when to expect the money.](https://blog.laayo.com.np/media/seed/refund-timeline.svg) It has the same steps every time: 1. **Refund started.** Our support team has agreed the refund and recorded where it is going. 2. **Processing.** The money is being sent. 3. **Refunded.** It has reached you. Each step that has happened is ticked and shows the date and time. From the very first step, the timeline also shows **when you should expect the money**, so you are not left guessing. As a rough guide, a refund to your Laayo Wallet is instant, a refund to a QR or the original payment method takes a few days, and a bank transfer can take a little longer. Every time a step changes, you get a notification. On the order history list, the card for that order gets a one line summary like *Refund on its way*, so you can see it without opening anything. If something blocks a refund, for example a bank account number that does not work, the timeline says so, in words, with the reason. A refund that silently fails is worse than one that says what went wrong. ### Why this is server driven The words on the timeline are written by our server, in English and Nepali, not built into the app. That matters for two reasons. First, the timeline is a promise about somebody's money, and if we ever word something badly we need to fix it the same day, not in the next app release. Second, Nepali and English put dates and times together differently. In Nepali, "बजे" comes after the time, so a translation that simply glues an English "at" between the date and time reads as nonsense. We format both languages properly. ### Wallet refunds get the timeline too A refund to your Laayo Wallet is instant, so it shows up already completed. We still show it the same way, because one consistent picture is easier to trust than two different ones. ## Invoices you can actually use The other money question we hear is from people who need a proper record: someone ordering lunch for an office, a small business buying supplies, or anyone who just likes to keep receipts. In the next update, every order gets two downloads: - **Order summary**, available on every order, delivered or not, with the items, charges, discounts and what you paid. - **Invoice**, available once an order is delivered, as a PDF in two parts: - the restaurant's invoice for the food, issued on their behalf with their PAN number, - Laayo's own invoice for the delivery and platform fee, shown only if there was one. Each invoice has a clear number that includes the Nepali fiscal year, so it is easy to file. Discounts are spread across the items properly, down to the paisa, so the columns add up exactly to what you paid. If there is a tiny rounding difference, it appears as its own line instead of hiding inside a total. We call it an **Invoice**, not a "Tax Invoice". Tax columns only appear when the restaurant actually charges tax on that order. We would rather a document be plain and correct than look official and be wrong. ## What we chose not to do - **No vague "some working days".** Every refund shows a specific expected date from the moment it starts. - **No refund status hidden inside a support chat.** The timeline lives on the order, where you would look for it. - **No invoice before delivery.** Until the food arrives, an invoice would describe a sale that has not happened. The order summary covers that time. - **No extra screens to choose a document.** The Download invoice button gives you the invoice, and the small download icon next to the bill gives you the summary. ## What's next Both features are coming in the next app update. Our goal is fewer moments where you have to ask us where your money is. If you ever do have to ask, the support team now sees the same timeline you do, so the answer is one glance away. --- # The story of Laayo so far > How a delivery app from Birtamod grew into a small platform: one town, then Damak, our own technology, a new look, payments software, a point of sale and native apps. - Source: https://blog.laayo.com.np/the-story-of-laayo - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 5, 2026 - Topics: Laayo, History, Birtamod, Damak Laayo is a food and grocery delivery app from Birtamod, Jhapa, run by Laayo Services Pvt. Ltd. This is the story of how it came to be what it is today, told in the order things happened. ## It began with a simple gap In Birtamod, ordering food used to mean calling the shop, describing your house by the nearest landmark and hoping the order arrived hot. Restaurants made excellent food but had no easy way to reach people beyond their phone line and front door. The big delivery apps were focused on the capital. Laayo started to close that gap at home. The idea was plain: let people order from the restaurants and shops they already love, and bring the order to their door with riders who know the town. We tell the longer version in [Why we started Laayo in Birtamod and Damak](https://blog.laayo.com.np/delivery-in-small-towns). ## Birtamod first Laayo's first home was **Birtamod**, and our office is still there, at New Kanchanjunga Tole. Starting in one town meant we could learn quickly. We saw how people describe addresses by landmarks, how lunch and dinner peaks feel on the road, and how the monsoon changes everything about delivery. From the start, Laayo used **its own riders** instead of handing delivery to someone else. That choice shaped a lot of what came later, from how we track rider locations to how we pay riders and partners. ## Then Damak Once Birtamod was running well, Laayo opened in **Damak**, a short ride away. Damak brought new partners, new streets and the same lesson: a delivery service has to be built around how a town actually works. Today Laayo delivers in Birtamod, the towns around it in Central Jhapa, and Damak. ## Building our own technology Very early, we decided to build and run Laayo's technology ourselves: the customer app, the rider app, the partner app, the admin tools and the backend. Owning the stack lets a small team move quickly and fix problems the same day. Over time we added a faster Go layer for the busiest parts of the app, realtime updates for order status, chat and store opening, and our own monitoring and crash reporting. The whole journey is in our five part series, starting with [Laayo's tech stack, part one: the foundation](https://blog.laayo.com.np/tech-stack-part-one-foundation). ## Payments built in Paying should be as easy as ordering. Laayo added **E-Payment** by QR, the **Laayo wallet**, and later **gift cards** that load into the wallet. Each step meant fewer cash hassles for customers and riders. See [Paying with a QR inside the app](https://blog.laayo.com.np/paying-with-a-qr-inside-the-app) and [Gift cards and Send a Treat](https://blog.laayo.com.np/gift-cards-and-send-a-treat). ## Laayo Plus For regular customers we introduced **Laayo Plus**, a monthly membership with delivery benefits and priority support. It rewards the people who order often and gives them a faster path to help. More in [What Laayo Plus gives you](https://blog.laayo.com.np/what-laayo-plus-gives-you). ## Laayo Biz and Qora Working closely with restaurants showed us two more needs. Restaurants wanted better tools to run the counter, the tables and the kitchen, so we built **Laayo Biz**, a point of sale that connects to the orders they receive on Laayo. Many businesses wanted to accept QR payments without complicated setup, so in **September 2026** we launched **Qora**, QR payment software for Nepali businesses. Qora never holds customer money; each merchant is paid directly by their own bank. ## A new look In **late September 2026**, Laayo moved to a new **wordmark**: "la" in charcoal next to a slanted charcoal badge holding "ayo" in yellow. The app icon and every Laayo website now use the new mark. Read about it in [What the Laayo name and logo look like](https://blog.laayo.com.np/what-the-laayo-name-and-logo-mean). ## Native apps and a new website In **October 2026** we began rebuilding the customer app natively, in **Swift** for iPhone and **Kotlin** for Android, screen by screen, so nobody would be logged out along the way. The rider and partner apps continue on Flutter. We also started a new, faster website for browsing restaurants on the web. Details in [Laayo's tech stack, part four: going native](https://blog.laayo.com.np/tech-stack-part-four-native-apps). ## This blog In **October 2026** we opened this blog to explain how Laayo works, for customers, partners, riders, engineers and investors. The [Investors page](https://blog.laayo.com.np/investors) collects our thinking about the business. ## What comes next We are working on Kathmandu, on more ways to help restaurant partners and on making every order faster and more reliable at home. We share plans, not promises, in [What comes next for Laayo](https://blog.laayo.com.np/what-comes-next). ## Quick answers ### Where did Laayo start? Laayo started in Birtamod, Jhapa, where the company is still based at New Kanchanjunga Tole. ### When did Laayo get its new logo? Laayo moved to its new yellow and charcoal wordmark in late September 2026. ### When was Qora launched? Qora, Laayo's QR payment software for businesses, launched in September 2026. ### Does Laayo build its own apps? Yes. Laayo designs, builds and runs its customer, rider and partner apps, its admin tools and its backend in-house. ### Which towns does Laayo serve? Laayo serves Birtamod, the surrounding towns of Central Jhapa, and Damak. Kathmandu is next, with no date announced. --- # A support assistant that knows when to hand over > Our AI assistant answers most support chats in seconds. The hard part was teaching it never to promise help that is not coming, and to bring in a person at the right moment. - Source: https://blog.laayo.com.np/support-assistant-that-knows-when-to-hand-over - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: October 4, 2026 - Topics: AI, Support, Chat Laayo's in app support chat is answered first by an AI assistant. For most questions that is exactly what people want: where is my order, how do I change my address, why was I charged a delivery fee, can I pay with E-Payment. The assistant reads the customer's live order data and our help articles, and it answers in seconds at two in the morning. But support is not a trivia game. Some chats need a person, and the worst thing an assistant can do is pretend it has called one. This post is about the mistake that taught us that, and how we rebuilt the assistant around one rule: never promise a human you have not actually called. ## The chat that waited A customer could not receive the verification code needed to change their phone number. The assistant suggested checking the country code. When that did not help, it said something like "I'll escalate this, hang tight." Nobody was alerted. At the time, the assistant had no way to bring in a person at all. The phrase came from our own help articles, which had been written for an older setup where escalation was real. The model read those articles, saw that escalating was the right move, and said so. A team member found the chat by chance many hours later. Two lessons came out of that chat. **The model will repeat whatever promises your documents make.** If your help content says "I will connect you to an agent", the assistant will say it, whether or not that is possible. We rewrote every scenario in the knowledge base so that escalation means a concrete, real action, and we added an explicit rule against phrases such as "the team will review this" or "hang tight" unless a handover has actually started. **Check what the model really sees.** Our knowledge base had grown longer than the amount of text we actually sent to the model. Everything past a certain point, including several important policies, was being cut off before the model ever read it. We now treat the size of the prompt as something to test, not something to assume, and the most important rules sit at the top. ![How a support chat moves between the assistant and our team](https://blog.laayo.com.np/media/seed/support-handover.svg) ## A handover that is real The new design makes handing over an action, not a sentence. When the assistant decides a chat needs a person, for example a refund dispute, a missing item it cannot verify, or a customer who simply asks for a human, it writes one short line and a special marker. The server sees the marker and does three things at once: it posts "Please wait while I connect you to an agent" into the chat, it marks the conversation as waiting, and it sends a loud alert to the support team's Admin App. When a team member opens the chat, the customer sees that they have joined, by first name. The server also watches the conversation for signs that a person is needed, independently of the model: - **Asking for a human,** in English, in romanized Nepali and in Nepali script. - **Sounding upset,** with a second look before acting, so a joke does not trigger an alarm. - **The assistant promising a follow up** it cannot deliver, which is now treated as a bug to catch, not a sentence to send. ## Tickets without a second inbox Once more chats reached people, our team had a new problem: too many conversations to read. So we added tickets, with one firm design rule. A ticket is a view onto the chat, not a second thread. The customer always replies in the same chat, and the team always replies there too. Some reasons open a ticket at once. Others, like a customer using a strong word, go to the assistant first, which reads the whole chat and decides. In testing, a customer joking that a dish was "the worst, I loved it" was left alone, while "the rider took my cash" became a ticket immediately. When a ticket opens, the assistant writes a brief for the team: a subject, a category, a priority and the order it is about. It can raise the priority but never lower it, and any order it links is checked to make sure it really belongs to that customer. The team member opening the ticket sees a summary at the top, instead of scrolling through twenty messages to find out what happened. The ticket view and the handover flow are rolling out to our support team now. ## Speaking the customer's language Many of our customers write in Nepali, in Nepali script or in Nepali typed with English letters, and many switch between them in the same message. The assistant now follows the language the app is set to, or the language the customer writes in when they have not chosen one. Fixed sentences that our server adds, such as order status summaries, are translated with the respectful form of address and cached, so the same sentence is not translated again and again. One small detail took longer than expected: a price written in rupees inside an English sentence must not make the system decide the customer is writing in Nepali. ## Turning complaints into reports When a customer describes a real problem with an order, the assistant can file it as a proper order report, the same kind a customer could file from the order screen. It always asks first and files only after the customer confirms. If the problem needs a photo, such as a damaged package, the assistant opens the report screen for the customer with the reason already filled in, because a photo is evidence our team needs to see. ## Learning from what it could not answer Every night, a job looks at the questions the assistant could not match to anything on our menus, such as a local spelling of a dish or a nickname for a restaurant. It maps them onto the real dishes and stores them as search synonyms. That makes the assistant better, and because the same synonyms feed normal search, it makes the search box better too. ## What's next We are measuring how often a chat ends with the customer's problem solved, with or without a person, and how long people wait for a human once a handover starts. Those two numbers, not the number of chats the assistant closes, are how we will judge it. --- # Getting help on Laayo > How to contact Laayo support by chat, phone or email, what to do when something is wrong with an order, and where to find answers on the Help Center. - Source: https://blog.laayo.com.np/getting-help-on-laayo - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 3, 2026 - Topics: Guides, Support, Help Something wrong with an order, a question about a payment, or just want to talk to a person? This guide lists every way to reach Laayo and when to use each one. ## How do I contact Laayo customer support? | Channel | Best for | How | |---|---|---| | Support chat in the app | Anything about a specific order | Open the order and tap Help, or go to Support in the app menu | | Phone | Urgent problems with a live order | Call **9707055875** | | Email | Account questions, refunds, partnership and business | **support@laayo.com.np** | | Help Center | Answers to common questions | [support.laayo.com.np](https://support.laayo.com.np) | ## What is the fastest way to get help with an order? Use the support chat from inside the order. It already knows which order you mean, so you do not have to explain it again. You can attach photos, for example of a wrong or damaged item, which helps us sort things out faster. The chat starts with the Laayo AI assistant, which can answer many questions on the spot, such as where your order is or how a refund works. When your problem needs a person, it hands the chat to our support team with the whole conversation, and a team member replies in the same thread. Read [The support assistant that knows when to hand over](https://blog.laayo.com.np/support-assistant-that-knows-when-to-hand-over). ## What should I do if my order is late? Open the order to see its status and, once it is picked up, the rider on the map. If the app shows the order as delayed, it means it is running behind the time we expected. You can message the rider or the restaurant from the order. If you are worried, open support chat or call **9707055875**. ## What should I do if something is wrong with my food? 1. **Take a photo** of the problem, such as a missing item, wrong item or spillage. 2. **Report it from the order.** Open the order, tap Help, and choose the problem. 3. **Tell us what you would like.** A refund for the item, a replacement or something else. Please report problems soon after delivery so we can check with the restaurant while the details are fresh. ## How do refunds work? When we approve a refund, you can follow it step by step in the app, from approval until the money reaches your wallet or your original payment method. Read [Refunds you can follow](https://blog.laayo.com.np/refunds-you-can-follow). ## How do I report fraud or misconduct? If a restaurant, rider or anyone claiming to be Laayo behaves dishonestly, for example asking for extra money or for your bank details, report it. From a running order you can choose to report the restaurant, or email **fraud@laayo.com.np**. Laayo never asks for your bank PIN or password. ## How do restaurant partners and riders get help? Restaurant partners can raise tickets from the Laayo partner app and contact their local Laayo team. Riders have support inside the rider app. Both can also call **9707055875**. Read [Help when you need it](https://blog.laayo.com.np/help-when-you-need-it) for how our support desk works. ## Does Laayo Plus get faster support? Yes. Laayo Plus members are answered first in support chat. See [What Laayo Plus gives you](https://blog.laayo.com.np/what-laayo-plus-gives-you). ## Quick answers ### What is the Laayo customer care number? Call Laayo support on 9707055875. For anything about a specific order, the in-app support chat is usually fastest. ### What is Laayo's email address? Email support@laayo.com.np for account questions, refunds, partnerships and business enquiries. ### Is there a Laayo Help Center? Yes. The Laayo Help Center at support.laayo.com.np answers common questions about orders, payments and accounts. ### Can I talk to a real person? Yes. The in-app chat starts with an AI assistant, which passes your chat to the support team when a person is needed. You can also call 9707055875. ### How do I report a problem with my food? Open the order, tap Help, choose the problem and attach a photo. Report it soon after delivery. --- # The Laayo name, logo and colours > What the Laayo wordmark looks like, how to write the name, which colours belong to the brand and how the logo should and should not be used. - Source: https://blog.laayo.com.np/what-the-laayo-name-and-logo-mean - Section: Design - Author: Laayo Design (Laayo Services Pvt. Ltd.) - Published: October 3, 2026 - Topics: Brand, Logo, Design This page explains the Laayo brand in plain words: how to write the name, what the logo looks like, which colours we use and where to get the official files. If you are a partner, a journalist or simply curious, this is the reference. ![The Laayo wordmark: "la" in charcoal beside a slanted charcoal badge with "ayo" in yellow, the compact app mark, and the two brand colours.](https://blog.laayo.com.np/media/seed/laayo-brand-sheet.svg) ## How to write the name The name is **Laayo**: capital L, then "aayo", one word. Please do not write it as "LAAYO", "La Ayo" or "Laayo App". When you need to be precise about the company, use **Laayo Services Pvt. Ltd.** Our products follow the same pattern: **Laayo Plus**, **Laayo Biz** and **Qora by Laayo**. ## The wordmark Laayo's logo is a **wordmark**, a logo made of the name itself. It has two parts: - **"la"** written in charcoal. - A **slanted charcoal badge** that holds **"ayo"** in Laayo yellow. The slant gives the mark a sense of movement, which suits a delivery service. The badge makes the logo recognisable even when it is small. Laayo adopted this wordmark in **late September 2026**. It replaced an earlier picture logo everywhere: the apps, the websites, emails and documents issued since then. ## The app mark Where the full wordmark would be too small, such as a browser tab, we use a **compact mark**: the yellow "a" from the badge on a charcoal rounded square. Phone launcher icons use the full wordmark on yellow, because a home screen has room for it. **Laayo Plus** has its own icon variant: the wordmark on **Plus gold** with a small crown, so members can tell it apart. ## Colours Laayo has two main colours and a small supporting set: | Colour | Hex | Used for | |---|---|---| | Laayo yellow | #FFD60A | Buttons, highlights, the badge in the logo | | Charcoal | #263238 | Text, the "la" in the logo, dark backgrounds | | Plus gold | #F2B705 | Laayo Plus only | Red is not a Laayo brand colour. We use it only for warnings, errors and "closed". The thinking behind this is in [Designing Laayo in yellow](https://blog.laayo.com.np/designing-laayo-in-yellow). **One rule matters more than the rest:** yellow is a fill colour, not a text colour. Yellow text on a white background is hard to read, so we always put charcoal text on yellow, never yellow text on white. ## Typeface Laayo's apps and websites use **Lexend**, an open-licence typeface designed for easy reading. It is friendly, clear at small sizes and works well for both English and numbers on receipts and menus. ## Using the Laayo logo If you are a restaurant partner, a journalist or an event organiser, you are welcome to use the Laayo wordmark to refer to Laayo. A few simple rules: - Use the **official files** from our [Investors page](https://blog.laayo.com.np/investors#contact), not a screenshot. - Use the **light background** version on white and light colours and the **dark background** version on dark colours. - Do not stretch, recolour, rotate or add effects such as shadows and glows. - Leave clear space around the logo so it can breathe. - Do not use the logo in a way that suggests Laayo endorses something it does not. For anything beyond this, write to us through the [Investors page](https://blog.laayo.com.np/investors) form and choose "Press and media". ## Quick answers ### What does the Laayo logo look like? It is a wordmark: "la" in charcoal next to a slanted charcoal badge with "ayo" in yellow. The compact app mark is the yellow "a" on a charcoal rounded square. ### What are Laayo's brand colours? Laayo yellow (#FFD60A) and charcoal (#263238). Plus gold (#F2B705) is used only for Laayo Plus. ### When did Laayo change its logo? Laayo adopted its current wordmark in late September 2026. ### Which font does Laayo use? Laayo uses Lexend, an open-licence typeface designed for readability. ### Where can I download the Laayo logo? The official wordmark files, for light and dark backgrounds, are linked under Brand assets on the Investors page of this blog. --- # One kitchen, many brands > More of our partners run several restaurant brands out of one kitchen. Here is how the partner app lets one owner switch between them, and how customers can see which brands share a kitchen. - Source: https://blog.laayo.com.np/one-kitchen-many-brands - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: October 2, 2026 - Topics: Restaurants, Partner app, Multi-brand A familiar story in our towns: a café does well, the owner notices that late-night orders are mostly fried chicken and noodles, and a few months later there is a second name on Laayo, cooked in the same kitchen by the same team. Sometimes it is a cloud kitchen with no dining room at all. Sometimes it is a second restaurant across the road. From a business point of view, these are separate restaurants. Each brand has its own menu, its own ratings and its own money. From the owner's point of view, it is one phone, one kitchen and one very busy evening. Our partner app used to only understand the first view. ## Separate on purpose There were two ways to model this. One is a single owner account that holds several stores. The other is several owner accounts, one per brand, linked together. We chose the second. Each brand keeps its **own wallet and its own payouts**, which is what most owners want. One brand might be a partnership with a friend, or simply have its own bank account. Mixing money between brands is a mistake that is easy to make and painful to unpick, so we built the system so it cannot happen by accident. Linking is done by our team, not by the partner. When an owner asks, someone at Laayo checks that the accounts really belong to the same person and links them. Unlinking is just as easy. ![Two brands keep their own menus, ratings and payouts. Linked accounts let the owner switch in the partner app and let customers see sister brands from the same kitchen.](https://blog.laayo.com.np/media/seed/multi-brand.svg) ## Switching in the partner app In the partner app, the top bar shows the name of the restaurant you are looking at. If your account is linked to others, a small arrow appears next to the name. Tap it and you see all your brands, each with an open or closed dot. Tap one and the app switches to it in a moment, without logging out. Getting this right took more care than the button suggests: - **Both brands keep ringing the same phone.** An owner switching to brand B still needs to hear brand A's new orders. Switching moves the phone's notifications to the new brand without removing the old one. - **Notifications say which brand.** When an owner has several brands, each new-order alert starts with the brand name, in the form "Brand name: You've got a new order", and tapping it opens the app on the right brand, switching for you if needed. - **Old orders do not leak across.** An early version kept the previous brand's running orders in memory after a switch, and the app kept trying to refresh orders that no longer belonged to the account it was showing. Switching now clears that state cleanly. We are bringing the same to staff accounts, so a kitchen manager who handles two brands can switch between them just like the owner, with each brand's permissions kept separate. ## What customers see Customers sometimes want to know that two restaurants share a kitchen. Maybe they love the momo from one brand and want to know where else that cook's food shows up. Maybe they just want to understand why two places look so similar. On a restaurant's page, we are rolling out a row that reads **"This is a multi-brand kitchen"** when the restaurant is linked to other brands. Tapping it shows the sister brands, open ones first, with the same restaurant card used everywhere else in the app. We made a few choices about what counts as a sister brand: - **Different names only.** Two branches of the same restaurant are outlets, not brands, so they are not listed here. - **Same kind of store.** A restaurant's sister brands are restaurants, not grocery shops the same owner happens to run. - **Live brands only.** A brand that is switched off or paused does not appear. ## Why we bothered Running several brands is one of the ways a good kitchen grows without a second building. We want Laayo to make that easier, not harder. One phone, clean money, and customers who can find your other food. ## What's next We are looking at a combined view for owners: today's orders across all their brands on one screen, while payouts stay separate. If you run more than one brand on Laayo and want your accounts linked, message us from the partner app and we will set it up. --- # A day in the Laayo rider app, from going online to getting paid > What a Laayo rider sees and does in the rider app over a normal shift. Going online, gigs, taking an order, pickup, delivery, cash, earnings and getting help. - Source: https://blog.laayo.com.np/laayo-rider-app-tour - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: October 1, 2026 - Topics: Riders, Rider app, Guides Laayo riders spend their whole shift with one app open: the **Laayo rider app**. This guide follows a normal day in it. If you are thinking about riding with us, read [becoming a Laayo rider](https://blog.laayo.com.np/becoming-a-laayo-rider) first, and for pay, see [how riders earn at Laayo](https://blog.laayo.com.np/how-riders-earn-at-laayo). ## How do I start my shift? 1. **Check in.** Freelance riders take a quick selfie at the start of the day so we know the person on the bike is the person on the account. It takes a moment and protects riders and customers alike. 2. **Pick your gig.** Freelance riders book gigs, which are slots in a work area, ahead of time. Going online is tied to a gig, so the app knows where you plan to be. Salaried riders follow the shifts agreed with our team. See [gigs for riders](https://blog.laayo.com.np/gigs-for-riders). 3. **Go online.** One switch. From then on the app shares your location while you work, so dispatch can offer you nearby orders and customers can follow their delivery. ![A rider's day in the app: check in, book a gig, go online, accept, pick up, deliver, then see earnings and cash in hand.](https://blog.laayo.com.np/media/seed/rider-day.svg) ## How do I accept an order? A new order arrives with a loud alarm and a clear card: the restaurant, the drop area, the earnings estimate for the trip and whether the customer pays in cash. Accept it and the app guides you to the restaurant. The alarm keeps going until you respond, because a missed order is the worst outcome for everyone. We wrote about that in [order alerts riders cannot miss](https://blog.laayo.com.np/order-alerts-riders-cannot-miss). ## What happens at the restaurant? - The app shows the order items so you can check the bag before you leave. - If the food is not ready, you can see the kitchen's progress and chat with the restaurant. - Confirm pickup in the app when you have the order. Your arrival at the restaurant is also picked up automatically from your location, so a forgotten swipe does not hold things up. ## What happens at the customer's door? The app shows the address pin, the landmark the customer gave and any delivery notes, with a call and chat button for the customer. When you reach the door, mark the order delivered. For cash orders, the app shows exactly how much to collect, including the full bill when a customer asks to see it. ## How does cash work? Cash you collect is tracked in the app as **cash in hand**. You can see what you are holding at any time and deposit it with Laayo as agreed with our team. Keeping cash in hand within limits lets you keep taking cash orders. ## Where do I see my earnings? The **My Earning** screen shows what each trip paid, tips customers left for you, and your totals over the day, week or month. What the order card estimated before you accepted is what you are credited, so there are no surprises later. Tips always belong to the rider. ## How do I get paid? Earnings go to your wallet in the app, and payouts go to the bank account you added at sign up. The app shows every payout and any deduction, with a clear statement. ## What else is in the rider app? - **Rain mode.** Riders can report that it is raining in their zone, which tells customers to expect a little longer and adds care to how orders are planned. See [riding through the monsoon](https://blog.laayo.com.np/riding-through-the-monsoon). - **Fuel requests**, rolling out for riders who need fuel support on a shift. - **Training center** with a practice order, so new riders learn the flow before a real customer is waiting. - **Refer a friend.** Riders can invite friends to ride with Laayo with their own referral code. - **Leave requests** for salaried riders. - **Benefits** information our team sets up, such as insurance details. - **Grievances.** Riders can raise a problem, or dispute a deduction, in a threaded conversation with our team. ## How do I get help during a delivery? Use the chat on the order, call Laayo support from the app or raise a grievance for anything that needs a proper answer. For anything urgent on the road, call our team straight away. ## Quick answers ### Do I need to book a gig to go online? Freelance riders go online for a gig they have booked. Salaried riders work the shifts agreed with Laayo. ### Why does the app ask for a selfie? The daily selfie confirms that the registered rider is the one riding today, which keeps customers, restaurants and riders safe. ### Do customers' tips go to the rider? Yes. Tips go to the rider and show up on the My Earning screen. ### What if I disagree with a deduction? Open it in the app and choose to dispute it. It becomes a grievance thread with our team. ### Can I practise before taking real orders? Yes. The training center has a practice order that walks through the full flow. --- # Designing Laayo in yellow > A new wordmark, two colours, one typeface and a handful of rules about motion and loading. How we are making every Laayo screen feel like the same calm, fast app. - Source: https://blog.laayo.com.np/designing-laayo-in-yellow - Section: Design - Author: Laayo Design (Laayo Services Pvt. Ltd.) - Published: October 1, 2026 - Topics: Brand, Typography, Motion, Design system A delivery app is used in small, impatient moments. You open it hungry, you scroll for a minute, you pay, and then you glance at it every few minutes until the food arrives. In those moments, nobody admires a gradient. What people notice is whether the app feels quick, whether it is clear what to tap, and whether it ever makes them feel unsure. This autumn we reworked how Laayo looks and moves. Here is what changed and the thinking behind it. ## A new wordmark At the end of September we introduced a new logo. It is a wordmark: "la" in charcoal, followed by a slanted charcoal badge with "ayo" in yellow. The slant gives it a sense of motion without drawing a scooter, a rider or a parcel. Those pictures date quickly, and they all look alike across delivery apps. The wordmark now appears everywhere: the app icon, the websites, emails and receipts. For small spaces like a browser tab we use a compact mark, a single yellow "a" from the badge on a charcoal rounded square. It stays readable at the smallest sizes, where a full wordmark becomes a smudge. The rider app keeps its own helmet mark on yellow, so when a rider glances at their phone mid-ride it is instantly clear which app is buzzing. ## Two colours, used with discipline ![The Laayo palette and type scale](https://blog.laayo.com.np/media/seed/laayo-palette.svg) Laayo is **yellow #FFD60A** and **charcoal #263238**. Almost everything else is neutral. - **Yellow is for filling, not for writing.** Main buttons, the selected tab, highlights and badges get a yellow fill with charcoal text. We never put yellow text on a white background. It looks bright on a designer's monitor and disappears on a cheap phone in afternoon sun. - **Charcoal is our ink.** Headings, links and important text use charcoal, not pure black. It is softer on the eye and pairs with the yellow. - **Gold #F2B705 belongs to Laayo Plus.** Members can tell their perks apart at a glance. - **Red is only for danger.** Delete, cancel, errors, a required field, a closed store. If red appears on a Laayo screen, something needs your attention. We do not spend it on decoration. That last rule sounds small, but it took the most effort. Food apps love red, and it kept creeping into our screens through reference designs and old components. Each time we found it we replaced it, because a colour that means "danger" cannot also mean "tasty". ## One typeface: Lexend For the apps and the website we use **Lexend**, an open licence typeface designed around readability research. It has open letter shapes, generous spacing and a tall x-height, which means small text like prices, delivery times and item descriptions stays clear on small screens. We tested a wide range of open licence fonts against the look we wanted, measuring how closely their shapes matched at real app sizes. Lexend came out on top and also has a full set of weights, so one family covers everything from a bold restaurant name to a light caption. Because Lexend sets slightly wider than our previous font, we scaled our type sizes down by a small factor in one central place, so every screen kept its layout without anyone retuning hundreds of sizes by hand. ## Status without the pastel A common pattern in app design is the status pill: a soft pastel background, text in a darker shade of the same colour, and a border in a third shade. "Delivered" in green on light green. "Pending" in amber on light amber. It is everywhere, and at small sizes the three tints blur together. We do not use it. A status on Laayo is either: - **Typographic:** a small coloured mark, like a tick or a dot, next to a plain charcoal label. Bold for an outcome, lighter for something still waiting. - **A solid badge:** a fully saturated fill with white bold text, used only when a status has to stand out in a busy list. ## Loading that feels like progress Nothing makes an app feel slower than a blank screen with a spinning circle in the middle. We replaced generic spinners with two things: - **For a full page:** the outline of the page appears first, a soft skeleton of where the photos and text will be, with a short food line and a thin two-arc Laayo loader floating above it. You can already see the shape of what is coming. - **For a small section inside a page,** like a row of restaurants on the home screen, a plain shimmer, so the rest of the page is usable while one row fills in. Pull to refresh uses the same two-arc loader in a small round badge. One loading language, everywhere. ## Motion that gets out of the way We are moving the customer app to fully native code on iPhone and Android, and motion was one of the reasons. Native gives us the system's own physics: - **Swipe back from anywhere** on the screen edge, following your finger. - **Sheets that spring** up and can be dragged down to dismiss. - **Shared transitions** where a restaurant card lifts slightly and becomes the restaurant page, with the header already filled in from the card, so only the menu needs to load. - **High refresh rate** where the phone supports it. Just as important is what we removed. No bouncing or shrinking buttons on press. A row dims slightly when you touch it and a button fades a little. That is enough to say "got it" without making the screen feel jumpy. Everything respects the system's Reduce Motion setting. ## Calm haptics Vibration is the easiest way to make an app feel nervous. An early version of one of our screens buzzed again and again during an animation and once more at the end. It felt rushed. Our rule now: **at most one gentle haptic per deliberate action.** A tap, an add to cart, a send. A slightly firmer one only for a real commitment, like placing an order. Never a haptic tied to an animation, a timer or something arriving in the background. Your phone should only tap your hand when you did something. ## What we are not doing We are just as clear about what Laayo should not look like: no floating 3D emoji, no purple night-sky gradients, no glows, no novelty display fonts, no pastel cards tilting at angles. Those are easy to make and they make every app look the same. Our screens use real food photos, flat colour, thin hairline borders and our own illustrations. The goal is not for anyone to notice the design. It is for them to notice that Laayo feels quick, clear and calm, and that their food is on the way. --- # What Laayo Plus actually gives you > Free deliveries, chats that are answered first, a bigger daily allowance for the AI assistant, and a cart that shows exactly what Plus saved you. Here is how each benefit works and the rules behind it. - Source: https://blog.laayo.com.np/what-laayo-plus-gives-you - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: September 30, 2026 - Topics: Laayo Plus, Membership, Delivery, Support Membership programmes have a reputation problem. Too many of them promise "exclusive benefits" and then hide the real value behind conditions nobody reads. When we designed Laayo Plus, we set ourselves one test: a member should be able to explain, in one sentence each, what they get. And the app should show them, order by order, what it was worth. This post walks through every Plus benefit and the rules we put around it. ## Free delivery on your regular orders The headline benefit is simple to say: **free delivery on a set number of orders every month, for proper meals within a normal delivery distance.** The exact terms are always shown on the Plus page in the app. Each part of that is there for a reason. - **A set number each month** keeps the plan honest for us and predictable for you, and it resets every month. - **A minimum order** means free delivery is for a real meal, not a single tea. - **A distance limit** covers most of Birtamod and Damak from most restaurants. Longer rides cost riders more fuel and time, and we would rather pay them properly than quietly shrink the benefit. Behind the scenes, Plus free delivery joins the same "pick the best deal" logic as every other delivery offer. If a restaurant is already running its own free delivery, or a coupon would save you more, you get the better one and your Plus delivery is not used up. A member should never be worse off for being a member. There is one more rule we are strict about. If the app cannot work out the distance for an order, for example because a pin is missing, Plus free delivery does not apply. Guessing in your favour sounds generous, but guessing wrong on a long ride is how a plan like this stops being sustainable. ## Priority support When something goes wrong with an order, the minutes you spend waiting in a chat feel much longer than the minutes you spent waiting for food. So Plus members go to the front of the support queue. When a member opens a chat, our support team sees it marked as a Plus chat and it is answered before others waiting. If the problem is serious, the team is alerted straight away. You will see a small **Plus priority** tag on your support chat in the next app update. The priority itself already works. ## More from the AI assistant Laayo has an AI assistant you can chat with, and a voice assistant you can talk to, to find food, ask about an order or get suggestions. Both have a daily allowance, so the assistant stays fast for everyone. Plus members get a larger daily allowance for chat messages and voice minutes. If a free user reaches the daily limit, the assistant says so plainly and mentions what Plus would give them, once, without nagging. ## Seeing what you saved The worst thing a membership can do is make you wonder whether it is worth it. So the cart shows your Plus savings on every order, as a line you can read at a glance: the delivery saving and any other Plus saving written side by side. We deliberately split the amounts instead of writing "including", because "including" makes people do maths at checkout. Every saving is also recorded against your membership, once per order, so a retried checkout can never count the same saving twice. ## Coupon codes for Plus Sometimes we give Plus away: to partners, to people who helped us test, or as part of a campaign. For that, members and non-members can redeem a **Plus coupon code** from the Memberships & Rewards section of the menu. Enter the code and the membership starts at once. If you already have Plus, the extra time is added after your current term instead of overlapping it, so a code is never wasted. ## Paying for Plus You can join with E-Payment or straight from your Laayo Wallet balance. We made sure the wallet option appears both on the Plus page and on the offer you see on the home screen, because people kept finding one and not the other. ## What we chose not to do - **No "unlimited" claims.** Unlimited free delivery sounds great on a banner and ends with quiet limits added later. A fixed monthly number is one we can keep. - **No benefits that only exist on paper.** Every benefit on the Plus page is wired into how an order is priced or how support works. If we cannot measure it, it is not on the list. - **No automatic popups to upgrade.** You will see Plus where it is relevant, like on a delivery fee or when you hit an assistant limit, not in a modal every time you open the app. ## What's next We will keep adjusting Plus as we learn what members use. If a benefit is not pulling its weight, we would rather replace it than pad the list. If you are a member and something about Plus is confusing, tell us in a support chat. You will be answered first. --- # A home screen that changes with the day, without an app update > Festival banners, animated hero cards and section-by-section call-to-action banners are now set up by our team in the admin panel and drawn by the app. Here is how we keep them fresh, local and smooth. - Source: https://blog.laayo.com.np/a-home-screen-that-changes-with-the-day - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: September 30, 2026 - Topics: Home, Banners, Animation, Admin The top of the Laayo home screen is the most valuable space we have. It is the first thing you see when you open the app, and it is where a Dashain feast, a new restaurant opening in your town or the Laayo Plus offer should live. For a long time that space was a carousel of flat images. Each new banner meant someone designing an image, exporting it at the right size, uploading it, and hoping it looked sharp on every phone. Anything that moved meant an app update. Banners stayed up long after the moment had passed, because taking them down was another task on someone's list. Over the last few months we turned that space into something our team controls from the admin panel, and that the app draws itself. ## Banners that know when and where to appear Every banner now has a schedule. Our team sets a start and an end, and the server only sends a banner to the app while it is inside its window. A festival banner can be set to appear when the festival begins and leave on its own when it ends. The schedule is in Nepal time, so "starts tomorrow" means tomorrow here. Banners are also tied to a delivery zone. A restaurant opening in Damak is announced to people in Damak, not to everyone. While building this we found that a general type of banner was being shown in every zone, so we fixed the zone filter to apply to every kind of banner. Our team can pin a banner to the front of the carousel. Everything that is not pinned is shuffled each time the carousel loads, so restaurants with banners share the best position fairly, and the home screen looks a little different each time you open it. ![Banners are scheduled, targeted and ordered on the server, then drawn by the app](https://blog.laayo.com.np/media/seed/home-banners-flow.svg) ## Animation the app draws itself For the hero card, we wanted motion without heavy video and without an app release for every new idea. So we built a small animation builder in the admin panel. Instead of uploading artwork, our team describes a banner: a headline, a short line underneath, a button label, colours, a few small shapes or glyphs and how they should drift. The app receives that description and paints the banner with code. Because it is drawn rather than downloaded, it is sharp on every screen size, it weighs almost nothing, and changing the words is as quick as saving a form. The admin page shows a live preview that uses the same maths as the app, so what our team sees is what you get. Positions in the description are relative to the banner, not fixed pixels, which is what keeps one design correct on a small Android phone and a large iPhone alike. Text that should come from live data, like the minimum order for free delivery in Laayo Plus, is filled in by the server at the moment the banner is sent, so a banner can never advertise a price the app would not honour. We kept three rules for smooth motion, and any change to the painter has to keep them: - **One clock for the whole banner.** Every shape moves on the same timer with its own offset, instead of each shape running its own animation. - **Small movements over long cycles.** Gentle drift reads as alive. Big fast motion reads as an ad. - **Paint in isolation.** The banner is drawn on its own layer, so its movement never forces the rest of the home screen to redraw. ## Video where video is better For festivals we wanted something richer than shapes: a full scene with movement. The carousel can already play short muted video that loops, so festival banners are made as small looping clips with a still poster image behind them. That taught us a rule we now apply to every banner: **the first frame must be a finished picture.** If a phone pauses the video, for example to save battery, the customer should see a complete banner, not a blank or half-drawn frame. We also found a case on iPhone where a paused video never resumed and the banner froze. The new app restarts only the visible slide, picks the video back up when you return to the app, and keeps the poster on screen until the video is genuinely moving. ## A banner in every section Below the carousel, smaller call-to-action banners point to things like a restaurant, a collection or a page in the app. Food, grocery and pharmacy each have their own home, so each section now has its own list of these banners in the admin panel, and a banner made for groceries cannot accidentally show on the food home. Setting this up section by section also surfaced some bugs that were invisible from the app. Turning a banner's button off did not save. Some pickers in the admin form did not show their options. Taps on a banner were being recorded against the wrong address, so we had no idea which banners people actually used. All of these are fixed on the server, and the native home screens will show these banners directly in the next app update. ## Why this matters None of this is visible as a "feature". You will just notice that the home screen fits the day: the festival when it is the festival, your town's new restaurant when it opens, the right offer for the section you are in. For our small team it means a seasonal campaign is an afternoon of work in the admin panel instead of a design request, an image export and an app release. ## What's next We want restaurants to be able to request a banner from the partner app, using their own logo and colours, with our team approving it. We are also exploring banners that respond to the time of day, so the morning home screen leans towards tea and breakfast, and the evening one towards dinner. --- # A few steps off: getting the address pin right > Two small bugs in our map picker could put a delivery address down the street, or at a place the customer never chose. Here is how we found them and the rule we now follow for every map. - Source: https://blog.laayo.com.np/picking-the-right-address-pin - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: September 28, 2026 - Topics: Maps, Addresses, Riders, UX In a town without house numbers on every gate, the pin on a map is the address. A customer in Birtamod or Damak might write "behind the blue school, second lane" in the notes, but the rider's app navigates to the coordinate. If the coordinate is wrong, everything after it is wrong too: the delivery fee, the estimated time, and the phone call where a rider asks "where exactly are you?" This autumn we found two separate problems in how our app picks that coordinate. Neither was dramatic. Both quietly cost riders and customers time every day. ![Two fixes to the map picker: lift the pin image so its tip sits on the exact point that gets saved, and treat any pin the app guessed as unconfirmed until the customer actually chooses a spot.](https://blog.laayo.com.np/media/seed/address-pin.svg) ## Bug one: the pin pointed below the saved spot Our address picker works like most: the map moves under a pin that stays fixed in the middle of the screen. When you tap Confirm, we save the point at the centre of the map. The pin is an image. When you centre an image, you centre the whole picture, not its tip. A map pin's tip is at the bottom of the image, so with the image centred, the tip pointed roughly half the pin's height *below* the point we were actually saving. Customers did exactly what we asked: they put the tip on their door. We saved a point a little way up the street. How far? At the zoom level people use to pick a house, it was far enough to matter. In a dense neighbourhood that is the next building, or the other side of a lane. The fix is to lift the image so its tip, not its centre, sits on the saved point. The detail that matters is *where the tip actually is* in each image. Our current pin has a small shadow under it, so the tip is not at the very bottom edge but a bit above it. We measured each pin asset and lift it by exactly that amount. One more case needed care. On the add address screen, a sheet with the address form covers the lower part of the map. If you centre the pin in the full map, the pin and the saved point drift apart again. So we tell the map about the sheet, the map shifts its centre into the visible area, and the pin is centred inside that same area. ## Bug two: a pin nobody chose The second problem was harder to see, because it only happened when something else failed. When the app needs to show a map and does not yet know where you are, it has to start somewhere. Ours started at a default point in town that comes from our settings. That is a reasonable place to start a map. It is a terrible place to save an address. There were two ways that default point could become someone's delivery address: 1. **When GPS failed**, an old helper quietly returned the default point as if it were your real location. Everything downstream treated it as real. 2. **When the map first settled**, the picker armed the Confirm button from wherever the camera was, even if the camera was only there because we put it there. The result: a customer opens the map, GPS is slow, they see a pin, they tap Confirm without looking closely, and their saved address is now a spot they have never been to. A rider then drives to it. ### The rule: provenance, not geography The tempting fix is to block coordinates near the default point. That does not work in a town where real customers live right next to it. The real question is not *where* the pin is, but *who put it there*. So the app now tracks where every pin came from: - **A guess** is any pin the app placed itself: the default starting point, or a fallback when location is unavailable. - **A choice** is a pin the customer clearly moved, picked from search results, or got from a real GPS fix. While the pin is a guess, the Confirm button is disabled, the street name under the pin is hidden so it does not look confirmed, and the save itself refuses even if something tries to call it. The moment the customer makes a choice, all three unlock. The old helper that invented a location when GPS failed now returns nothing, and every screen that used it handles "no location yet" properly instead of assuming one exists. ## Searching for places nearby first Picking a pin is only half the job. Most people search first, and search results need to make sense for a small town. We changed place search so that results are biased towards where you are, sorted by distance and shown with that distance, so "City Center" from Birtamod shows the one a kilometre away first rather than one in another city. When nothing nearby matches a typed name, which happens with local spellings, we fall back to a broader text search before giving up. A loosely typed shop name can still find the right place nearby. Your saved addresses appear at the top of the search sheet as recent locations, each with its distance from where you are now, because for most orders the right answer is somewhere you have already been. The map in the picker also shows the names of nearby places like shops, schools and temples with muted icons, since those are what people actually use to orient themselves here. ## The rule for every new map These fixes now form a checklist we apply to any map that can save a location, in any of our apps: 1. **The pin tip is the saved point.** Measure the asset and lift it. 2. **If anything covers the map, pad the map.** The pin and the saved point must be centred in the same visible area. 3. **Never seed a save from a guess.** Start from the customer's own saved address if there is one. If the start is a fallback, mark it as a guess and keep Confirm disabled until the customer makes a choice. 4. **No invented locations.** If we do not know where someone is, we say so. Place search with distance is already live. The picker changes are rolling out in app updates. They do not add a single new screen. They just make sure that when a customer puts the tip of the pin on their door, the rider goes to that door. --- # What Laayo values, and how it shows up in the app > Six values that guide how Laayo works, each tied to real decisions in the product, from honest delivery times to partners paid on time. - Source: https://blog.laayo.com.np/laayo-values - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: September 25, 2026 - Topics: Laayo, Values, Culture Laayo is a food and grocery delivery app from Birtamod, Jhapa, run by Laayo Services Pvt. Ltd. Every company says it has values. We would rather show you where ours appear in the product, so you can judge them for yourself. ![Six values at Laayo, each linked to a real decision in the product.](https://blog.laayo.com.np/media/seed/laayo-values-map.svg) ## Small towns first We started in Birtamod and Damak, not in the capital, because people in smaller towns deserve the same convenience as anyone else, built for how their town actually works. That is why Laayo understands landmark addresses, plans for monsoon roads and works with local kitchens that had never been online before. **Where you see it:** [Why we started Laayo in Birtamod and Damak](https://blog.laayo.com.np/delivery-in-small-towns), [Riding through the monsoon](https://blog.laayo.com.np/riding-through-the-monsoon), [We started small on purpose](https://blog.laayo.com.np/starting-small-on-purpose). ## Honesty, especially about time A delivery time is a promise. We would rather show an honest range than a hopeful one, and tell you when an order is running late instead of letting the number silently slip. Honesty also means saying "rolling out" when a feature is not finished, here on this blog and in the app. **Where you see it:** [How we estimate when your food will arrive](https://blog.laayo.com.np/how-we-estimate-delivery-time), [Loading without lying](https://blog.laayo.com.np/skeletons-not-spinners), [When a store shows as open or closed](https://blog.laayo.com.np/store-open-or-closed-the-truth). ## Partners and riders are paid on time Restaurants and riders do the hard work. They should never have to chase their money. We built clear payout statements, confirmation calls and earnings screens so everyone can see what they earned and when it arrives. **Where you see it:** [Getting paid on time as a partner](https://blog.laayo.com.np/getting-paid-on-time-as-a-partner), [How riders earn at Laayo](https://blog.laayo.com.np/how-riders-earn-at-laayo), [Tipping your rider](https://blog.laayo.com.np/one-tip-per-order). ## Calm by design An app you use when you are hungry should never shout at you. Laayo uses two colours, one typeface, gentle motion and calm haptics. It shows real content as soon as it can, and it does not flash things on screen only to take them away. **Where you see it:** [Designing Laayo in yellow](https://blog.laayo.com.np/designing-laayo-in-yellow), [Motion that feels native](https://blog.laayo.com.np/motion-that-feels-native), [One restaurant card, everywhere](https://blog.laayo.com.np/one-store-card-everywhere). ## Own the technology When something touches your order, your payment or your delivery, we want to be able to fix it the same day. So Laayo builds and runs its own apps and systems. That choice also keeps us lean. **Where you see it:** [Laayo's tech stack series](https://blog.laayo.com.np/tech-stack), [Building lean](https://blog.laayo.com.np/building-lean). ## Safety and dignity Riders work on real roads in real weather. Customers share their addresses and phone numbers. We design with both in mind: riders say when it is raining, not a weather app; tracking shows a rider only once food is on its way; accessibility needs are shared only with the rider who needs to know; and a person is always reachable in support. **Where you see it:** [Riding through the monsoon](https://blog.laayo.com.np/riding-through-the-monsoon), [Privacy and your data at Laayo](https://blog.laayo.com.np/privacy-and-your-data-at-laayo), [Designing for everyone](https://blog.laayo.com.np/designing-for-everyone-accessibility), [Support calls that reach a human](https://blog.laayo.com.np/support-calls-that-reach-a-human). ## How we use these values When a decision is hard, we ask which choice better fits these six. Sometimes that means building something slower but more honest, or saying no to a feature that would look good but make the app noisier. If you think we are falling short, tell us at support@laayo.com.np. We read it. ## Quick answers ### What are Laayo's values? Small towns first, honesty about time, partners and riders paid on time, calm design, owning the technology, and safety and dignity. ### Why did Laayo start in smaller towns? Laayo believes people in smaller towns deserve the same convenience as big cities, built for how their towns actually work. It began in Birtamod and then Damak. ### Does Laayo build its own technology? Yes. Laayo designs, builds and runs its own apps and backend so it can fix problems quickly and keep costs under control. ### How does Laayo look after riders? Riders control rain mode for their zone, see clear earnings, can receive tips and are supported by Laayo's operations team through the day. --- # Your Laayo account, explained > Signing in with your phone, your profile, saved addresses, notifications, devices and deleting your account. Everything about managing your Laayo account. - Source: https://blog.laayo.com.np/your-laayo-account - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: September 24, 2026 - Topics: Guides, Account, Privacy Your Laayo account keeps your orders, addresses, wallet and preferences together. This guide covers how to sign in and how to manage everything in your account. ## How do I create a Laayo account? There is no separate sign-up form. Open the app, enter your mobile number, and type the one-time code Laayo sends by SMS. If the number is new to Laayo, the app asks for your name, and your account is ready. Adding an email address is optional, and you can do it later from your profile. ## Do I need a password? No. Laayo signs you in with a one-time SMS code each time you log in on a new phone. If you have used Laayo on a phone before, the app may show your account as a one-tap option on the login screen. Tapping it still sends a fresh code, so nobody can open your account just by picking up your phone's app. ## Can I use Laayo without signing in? You can open the app and look at restaurants and menus without signing in. To add items to a cart, place an order, use the wallet or chat with support about an order, you need to sign in. ## Can I use my account on two phones? Your account is active on one phone at a time. If you sign in on a new phone, the old one is signed out and the app explains why. This protects your wallet and order history if a phone is lost or shared. You can see and manage your signed-in devices from your account settings. ## How do I change my name, email or phone? Open the Profile section of the app. - **Name** can be edited directly. - **Email** can be added or changed. When you change it, we send a verification step to make sure the new address is yours. - **Phone number** is how you sign in. If you need to move your account to a new number, contact support so we can verify it is really you. ## How do I save and manage addresses? You can save addresses such as Home, Work or a family member's house, each with its own map pin, landmark and delivery notes. Choose one at checkout or add a new one. You can edit or remove saved addresses from the Addresses section of your profile. The app asks you to confirm before deleting one. ## How do I control notifications? Laayo sends notifications about your orders, such as when the restaurant accepts, when the rider is on the way and when food arrives. These matter, so we recommend keeping order notifications on. Laayo also sends occasional messages about offers and new restaurants. You can manage notifications in your phone's settings for the Laayo app. We try hard to send only messages worth opening. Read [Notifications that are worth opening](https://blog.laayo.com.np/notifications-that-are-worth-opening). ## Can I set accessibility preferences? Yes. Laayo has an optional accessibility profile where you can tell us about hearing, vision or mobility needs. Riders then see a short note on how best to hand over your order, such as calling instead of ringing a bell. Read [Designing for everyone](https://blog.laayo.com.np/designing-for-everyone-accessibility). ## How do I delete my Laayo account? You can request account deletion from your account settings in the app. Before you do, use up any wallet balance and make sure you have no active orders, because deletion cannot be undone. If you have trouble, contact support@laayo.com.np from the email or phone linked to your account. ## Quick answers ### How do I sign up for Laayo? Enter your mobile number in the app, type the one-time SMS code, and add your name. That is the whole sign-up. ### Does Laayo have a password? No. You sign in with a one-time code sent by SMS to your mobile number. ### Why was I logged out on my old phone? A Laayo account is active on one phone at a time. Signing in on a new phone signs the old one out, to protect your account. ### Can I save more than one address? Yes. You can save several addresses, each with its own pin, landmark and notes, and pick one at checkout. ### Can I delete my Laayo account? Yes. Request deletion from your account settings in the app, after using any wallet balance and finishing active orders. --- # What is Qora? QR payments for Nepali businesses, explained > Qora is payment software from Laayo that lets any business take QR payments and know the moment a customer has paid. What it does, who it is for, and why it never holds your money. - Source: https://blog.laayo.com.np/what-is-qora - Section: Guides - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: September 24, 2026 - Topics: Qora, Payments, QR, Guides Every shop in Nepal has a QR code on the counter. The hard part is not showing a QR. It is knowing, reliably and right away, that the money has arrived, and connecting that to your bill, your website or your app. That gap is what **Qora** fills. ## What is Qora? Qora is a payment platform for Nepali businesses, built by Laayo Services Pvt. Ltd. and shown as "Qora by Laayo". It lives at **qora.laayo.com.np** and gives a business three things: - **A merchant dashboard** to create payments, see every payment and its status, and manage the account. - **Payment links and counter QR posters** for businesses that do not write code. - **A developer API** with documentation, for businesses that want payments inside their own website, app or billing system. Laayo itself takes E-Payment with the same kind of technology, so Qora is built on what we use every day. ## Does Qora hold my money? No. This is the most important thing to know. When a customer pays a Qora merchant, the money goes from the customer's bank to the **merchant's own account**. Qora never sits in the middle of the money. What Qora provides is the software around the payment: creating the QR, watching for the customer's payment, confirming it, and telling the merchant's systems. ## Who is Qora for? - **Shops and counters** that want a QR for each bill with a clear "paid" confirmation, instead of asking customers to show their phone screen. - **Businesses that send bills**, such as tutors, clinics or service providers, who want to send a payment link to a customer. - **Developers and online businesses** that need payment confirmation inside their own app or website. ## How does paying with Qora work for a customer? 1. The customer sees a QR on a screen, a printed poster or a payment link. 2. They scan it with the banking or wallet app they already use. 3. As soon as their app opens the payment, the merchant sees it marked as scanned. 4. When the payment completes, the merchant sees it as paid, and their systems are told automatically. The customer does not need to install anything new or create an account. ## What are payment links and counter QR posters? These are for businesses that will never touch an API: - **Payment links** are made in the dashboard for a known amount and sent to one customer by message or email. - **Counter QR posters** are printable posters for the till. The customer scans, types the amount and pays. Both show up in the dashboard with their status, just like payments made through the API. ## What does Qora offer developers? - **A REST API** to create payments and check their status. - **Signed webhooks**, so a merchant's server is told when a payment succeeds and can check that the message really came from Qora. - **Documentation with a live console**, where a developer can use their own key to create a real payment from the docs page and watch it complete. The documentation is at qora.laayo.com.np. ## How does a business sign up? A business creates an account, verifies its email and phone number and submits its business details for review. Qora can read the business's PAN or VAT certificate to fill in the form, so the owner does not have to type everything. Once approved, the business connects its own bank QR account and can start taking payments. ## How does Qora make money? Qora charges businesses for the software, not for holding money. Plans are shown when a business signs up. ![How a Qora payment flows: the merchant creates a payment, the customer scans with their own bank app, the money goes straight to the merchant's account, and Qora confirms it to the merchant.](https://blog.laayo.com.np/media/seed/qora-payment-steps.svg) ## Quick answers ### Is Qora a bank or a wallet? No. Qora is payment software. Money moves from the customer's bank to the merchant's own account, and Qora never holds it. ### Do customers need the Qora app? No. Customers scan with the banking or wallet app they already use. ### Can I use Qora without a developer? Yes. Payment links and printable counter QR posters work straight from the dashboard. ### Does Qora have an API? Yes. Qora has a REST API, signed webhooks and documentation with a live console at qora.laayo.com.np. ### Who makes Qora? Qora is made by Laayo Services Pvt. Ltd., the company behind the Laayo delivery app. --- # Reviews go both ways > Customers rate riders, and riders rate the delivery too. Here is why we ask riders how it went at the gate, what we do with their answers, and how trust works on both sides of the handover. - Source: https://blog.laayo.com.np/reviews-for-riders-too - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: September 24, 2026 - Topics: Riders, Ratings, Trust Every Laayo delivery ends with a handover: a bag passes from a rider's hand to a customer's at a gate, a shop counter or a hostel stairwell. Most of the time it takes a few seconds and both people smile. Sometimes it does not go well, and until recently only one side of that moment could tell us about it. Customers have always been able to rate their rider. We think riders deserve the same voice. ## How customers rate riders After a delivery, the app asks the customer how it went. They can rate the food and the rider separately, so a slow kitchen does not turn into a bad mark for the person who rode through the rain to bring it. A rider's average rating shows on their profile in the rider app, and it is one of the signals that make up a freelance rider's medal. Low ratings are not just a number. When a customer leaves a poor rating with a comment, our team reads it. ## How riders rate the delivery After marking an order delivered, the rider app asks the rider a short question about the handover: how did it go? They pick a star rating and tap any tags that fit. The tags are written from the rider's side of the gate: - **Good things:** the customer was nice, said thank you, gave a tip, was on time, gave me water. - **Problems:** the customer was rude, was late, the delivery address was wrong, I could not reach the customer, the customer refused the order, the customer did not have change. There is space for a short comment too. The whole thing takes a few seconds and can be skipped. We chose tags over a free-text box on purpose. A rider standing at a gate with their next order already waiting will not write a paragraph. Two taps they will do. And tags let us see patterns: an address that is wrong again and again, a building where nobody answers the phone. ## What we do with rider reviews Rider reviews are visible to our team on each customer's profile, alongside everything else we know about their orders: an average, a tally of the good tags and the problem tags, and the full list with a link to each order. Low ratings are marked so they stand out. Here is what that is for: - **Fixing addresses.** If several riders tag the same customer with "wrong delivery address", we can reach out and help them fix the pin, which helps the next rider too. - **Supporting riders.** A rider who reports a rude customer or a refused order should not carry that alone. Our team can see it, follow up and back the rider when there is a complaint about the same delivery. - **Understanding cash problems.** "Did not have change" sounds small, but it is a real cost to a rider standing at a gate. It is one of the reasons we keep making E-Payment easier. It is just as important to say what rider reviews are **not** for. Customers do not see them, a single bad review does not block anyone from ordering. They are a quiet signal for our team, not a public score. ## Trust, measured over time Behind the scenes we keep a trust score for customers and for riders. It is built from what actually happens over many orders: deliveries completed, cancellations, ratings from the other side, refunds. Older events count for less as time passes, and one bad day does not outweigh months of good ones. Today that score is **observational only**. It does not change prices, block cash orders, decide refunds or affect a rider's pay. We use it to understand patterns and to spot the rare account that needs a closer look. If we ever let it change what someone can do in the app, we will say so clearly first. ## The handover is the product It is easy to think of a delivery app as menus, payments and maps. But the moment that decides how someone feels about Laayo is the few seconds at the gate. A polite customer and a careful rider make each other's day better. A wrong address or a refused order makes it worse for both. Asking both people how it went is how we learn to make that moment better. ## What's next We are looking at closing the loop for riders: when a rider's report leads to a fixed address or a resolved complaint, they should hear about it. If you ride for Laayo, keep tagging. Every tag goes somewhere. --- # One company, four products > Laayo is more than a delivery app. How the Laayo app, Laayo Plus, Qora and Laayo Biz fit together, and why sharing riders, payment rails and technology makes each one stronger. - Source: https://blog.laayo.com.np/one-company-four-products - Section: Investors - Author: Laayo Leadership (Laayo Services Pvt. Ltd.) - Published: September 23, 2026 - Topics: Laayo, Qora, Laayo Biz, Laayo Plus, Strategy Most people know Laayo as the yellow app they use to order dinner. Behind it is a small company, Laayo Services Pvt. Ltd., that builds four products for the same towns and often the same businesses. This post explains what each product does, who it serves and why we think they belong together. ## The Laayo app The Laayo app is where it starts. Customers order food, groceries and everyday items from local restaurants and shops, pay by cash or E-Payment, track their rider live and get help when something goes wrong. Restaurants and shops manage their menus and orders in the partner app. Riders work from the rider app. The app is also where most of our customers first meet us, which makes it the front door to everything else. ## Laayo Plus Laayo Plus is a monthly membership inside the app. Members get free delivery on qualifying orders each month, priority support and other perks. For customers, Plus makes Laayo cheaper and easier to use often. For us, it creates recurring revenue and turns occasional customers into regulars. You can read the details in [what Laayo Plus gives you](https://blog.laayo.com.np/what-laayo-plus-gives-you). ## Qora [Qora](https://qora.laayo.com.np) is a QR payment platform for Nepali businesses of any kind, not just restaurants. A merchant can create dynamic QR codes, receive payments that settle directly to their own account, see each payment arrive in real time and connect payments to their own systems through an API with developer documentation. Qora grew out of our own needs. To make E-Payment work smoothly in the Laayo app, we had to build reliable QR payment handling. Once that worked well for us, offering it to other businesses was a natural next step. Qora runs on its own separate systems and database, and it never holds customer money. ## Laayo Biz [Laayo Biz](https://biz.laayo.com.np) is a point of sale and restaurant management system. Restaurants use it for billing, dine-in tables, kitchen order tickets, staff, inventory and reports, on the web and in a mobile app. Each business has its own isolated data. Laayo Biz can also receive orders from the Laayo marketplace directly, so a restaurant that uses both sees delivery orders and counter orders in one place. ![Four products sharing three foundations: riders and operations, payment rails, and one engineering platform](https://blog.laayo.com.np/media/seed/investor-four-products.svg) ## What they share The products are separate, but they are built on shared foundations. That is where most of the advantage comes from. **Riders and operations.** Our rider fleet, support team and local operations serve the marketplace today, and the same people and processes can support deliveries for other products as they grow. **Payment rails.** E-Payment in the Laayo app, merchant payments in Qora and subscription billing for Laayo Biz and Qora all run through payment infrastructure we already operate and understand. Building it once and using it many times keeps costs down and quality up. **Technology and team.** One engineering team builds and runs everything, with shared practices for testing, deploying, monitoring and security. Lessons from one product carry straight into the others. We describe that platform in our [tech stack series](https://blog.laayo.com.np/tech-stack). **Relationships.** A restaurant that joins the marketplace already knows and trusts us. Offering it a point of sale or a payment tool is a conversation with a partner, not a cold sale. ## Why not focus on one thing? It is a fair question, and focus matters to us. Delivery in Birtamod and Damak remains our main priority, and most of our energy goes there. But Qora and Laayo Biz are not distractions from delivery. They grew out of tools we needed to build anyway, and they make the delivery business stronger: partners who run their counter on Laayo Biz and take payments through Qora have more reasons to stay, and more of their business runs on systems we can improve. We think of the four products as one relationship with a town's customers and businesses, seen from four angles. ## Built carefully Running several products means we take separation seriously. Each product has its own data, its own access rules and its own billing. A problem in one should never spill into another. That discipline is part of how a small team can run several products without losing control of any of them. ## Where this goes Today, the four products serve Birtamod and Damak first, with Qora and Laayo Biz also open to businesses elsewhere. As we grow into new towns, each product arrives with the others, so every new town gets a complete set of tools from day one. We are also exploring another line, Laayo Supply, to help restaurant partners buy kitchen supplies. It is at an early stage, and we write about it in [what comes next](https://blog.laayo.com.np/what-comes-next). --- # The map bill that was paying for answers we threw away > A single screen in our rider app was asking the maps API for far more travel times than it ever read. Here is how we found it, fixed it, and what we changed so it cannot happen again. - Source: https://blog.laayo.com.np/cutting-maps-costs - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: September 16, 2026 - Topics: Maps, Cost, Riders, Backend Every delivery app is, under the hood, a maps company that happens to sell food. We ask a maps provider where an address is, how far a store is from you, how long a rider will take, and which road they should use. Each of those questions costs a little money. At our size, a little money per question is fine. A little money times a mistake is not. This is the story of a mistake that had been quietly running for a long time, and the rules we wrote afterwards. ## How the maps bill works Most of our maps questions go to Google Maps Platform. Different questions are billed differently, but the one that matters here is the **Distance Matrix**. You give it a list of starting points and a list of destinations, and it returns the travel time from every start to every destination. The key word is *every*. You are billed per **element**, and the number of elements is: ```text elements = origins x destinations ``` Add a few more starts and a few more destinations and the count does not grow a little, it multiplies. That multiplication is the whole story. ## Finding it When we sat down with our billing history, one line stood out. Distance Matrix was by far the biggest maps cost, much bigger than geocoding addresses or drawing routes, which surprised us. The customer app does most of our maps work, and we already knew its calls were cached aggressively. Something else was asking a lot of questions. We searched our code for every place that called that API. There was exactly one server-side caller left: the rider app's **My Run** screen. When a rider carries several orders, My Run shows the order of their stops and how long each leg will take: from where they are now to the first stop, from the first stop to the second, and so on. ## The bug To get those legs, the server built a list of origins (the rider, stop 1, stop 2, ...) and a list of destinations (stop 1, stop 2, stop 3, ...) and sent them in one request. What it needed was the first origin to the first destination, the second to the second, and so on. The diagonal. ![A matrix request bills every cell, but My Run only read the diagonal](https://blog.laayo.com.np/media/seed/maps-matrix.svg) What it paid for was every cell. For a run of N legs it was billed N times N elements and read only N of them. The longer the run, the bigger the waste, and almost all of what we paid for was thrown away the moment the response arrived. Nobody would have noticed from the app. The screen was correct, and it was fast. Only the bill knew. ## The fix The fix was simple once we could see it. Instead of one big matrix, the server now sends one small request per leg, each with exactly one origin and one destination, all fired at the same time. The rider sees the same numbers in the same time. We pay for N elements instead of N squared. We made two more changes while we were in there: - **Ask once per leg.** If two legs in the same run share the same start and end, they are now one request, not two. - **Remember longer.** Only the first leg really changes as the rider moves. The leg between two stops is the same road it was a moment ago. My Run refreshes often, and it used to re-ask about every leg on almost every refresh. Those fixed legs are now remembered for a while instead. We kept one thing that looks expensive on purpose: these requests still ask for **traffic-aware** times. In monsoon season, with one-way streets and roads that flood, a travel time without traffic is not worth much to a rider deciding which stop to do first. With the multiplication fixed, the cost of doing it properly is small. ## The same bug, smaller, somewhere else Once you know the shape of a bug, you start seeing it. Our point-of-sale screens for restaurants calculate delivery distance in the browser using the same kind of matrix. They were sending an extra origin that was never read, which doubled what each lookup cost. We removed it, and the result on screen is byte for byte the same. ## What was already right It is just as useful to know what not to touch. The customer app's maps calls go through our own server, which caches them: address lookups, routes and distances are each remembered for as long as they stay true. The public order tracking page asks for routes without traffic, requests only the fields it shows, and caches its answers. None of these were driving the bill, and "optimising" them would only have added risk. ## Rules we keep now The fix itself was small. The rules are what we want to keep for years. 1. **Never send a matrix to read a diagonal.** If you need A to B and C to D, ask those two questions. The newer Routes API bills its matrix the same way, so it is not a way around this. 2. **Cache by what changes.** Fixed geometry, like store to store, can be remembered. A rider's live position cannot. 3. **Round the question.** A rider moving one metre does not need a new route. Parts of the rider app already wait for real movement before asking again. Making every map screen do the same, with a cap on how many answers it keeps in memory, is next on our list. 4. **Put a ceiling on the bill.** Daily quotas per API mean that even a future bug can only cost a bounded amount before it stops itself. Setting those limits is part of the same clean up. The best part of this fix is that nobody using Laayo noticed anything. Riders see the same run, restaurants see the same distance, and the money goes into making deliveries faster instead of into travel times nobody reads. --- # Ordering groceries on Laayo > Laayo is not only for meals. How the grocery section works, what you can order from local shops, and how grocery orders differ from food orders. - Source: https://blog.laayo.com.np/groceries-on-laayo - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: September 16, 2026 - Topics: Guides, Grocery, Shops Besides restaurants, Laayo brings you groceries and daily needs from local shops in our delivery areas. This guide explains how the grocery section works. ## Does Laayo deliver groceries? Yes. Laayo has two sections: **Food**, for restaurants and cafes, and **Grocery**, for local shops and stores. Grocery orders are delivered by the same Laayo riders and tracked in the same way as food. Laayo does not offer medicine, pharmacy or parcel delivery. Food and groceries are what we do. ## How do I open the grocery section? On the Laayo home screen, switch from Food to Grocery. The app then shows grocery shops that deliver to your pin and their products, grouped by category. What you can find depends on the shops near you. Typical categories include fresh produce, meat, dairy and eggs, staples like rice, flour and oil, snacks and drinks, and household items. ## How is a grocery order different from a food order? The basics are the same: add items, check out, pay, and track. A few things are different: - **Products have sizes.** Grocery items often come in different weights or pack sizes, so check the size before adding. - **Items can run out.** A shop may be out of something on the shelf even if it shows in the app. At checkout you can tell us what to do if an item is unavailable, for example to skip it or to call you. - **One shop per order.** Each grocery order comes from one shop, so the shopkeeper can pack everything together. - **Shop hours apply.** Like restaurants, shops have opening hours, and you can only order while a shop is open. ## Is the grocery section changing? Yes. A new grocery design is rolling out, with category tabs at the top, aisle pages with a side menu of sub-categories, larger product cards and product pages with more detail. It also brings a "buy again" row with things you ordered before. The way you order and pay stays the same. ## Can I pay for groceries the same way as food? Yes. Grocery orders accept the same payment methods: cash on delivery, E-Payment by QR, and the Laayo wallet. See [How to pay on Laayo](https://blog.laayo.com.np/how-to-pay-on-laayo). ## I run a shop. Can I sell on Laayo? Yes. Local shops and grocery stores can join Laayo as partners, the same way restaurants do. Read [Joining Laayo as a restaurant partner](https://blog.laayo.com.np/joining-laayo-as-a-restaurant-partner) for how sign-up works, or contact us at support@laayo.com.np. ## Quick answers ### Does Laayo deliver groceries? Yes. Laayo has a Grocery section with local shops in Birtamod, Damak and nearby areas, delivered by Laayo riders. ### Does Laayo deliver medicine or parcels? No. Laayo delivers food from restaurants and groceries from local shops only. ### What if an item in my grocery order is not available? At checkout you can choose what should happen if an item is unavailable, such as skipping it or asking the shop to call you. ### Can I order groceries from more than one shop at once? Each grocery order comes from one shop. Place a separate order for each shop. ### How do I pay for groceries? The same way as food: cash on delivery, E-Payment by QR, or the Laayo wallet. --- # What is Laayo Biz? The point of sale for restaurants, explained > Laayo Biz is our point of sale for restaurants and cafes. Who it is for, what it does from the floor to the kitchen, and how it connects to orders that come in through Laayo. - Source: https://blog.laayo.com.np/what-is-laayo-biz - Section: Guides - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: September 16, 2026 - Topics: Laayo Biz, POS, Restaurants, Guides Most restaurants run two systems that never talk to each other. There is the billing software at the counter for dine-in guests, and there is the delivery app on a phone next to it. Orders get typed twice, the kitchen hears about them from two directions, and at the end of the month nobody is sure which sales came from where. **Laayo Biz** is how we close that gap. ## What is Laayo Biz? Laayo Biz is a point of sale (POS) system for restaurants, cafes and similar businesses, made by Laayo Services Pvt. Ltd. It runs in a web browser at **biz.laayo.com.np** and as the **Laayo Biz POS app** on Android phones and tablets. A restaurant does not need to be on the Laayo delivery app to use it, but it works best when it is. ## Who is Laayo Biz for? - Restaurants and cafes with tables and dine-in guests. - Kitchens that want orders to reach the cooks without anyone walking back and forth. - Owners who want one place for sales, staff and stock, in Nepali dates as well as English ones. ## What can Laayo Biz do? ### The floor and the bill - **Floor view.** Every table on one screen, grouped by area, showing which are free and which are seated and for how long. - **Open a table, add as you go.** Waiters open a table, add dishes as guests order, and the running bill saves itself after every change. The web counter and the app share the same bill, so it does not matter which one a waiter picks up. - **Settle the way guests pay.** Cash, bank QR or a mix of methods on one bill. - **Takeaway orders** for guests who order at the counter. ### The kitchen - **Kitchen order tickets.** When a waiter sends an order, a ticket appears for the kitchen. - **Kitchen display.** A tablet in the kitchen shows new tickets with a sound. Cooks mark a ticket as seen and then as ready, and the counter sees both, so nobody has to shout through the hatch. ### The back office - **Staff and roles.** Owners, managers, waiters and kitchen staff each see only what they need. Staff can clock in and out, and attendance and timesheets are kept for payroll. - **Inventory by location.** Stock can be tracked separately for the kitchen, the bar and the store room, with a month-end stock report. - **Customers.** A customer typed in at the counter is saved by mobile number, so regulars build a history. - **Reports and insights** on sales, best sellers and payment methods. - **Activity log.** A record of who changed what and when, for owners who share the system with a team. - **Nepali calendar.** Dates can be shown in Bikram Sambat. ## How does Laayo Biz connect to Laayo orders? For restaurants on both, Laayo Biz and the Laayo delivery app are connected, and that is the part that saves the most time: 1. **Laayo orders arrive in the POS.** A delivery order placed on Laayo appears in Laayo Biz automatically, with its items matched to your POS menu, and goes to the kitchen like any other ticket. 2. **The kitchen updates Laayo.** When the cooks mark the ticket as being prepared or ready, the Laayo order is updated too, so the customer and the rider see real progress. 3. **Sold out means sold out everywhere.** When a stocked item runs out in the POS, it is hidden on Laayo, so customers cannot order something the kitchen no longer has. 4. **One view of the money.** Laayo payouts appear in Laayo Biz, with a marketplace report that shows what came from Laayo, what was paid and what is still to come. The connection is signed and checked on both sides, and each restaurant has its own private link. ![How a Laayo order travels through Laayo Biz: the order arrives as a kitchen ticket, the kitchen's progress goes back to the customer, and sold-out items are hidden on Laayo.](https://blog.laayo.com.np/media/seed/biz-order-loop.svg) ## Is my restaurant's data separate from other restaurants? Yes. Each business on Laayo Biz has its own separate data store. One restaurant's sales, menu, staff and customers are never mixed with another's. ## How do I get Laayo Biz? Restaurants can ask for Laayo Biz through the Laayo team or the sign-up on biz.laayo.com.np. Once the account is ready, staff sign in with the restaurant's business code, their email and password. Plans and billing are explained when you sign up, and renewals can be paid online. ## Quick answers ### Is Laayo Biz the same as the Laayo app? No. The Laayo app is where customers order delivery. Laayo Biz is the point of sale a restaurant uses at the counter and in the kitchen. They connect for restaurants that use both. ### Does Laayo Biz work on a phone? Yes. There is a web version at biz.laayo.com.np and the Laayo Biz POS app for Android phones and tablets. ### Can the kitchen see orders without paper? Yes. The kitchen display shows tickets on a tablet with a sound, and cooks mark them seen and ready. ### Do I need to be on Laayo delivery to use Laayo Biz? No, but restaurants on both get delivery orders straight into the POS and kitchen. ### Can staff have separate logins? Yes. Each staff member gets their own login and role, and owners can see an activity log of changes. --- # The ops team in your pocket: building the Laayo Admin App > Running deliveries in a small town happens on foot, on a scooter and at a restaurant counter, not at a desk. So we gave our operations team a phone app built on the same rules as the web panel. - Source: https://blog.laayo.com.np/the-ops-team-in-your-pocket - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: September 9, 2026 - Topics: Admin App, Operations, Flutter, Access control For a long time, running Laayo meant a laptop. Orders waiting for a rider, a restaurant that had not started cooking, a customer asking where their food was: all of it lived in a web panel built for a big screen. The people who actually fix those things are rarely at a desk. They are at a restaurant counter, on a scooter between towns or standing outside a customer's gate. So we built the **Laayo Admin App**, a phone app for the people who keep the day running. ## Start from the rules we already had The tempting way to build an admin app is to write a fresh set of API endpoints and a fresh set of permissions for it. That is also how you end up with two admin systems that disagree about who is allowed to do what. We went the other way. The web panel already has a well-tested access model: sections like orders, tickets, settings and finance, and roles that can see some sections, edit some and only read others. The app's server side reads **exactly the same rules**. Every app endpoint declares which section it belongs to, and a single gate checks the signed-in person against the same table the web panel uses. Two details mattered more than we expected: - **Read-only really means read-only.** A role that can only view a section is refused every change in it, unless the endpoint is explicitly marked as safe, such as saving your own notification preferences. An auditor still needs alerts on their phone. - **More than one device per person.** The rider app allows one phone per rider on purpose. For the ops team that rule is wrong: people use a phone and a tablet, and both should get alerts. ![The Admin App's main areas, Pulse, Dispatch, Tickets and Calls, all sit behind the same access rules as the web panel.](https://blog.laayo.com.np/media/seed/ops-pocket.svg) ## Pulse: what needs you, first The first screen is **Pulse**. It is ordered by urgency, not by department: 1. **Alerts** that need someone now: an order no rider has taken, a restaurant that has not started cooking, a customer waiting on a person in chat. 2. **Counts** for the day so far, compared with a normal day. 3. **Money**: what has been collected, what is waiting to be settled. 4. **Switches** that change how the platform behaves, for the people allowed to touch them. 5. **Activity**: a running log of what the team did, so nobody fixes the same thing twice. Alerts are not just pushes. Each one opens the exact order, ticket or rider it is about. ## Dispatch on a map The **Dispatch** board shows orders that need a rider and the riders who could take them, on a map and in a list. Assigning a rider from the app goes through the same order logic as the web panel. We learned that the hard way: an early version only attached the rider and left the order in its old state, so neither the restaurant nor the rider got the alert they should have. Now the app and the panel share one code path for assignment, and a fix in one is a fix in both. Each rider row shows how many orders they have delivered today, including when that number is zero. Hiding zeros made a quiet rider and an uncounted rider look the same. Riders are getting a lighter version of the same idea in their own app, called **Crew Radar**, rolling out with the rider app: who on the team is online, where they are and which orders each person is carrying. It makes it easy to see who is free when a new order comes in. ## Tickets and calls in one place Order problems reported by customers and support chats that need a person both land in **Tickets**, in one queue sorted by who has waited longest. A ticket opens straight into the conversation or the order report, so the reply goes where the customer already is. Calls work the same way. When someone on the team calls a customer, rider or restaurant from the app, the call is placed through Laayo's own line, so personal numbers stay private on both sides. Each call is linked to the order or ticket it was about, with a short summary of what happened. Automatic calls, like the reminders we place to restaurants that have not started an order, show up there too, marked as made by Laayo. ## Design rules for a work tool An app people use under pressure needs to be calm. We kept a few strict rules: - **Real artwork, not generic icons.** The app reuses illustrations and icons from our customer, rider and partner apps, so it looks like Laayo and not like a template. - **A small, fixed set of card shapes.** Every list in the app reuses the same layouts, so nobody has to relearn a screen. - **Skeletons, never a spinner covering the page.** Data appears where it will sit, and a slow network never hides what was already on screen. ## What's next Every new feature in the Admin App starts with the question "where is the person who will use this standing?" Next we are bringing more of the day-to-day restaurant work into the app, so a team member visiting a partner can fix a menu or a payout question right there at the counter. --- # We started small on purpose > Launching in smaller towns first was not a compromise. Density, close partner relationships and low costs give a young company advantages that are hard to get anywhere else. - Source: https://blog.laayo.com.np/starting-small-on-purpose - Section: Investors - Author: Laayo Leadership (Laayo Services Pvt. Ltd.) - Published: September 9, 2026 - Topics: Strategy, Small towns, Birtamod, Damak The standard playbook for a delivery company is to launch in the biggest city first. The logic is simple: that is where the most restaurants, customers and money are. We went the other way. Laayo launched in Birtamod and then Damak, two growing towns in eastern Nepal. People sometimes assume that was because we could not afford a big city. The truth is that we chose it, and we would choose it again. Here is why. ## Density makes the economics work Delivery is a game of density. What matters is not how many people live in a city, but how many orders a rider can complete in an hour, how far food travels and how long it waits. In our towns, most deliveries are short. Restaurants, offices and homes sit close together. A rider can finish more trips in a shift, food arrives hotter and fewer orders are lost to long distances. Within a town, a small team can reach meaningful coverage quickly, instead of being one of many options spread thin across a huge city. That density is also what makes each improvement count. When we make delivery estimates more accurate or cut the time food waits at the counter, the effect shows up across the whole town at once. ## Relationships are close In a smaller town, we know our partners. Restaurant owners can call us. Our team can visit a kitchen the same afternoon a problem shows up. When a partner has a slow week, we notice and we talk about it. These relationships are an advantage that is very hard to copy. A large platform arriving later can match our features, but it cannot easily match years of trust built face to face. Partners who feel heard tend to stay, and partners who stay improve their food, their packaging and their timing with us. ## We learn faster A smaller market is a better laboratory. We can change something on Monday and see its effect across the whole town by Friday. We can talk to the riders who were on the road and the customers who complained, often in person. Much of what is on this blog came from that loop: honest [delivery estimates](https://blog.laayo.com.np/how-we-estimate-delivery-time), [typed cancel reasons](https://blog.laayo.com.np/why-we-ask-you-to-type-a-cancel-reason) that tell us what really happened, rider alerts that are hard to miss. Each started as something we saw on the streets of our own town. ## Local knowledge shapes the product Building for smaller towns forced us to solve problems that city-first apps often ignore. - **Addresses are landmarks.** Many homes have no usable street address, so customers drop a precise pin and riders can call when a lane is hard to find. - **Weather changes everything.** Monsoon rain turns short rides into long ones, so our estimates and rider pay account for it. - **Cash and E-Payment live side by side.** We support both and work to make every payment method feel like one tap. - **Lunch is the big moment.** Offices, shops and schools all order at once, so a lot of our work is about getting the midday rush right. These are not small-town quirks. They are common across much of Nepal, which means the product we built here travels well. ## Costs stay low Operating in smaller towns is simply less expensive. Office space, marketing and operations cost less, and a small team can cover a whole town. Combined with lean engineering choices, which we describe in [building lean](https://blog.laayo.com.np/building-lean), that means every rupee goes further while we are still learning. ![Why smaller towns first: short trips, close partners, fast learning and low costs reinforce each other](https://blog.laayo.com.np/media/seed/investor-small-town-flywheel.svg) ## Small is a starting point, not a ceiling Starting small does not mean thinking small. It means earning the right to grow. Our playbook for a new town is now clear: sign the restaurants people already love, build a reliable rider team, get delivery times honest and fast, and earn trust one order at a time. Each town we serve makes the next one easier, because the product, the tools and the lessons come with us. Our focus today is to make Laayo genuinely excellent in Birtamod and Damak. Beyond that, Kathmandu is the next city we are preparing for. We will only launch there when we are confident we can bring the same care. You can read more about our plans in [what comes next](https://blog.laayo.com.np/what-comes-next). We started small on purpose. We intend to grow on purpose too. --- # Where does Laayo deliver? > Laayo delivers in Birtamod, Damak and nearby areas of Jhapa in eastern Nepal. How delivery areas work, how to check if your address is covered, and where we are going next. - Source: https://blog.laayo.com.np/where-laayo-delivers - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: September 5, 2026 - Topics: Guides, Delivery areas, Birtamod, Damak Laayo delivers food and groceries in **Birtamod and Damak**, two towns in Jhapa district in eastern Nepal, and in nearby areas around them. This guide explains how coverage works and how to check your own address. ## Does Laayo deliver in Birtamod? Yes. Birtamod is where Laayo started, and it is our home town. Restaurants and shops across Birtamod and the surrounding area are on Laayo, delivered by our own riders. ## Does Laayo deliver in Damak? Yes. Damak has its own Laayo delivery area, with local restaurants and riders who work in Damak. ## Does Laayo deliver in Kathmandu? Not yet. Kathmandu is the next city we are preparing for, but Laayo does not deliver there today. If someone tells you otherwise, they are mistaken. When Kathmandu goes live, we will say so here and in the app. If you live in Kathmandu and want to order for family in Birtamod or Damak, you can. Install the app, set the delivery pin to their address, and pay online. See [Laayo for families and gifts](https://blog.laayo.com.np/laayo-for-families-and-gifts). ## How do delivery areas work? Laayo divides its service into delivery areas, one for each town and the places around it. Each area has its own restaurants, shops and riders. When you set your location, the app works out which area you are in and shows you the restaurants that can deliver to that exact spot. Two things decide what you see: - **Your pin.** Restaurants are shown based on where your delivery pin is, not where your phone happens to be. If you are ordering for a different address, move the pin there first. - **Each restaurant's reach.** Every restaurant delivers within a sensible distance of its kitchen, so food arrives fresh. A restaurant on the far side of town may not show up for every address. ## How do I check if my address is covered? Open the app and set your location to the address you want food delivered to. Then: - **If restaurants appear,** you are covered. Order as normal. - **If the app says the location is outside our service area,** we do not deliver there yet. - **If only a few restaurants appear,** you are probably near the edge of an area. Try moving the pin to the exact gate, as a pin dropped in a field or on a main road can land outside a boundary by mistake. You can also browse by town on the web at new.laayo.com.np, which lists restaurants for Birtamod and Damak. ## Why did a restaurant disappear from my list? Usually one of three reasons: 1. **It is closed right now.** Closed restaurants move out of the main list but still appear in search and on their own page. 2. **Your pin moved.** If your saved address or GPS changed, a different set of restaurants may be in reach. 3. **It is not delivering at the moment.** Sometimes a restaurant pauses delivery when the kitchen is very busy. ## Can I ask Laayo to come to my town? Yes, and we would like to hear from you. Tell us through support chat in the app or email support@laayo.com.np. Requests from customers and restaurant owners help us decide where to go next. ## Quick answers ### Which cities does Laayo deliver in? Laayo delivers in Birtamod and Damak in Jhapa district, eastern Nepal, and in nearby areas around them. ### Is Laayo available in Kathmandu? Not yet. Kathmandu is the next city Laayo is preparing for, but there is no delivery there today. ### How do I know if Laayo delivers to my house? Set your delivery pin to your address in the app. If restaurants appear, you are covered. If the app says you are outside the service area, we do not deliver there yet. ### Can I order from Kathmandu or abroad for my family in Jhapa? Yes. Set the delivery pin to their address in Birtamod or Damak and pay online in the app. ### Why do I see different restaurants at different addresses? Restaurants are shown based on your delivery pin and how far each restaurant delivers, so each address sees the restaurants that can reach it. --- # How to list your shop on Laayo, a guide for grocery and speciality stores > Laayo is not only for restaurants. Here is how grocery shops, meat and fish counters and speciality stores join, how their catalogue gets set up, and what customers see. - Source: https://blog.laayo.com.np/how-to-list-your-shop-on-laayo - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: September 2, 2026 - Topics: Partners, Grocery, Shops, Guides People in Birtamod and Damak use Laayo for more than dinner. They order vegetables and fruit, chicken and fish, household basics and speciality products from shops in their own town. If you run one of those shops, this guide explains how to get on Laayo. ## Which shops can join Laayo? Laayo has a grocery section next to food. It suits: - **General grocery and kirana stores.** - **Fresh counters**, such as chicken, mutton and fish shops. - **Fruit and vegetable sellers.** - **Speciality shops**, such as sports nutrition or health stores. If customers in town would like your products delivered, you are a good fit. Our team will tell you honestly if something you sell cannot be delivered well. ## How do I sign up my shop? The sign-up is the same as for restaurants, with the shop type chosen at the start. You can: - tap **Partner with Laayo** in the Laayo app and follow the guided steps, or - ask a member of our field team, who can sign you up in person from their phone. You share your shop details, location, opening hours, photos, documents and bank details for payouts. Someone from Laayo reviews every application before a shop goes live. The full walk-through is in [joining Laayo as a partner](https://blog.laayo.com.np/joining-laayo-as-a-restaurant-partner). ## How does my product list get on the app? This is where shops differ most from restaurants. A restaurant menu is short. A shop can have a long list of products, often kept in a billing system, a spreadsheet or a printed price board. Typing all of that by hand is the main reason shops put off joining, so we help: 1. **Send us what you already have.** A price list, an export from your billing software or clear photos of your price board. 2. **We build the catalogue.** Our team sets up categories and sub categories (for example Seafood, then Fresh fish and Live fish), units such as per kilo or per piece, prices and short, honest descriptions. 3. **Photos.** We use your own product photos where you have them. Otherwise we use properly licensed pictures and mark them for you to replace when you can. 4. **You check before it goes live.** Nothing is published until you are happy with names, prices and pictures. Bulk set-ups are done carefully, with a way to undo them, so a mistake never leaves your shop half updated. ## How do customers find my shop? Shops appear in the grocery section of the Laayo app, organised by category, and in search. Customers can filter and browse like they would in a supermarket aisle, add items from several categories to one cart and check out with cash on delivery or E-Payment. A redesigned, faster grocery experience is rolling out with the new native apps. ## How do I keep prices and stock right? From the partner app you can edit prices, mark items out of stock and add new products whenever you like. Shops with prices that move often, like fresh meat, usually update a few items at the start of the day. Keeping stock accurate matters more in grocery than anywhere else: a customer who orders three things and receives two is less likely to come back. ## Who delivers my orders? Laayo riders. When an order comes in, you pack it and a rider collects it. Fresh and frozen items should be packed so they travel well, and our team can advise on packaging. ## Quick answers ### Can a grocery shop join Laayo? Yes. Laayo has a grocery section for grocery, fresh meat and fish, fruit and vegetables and speciality shops. ### Do I have to type in every product myself? No. Send us your price list, a billing export or photos of your price board, and our team builds the catalogue for you to check. ### Can I sell items by weight? Yes. Products can be priced per kilo, per piece or in other units that suit what you sell. ### Can I change prices every day? Yes. Prices, stock and new products can be changed from the partner app at any time. ### How do I get paid? The same way restaurants are paid: Laayo sends payouts to your bank account, each with a statement of the orders it covers. --- # How to pay on Laayo > Cash on delivery, E-Payment by QR, the Laayo wallet and gift cards. Which payment options Laayo accepts, how each one works, and what to do if a payment goes wrong. - Source: https://blog.laayo.com.np/how-to-pay-on-laayo - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: August 29, 2026 - Topics: Guides, Payments, E-Payment, Wallet Laayo keeps paying simple. You can pay in cash when the food arrives, or pay before delivery from the app. This guide explains every option and what to do if something does not go through. ![The ways to pay on Laayo: cash on delivery, E-Payment by QR, and the Laayo wallet, which you can top up and fill with gift cards](https://blog.laayo.com.np/media/seed/guide-payment-options.svg) ## What payment methods does Laayo accept? - **Cash on delivery.** Pay the rider in cash when your order arrives. - **E-Payment by QR.** Pay from your bank or wallet app by scanning a QR code that the Laayo app shows you. - **Laayo wallet.** Pay from money you have added to your Laayo wallet, refunds, gift cards you have claimed and other credits. You choose the method at checkout, just before you tap Place order. Some orders, such as gifts for someone else, need to be paid in advance, and the app tells you when that is the case. ## How does E-Payment by QR work? When you choose E-Payment and place your order, the app shows a QR code with the exact amount. Open your mobile banking or wallet app, scan the code, and confirm the payment there. Many banking apps let you scan a QR straight from a screenshot saved to your gallery, which is handy if you are paying on the same phone. When the payment arrives, the Laayo app marks it as paid and your order goes to the restaurant. You do not need to send anyone a screenshot or a transaction number. Read [Paying with a QR inside the app](https://blog.laayo.com.np/paying-with-a-qr-inside-the-app) for the full story. ## How does the Laayo wallet work? The Laayo wallet, called Laayo Money in the app, holds money you can spend on orders. Money gets into your wallet in a few ways: - **Adding money** with E-Payment. - **Refunds** for cancelled or problem orders, when refunded to the wallet. - **Gift cards** that someone sent you, once you claim them. - **Rewards and bonuses** during offers and festivals. At checkout, pick the wallet as your payment method. If your wallet does not cover the whole order, the app shows you how to pay the rest. You can see every wallet transaction in the app's wallet screen. ## Can I pay with a gift card? Yes. A Laayo gift card comes with a code. Claim it in the app and the value goes into your Laayo wallet, ready to spend on any order. See [Gift cards and Send a Treat](https://blog.laayo.com.np/gift-cards-and-send-a-treat). ## Can I tip my rider? Yes. You can tip your rider in cash, or from the app after delivery using E-Payment or your wallet. The whole tip goes to the rider. Read [Tipping your rider](https://blog.laayo.com.np/one-tip-per-order). ## What if my E-Payment fails? Do not pay a second time straight away. First: 1. **Check the order screen.** If it shows the order as paid, you are done. 2. **Check your bank app.** If money left your account but the order still shows unpaid, wait a little. Payments sometimes take a moment to confirm. 3. **Contact support.** If it still does not match, open support chat from the order and tell us. Include the time you paid. We check the payment on our side and either confirm the order or refund you. If an order is cancelled after you paid, the money is refunded. You can follow every refund step by step in the app. See [Refunds you can follow](https://blog.laayo.com.np/refunds-you-can-follow). ## Is paying in the app safe? The QR you scan is created for your order and amount only, and the payment is confirmed by the payment network, not by a screenshot. Laayo never asks for your bank PIN or password, by phone, chat or SMS. If anyone claiming to be Laayo asks for one, do not share it and report it to us. ## Quick answers ### Does Laayo accept cash on delivery? Yes. You can pay the rider in cash when your order arrives, except for orders that must be paid in advance, such as gifts. ### Can I pay with my mobile banking app? Yes. Choose E-Payment at checkout and scan the QR code with your mobile banking or wallet app. ### What is Laayo Money? Laayo Money is the Laayo wallet. It holds money you add, refunds, claimed gift cards and rewards, and you can spend it on any order. ### Money left my account but the order says unpaid. What should I do? Wait a moment, then check again. If it still says unpaid, contact support from the order with the payment time and we will sort it out. ### Will Laayo ever ask for my bank PIN? No. Laayo never asks for your PIN or password. Do not share them with anyone. --- # Ordering together, without passing one phone around the table > Group orders let everyone add their own food from their own phone, while one person checks out and pays. Here is how the link, the timer and the host controls work. - Source: https://blog.laayo.com.np/ordering-together-with-group-orders - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: August 28, 2026 - Topics: Group orders, Cart, Checkout Every office has the lunch ritual. Someone says "let's order", a phone goes around the table, everyone scrolls the same menu with someone else's thumb, and the person who started it ends up retyping half the list because somebody wanted extra cheese. At a birthday at home it is the same, except louder. Group orders on Laayo are our answer. One person starts the order, shares a link, and everyone adds what they want from their own phone. When the food list is complete, the host checks out once, pays once, and one rider brings everything. ## How it works ![A group order from start to checkout: the host starts it from a restaurant, shares the link, friends add their own items before the timer runs out, and the host places one order.](https://blog.laayo.com.np/media/seed/group-order-flow.svg) 1. **Start.** Open a restaurant and tap **Start group order**. The group gets a name, "your name's group order" by default, which you can change. 2. **Share.** Send the link on WhatsApp, Viber or anywhere else. Anyone who opens it and is signed in to Laayo joins the group. 3. **Add.** Each person browses the same menu and adds their own items, with their own sizes and add-ons. Everyone sees the shared list, with names next to items, so nobody orders the same thing twice by accident. 4. **Check out.** The host taps **Proceed to cart**. Everyone's items move into the host's cart as one order, the host picks the address and payment, and places it. When someone joins or adds an item, the host gets a notification. When the host starts checking out, everyone else gets one too: the order is about to be placed, so speak now. ## The timer A group order is open for **a short, fixed time**. That sounds strict, and it is meant to. Without a deadline, group orders drift. People add something, wander off, come back much later, and the restaurant has closed. The host can add **a little more time** with one tap if someone is still deciding, up to a firm limit. Everyone in the group sees the countdown, so nobody is surprised when it closes. If the timer runs out before checkout, nobody loses their choices. Each person's items go back into their own cart, and they get a message saying so. They can order on their own, or start a new group. ## The host is in charge Group orders need one person who decides, otherwise they fall apart. So a few things only the host can do: - **Place the order and pay for it.** One order, one payment, one delivery fee. - **Apply a coupon.** The coupon is checked again at the moment of checkout, so if the total has dropped below the coupon's minimum, or the code was used elsewhere in the meantime, you find out before paying, not after. - **Extend the timer, rename the group or delete it.** - **Remove someone or one of their items.** Sometimes a link travels further than intended. The removed person is told, and their items are returned to their own cart. Anyone who is not the host can leave at any time. Their items go back to their personal cart. ## Details that took longer than they look - **Your cart is safe.** If you already had items from that restaurant in your cart when you started a group, they become your items in the group. If the group is cancelled, they come back. - **Backing out of checkout is fine.** If the host taps Proceed to cart and then leaves without paying, the group opens again the next time they come back to it, with everyone's items intact. - **Double taps do not create two groups.** Tapping Start twice on the same restaurant takes you back to the group you already have. - **The restaurant has to be open.** We check this on our side as well as in the app, so a group cannot get stuck halfway through checkout because the kitchen closed. - **Groups have a sensible size limit.** It is big enough for the biggest office lunch we have seen, and it keeps a link that gets forwarded too widely from becoming a problem. ## What we chose not to do - **No split payments, yet.** Splitting a bill sounds simple until one person's payment fails and the whole order is stuck. For now, the host pays and settles up with friends the way people already do. We would rather the order always go through. - **No guest joining without signing in.** Every item in a group belongs to a real person, so we can return it to their cart, notify them and keep the list honest. Signing in takes a few seconds with your mobile number. - **One restaurant per group.** Mixing restaurants in a group means multiple riders and multiple timers. Keeping it to one restaurant keeps the food arriving together and hot. ## What's next We are watching how people use the timer and the host controls, and we will tune both. If your team uses group orders for lunch every week, tell us what would make it faster. We are listening. --- # Privacy and your data at Laayo, in plain words > A friendly summary of how Laayo handles your information when you order, pay, track and chat, and where to find the official privacy policy. - Source: https://blog.laayo.com.np/privacy-and-your-data-at-laayo - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: August 27, 2026 - Topics: Privacy, Payments, Tracking, Laayo Laayo is a food and grocery delivery app in Birtamod and Damak, Jhapa, run by Laayo Services Pvt. Ltd. To bring you food, we need some information about you, such as where to deliver and how to reach you. This post explains, in plain words, what that looks like in practice. This is a summary, not the legal text. Laayo's official policy is the [Privacy policy on laayo.com.np](https://laayo.com.np/privacy-policy), which is what applies. ## What Laayo needs and why To deliver an order, Laayo needs: - **Your name and phone number**, so the restaurant and the rider know who the order is for and can reach you. - **Your delivery address and map pin**, so the rider can find your door. You choose and confirm the pin yourself; the app does not guess it for you. See [Picking the right address pin](https://blog.laayo.com.np/picking-the-right-address-pin). - **Your order**, so the restaurant can prepare it and you can see it again in your history. - **How you paid**, so we can confirm the payment and handle refunds. Some things are **optional**, such as an email address, an accessibility profile or a "for you" rating based on your taste. You can use Laayo without them. ## Payments When you pay by **E-Payment**, you scan a QR code and approve the payment in your own bank or wallet app. Laayo does not ask for or store your card number or your bank login. The same principle applies to **Qora**, Laayo's QR payment software for businesses: merchants are paid directly by their own bank, and Qora never holds customer money. See [Paying with a QR inside the app](https://blog.laayo.com.np/paying-with-a-qr-inside-the-app). ## Live tracking and sharing When your order is on its way, you can see the rider on the map. The rider's position appears only once your food has been picked up. Before that, tracking shows the order's progress, not anyone's location. If you **share your tracking link**, the person you send it to sees that one order's status and, once it is on its way, the rider on the map. The link shows **no name, no phone number and no order history**, and it cannot be guessed. See [Share your order tracking](https://blog.laayo.com.np/share-your-order-tracking). ## Riders and restaurants see only what they need - **Restaurants** see what you ordered and the notes you added for the kitchen. - **Riders** see what they need to deliver: the pickup, your delivery location and how to contact you about the order. - If you choose to share an **accessibility need**, only the rider delivering your order sees a short card about it. Restaurants do not. See [Designing for everyone](https://blog.laayo.com.np/designing-for-everyone-accessibility). ## Chat and support Order chat keeps the conversation about one order in one place. Support conversations are seen by Laayo's support team so they can help you. When an AI assistant answers first in support chat, it works with what the task needs, and it hands the chat to a person whenever needed. See [How Laayo uses AI](https://blog.laayo.com.np/how-laayo-uses-ai). ## Crash reports When the Laayo app crashes, it sends a technical report so our engineers can fix the problem. These reports are set up to **leave out personal details**: screenshots are turned off, and things like email addresses and phone numbers are masked before a report is stored. See [Laayo's tech stack, part five](https://blog.laayo.com.np/tech-stack-part-five-observability). ## Messages from Laayo Laayo sends notifications about your orders, and sometimes suggestions or offers. We try to keep them useful and limited. You can control notifications in your phone's settings. ## Deleting your account You can ask Laayo to delete your account at any time from [laayo.com.np/delete-account](https://laayo.com.np/delete-account). ## Questions If you have a question about your data, write to **support@laayo.com.np** or call **9707055875**. ## Quick answers ### Does Laayo store my card details? No. With E-Payment you approve the payment in your own bank or wallet app by scanning a QR code. Laayo does not ask for or store card numbers or bank logins. ### Who can see my location when I order? The rider delivering your order sees your delivery location. If you share a tracking link, the person you send it to sees that order's status and, once it is on its way, the rider on the map. ### Does a shared tracking link show my phone number? No. A shared tracking link shows one order's status only, with no name, phone number or order history. ### Where is Laayo's privacy policy? The official privacy policy is at laayo.com.np/privacy-policy. ### How do I delete my Laayo account? Request deletion at laayo.com.np/delete-account, or contact support@laayo.com.np. --- # How Laayo makes money > A plain explanation of our revenue lines, from restaurant commission and delivery fees to memberships and software for businesses, and why we built them in this order. - Source: https://blog.laayo.com.np/how-laayo-makes-money - Section: Investors - Author: Laayo Leadership (Laayo Services Pvt. Ltd.) - Published: August 26, 2026 - Topics: Business model, Revenue, Laayo Plus, Qora, Laayo Biz People often ask how a delivery app in a smaller town can be a real business. It is a fair question. Margins in delivery are thin everywhere, and the economics only work if every part of the system pulls its weight. This post explains, in plain terms, where Laayo's revenue comes from today and how the lines fit together. We do not share figures here. What we want to show is the shape of the business. ## 1. Restaurant and shop commission When a customer orders through Laayo, the restaurant or shop pays us a commission on the order. This is the core of most delivery businesses and it is the core of ours. In return, partners get things that would be hard or expensive to build alone: new customers who would never have called them, a rider fleet they do not have to hire, an app to manage their menu and orders, E-Payment collection, and regular payouts with a full statement of every order, fee and adjustment. We keep the deal simple. A partner should be able to understand exactly what they paid for any order by reading their statement. Clear money builds trust, and trust keeps partners with us. ## 2. Delivery fees Customers pay a delivery fee that depends mainly on distance. Delivery fees help cover what it costs to get food from the kitchen to the door, most importantly what we pay riders. We think of delivery fees as a lever, not just a charge. Lower fees on short trips encourage people to order more often. Free delivery is one of the main benefits of membership. And in bad weather a small rain charge helps make sure riders are paid fairly for harder trips. ## 3. Laayo Plus Laayo Plus is our membership. Members pay a monthly fee and get free delivery on a set number of qualifying orders each month, priority support and other perks. Memberships matter to us for two reasons. They create steady, recurring revenue that does not depend on any single order. And they change behaviour: members tend to make Laayo their default, which makes every other part of the business stronger. ## 4. Qora: software for payments [Qora](https://qora.laayo.com.np) is a QR payment platform for Nepali businesses. Merchants use it to create dynamic QR codes, see payments arrive in real time and connect payments to their own systems through an API. Qora earns a subscription and a small per-transaction software fee, drawn from a prepaid credit balance. One detail matters a lot: **Qora never holds customer money.** Payments settle directly to the merchant through their own payment account. We sell software, not custody, which keeps the model simple and the risk low. ## 5. Laayo Biz: point of sale for restaurants [Laayo Biz](https://biz.laayo.com.np) is a point of sale and restaurant management system that runs in the browser and on a phone or tablet. Restaurants use it for billing, tables, kitchen order tickets, staff and reports. Each business gets its own separate, isolated data. Laayo Biz is a subscription. It also connects to the Laayo marketplace, so orders that arrive through the app can flow straight into the restaurant's point of sale. For a partner, that means one place to see everything. For us, it means a deeper, longer relationship with every restaurant that uses both. ![Our revenue lines, two kinds of customer: consumers pay delivery fees and memberships, businesses pay commission and software subscriptions](https://blog.laayo.com.np/media/seed/investor-revenue-lines.svg) ## Why this order We did not build all of these at once, and the order was deliberate. **Delivery came first** because it is the service people use most often and it builds the networks everything else depends on: customers, partners, riders and payments. **Membership came next** because once people order regularly, a membership turns occasional customers into loyal ones and adds revenue that repeats every month. **Software for businesses came after** because by then we already had relationships with restaurants and shops, and we had already built the payment and operations tools for our own use. Turning those tools into products was a natural step. A restaurant that uses Laayo for delivery, Laayo Biz for its counter and Qora for payments is a restaurant with every reason to stay. ## What we will not do Some ways of making money would hurt the business we want to build, so we avoid them. - **We do not hide fees.** Customers see delivery fees and charges before they order. Partners see every deduction on their statement. - **We do not hold other people's money longer than we need to.** Partners are paid on a regular schedule, and Qora does not hold customer funds at all. - **We do not buy growth with discounts we cannot sustain.** Offers are useful, but a business that only works when it pays people to use it is not a business. ## The shape of the opportunity Each line on its own is modest. Together they reinforce each other. Delivery brings customers and partners. Membership keeps customers. Software keeps partners. Payments run underneath all of it. That combination is what we think makes Laayo different from a delivery app alone, and why we believe a business built in smaller towns can be a strong one. You can read more about how the products connect in [one company, four products](https://blog.laayo.com.np/one-company-four-products). --- # Who founded Laayo > Laayo was founded by Sakshyam Baral, a full-stack developer from Nepal. A short introduction to the founder and how leadership at Laayo works. - Source: https://blog.laayo.com.np/who-founded-laayo - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: August 20, 2026 - Topics: Laayo, Founder, Leadership People often ask who is behind Laayo. Here is the short answer, using only what the founder has shared publicly. ## The founder **Laayo was founded by Sakshyam Baral**, a full-stack developer from Nepal. He built Laayo in **Birtamod, Jhapa**, as a food and grocery delivery app for his home town, and it now serves Birtamod, the towns around it in Central Jhapa, and Damak. In his own words on his founder page: "I'm Sakshyam Baral, a full-stack developer from Nepal. Laayo is the food and grocery delivery app I founded in Birtamod, Jhapa." Sakshyam's background as a developer explains a lot about how Laayo works. From the start, Laayo built its own technology instead of renting someone else's platform: the customer app, the rider app, the partner app, the admin tools and the systems behind them. You can see that thinking across our [tech stack series](https://blog.laayo.com.np/tech-stack). ### Where to read more - **Founder page:** [laayo.sakshyambaral.com.np](https://laayo.sakshyambaral.com.np) - **Personal website:** [sakshyambaral.com.np](https://sakshyambaral.com.np) - **GitHub:** [github.com/SakshL](https://github.com/SakshL) ## The company Laayo is operated by **Laayo Services Pvt. Ltd.**, a Nepali company based at **New Kanchanjunga Tole, Birtamod**, in Koshi Province. The same company runs **Laayo Plus**, **Qora** (QR payment software for businesses) and **Laayo Biz** (a point of sale for restaurants). See [Laayo at a glance](https://blog.laayo.com.np/laayo-at-a-glance) for the full fact sheet. ## How leadership works at Laayo Laayo is a small, close team. Decisions are made close to the work, by people who use the app themselves and know the towns we serve. A few habits guide how we lead: - **Start with the people on the road.** Riders, restaurant partners and customers tell us what is broken long before any chart does. We listen to them first. - **Build it ourselves when it matters.** If something touches the order, the payment or the delivery, we want to own it and be able to fix it quickly. - **Be honest in public.** We say what is live, what is rolling out and what is only a plan. Our [Investors page](https://blog.laayo.com.np/investors) follows the same rule. - **Grow carefully.** We started small on purpose and move to new towns only when we and our partners are ready. More in [We started small on purpose](https://blog.laayo.com.np/starting-small-on-purpose). Articles written by the leadership team appear under **Laayo Leadership** on this blog, starting with [Why we are building Laayo](https://blog.laayo.com.np/why-we-are-building-laayo). ## The people behind every order A founder starts a company, but a delivery service runs on many people. Behind every Laayo order there is: - **The rider** who picks it up and brings it to your door, in sun and in monsoon rain. - **The restaurant or shop partner** who cooks or packs it with care. - **The operations team** who watches orders through the day, helps riders and partners when something goes wrong, and keeps each town running smoothly. - **The support team** who answers chats and calls, and steps in whenever the support assistant hands a conversation over. - **The people who build Laayo**, who design, write and run the apps and systems. Every one of them is part of how Laayo works, and every one of them shapes the decisions we write about on this blog. ## Contact - **Customers and partners:** support@laayo.com.np or 9707055875 - **Investors, partners and press:** the form on our [Investors page](https://blog.laayo.com.np/investors) ## Quick answers ### Who is the founder of Laayo? Laayo was founded by Sakshyam Baral, a full-stack developer from Nepal. ### Where was Laayo founded? Laayo was founded in Birtamod, Jhapa, Nepal, where Laayo Services Pvt. Ltd. is still based. ### Which company runs Laayo? Laayo is run by Laayo Services Pvt. Ltd., which also operates Laayo Plus, Qora and Laayo Biz. ### How can I contact Laayo's leadership? Use the contact form on the Investors page at blog.laayo.com.np/investors. For orders and support, email support@laayo.com.np or call 9707055875. --- # A tour of the Laayo partner app, for restaurants > What a restaurant does in the Laayo partner app on a normal day, from accepting the first order to checking payouts and asking our team for help. - Source: https://blog.laayo.com.np/laayo-partner-app-tour - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: August 18, 2026 - Topics: Partners, Restaurants, Partner app, Guides Every restaurant on Laayo runs its side of the business from one app: the **Laayo partner app** (some people still call it the vendor app). This guide walks through a normal day in it, in the order most kitchens use it. If you have not joined yet, start with [joining Laayo as a restaurant partner](https://blog.laayo.com.np/joining-laayo-as-a-restaurant-partner). ## What is the Laayo partner app? It is the app restaurants and shops use to receive and manage Laayo orders. The owner signs in, and staff can have their own logins with the access the owner chooses. The same app works for a single kitchen or for a group of brands that share one kitchen, with a switcher at the top to move between restaurants. More on that in [one kitchen, many brands](https://blog.laayo.com.np/one-kitchen-many-brands). ## How do I open and close my restaurant? Your opening hours are set once, and Laayo follows them automatically. When you need to close early, run out of gas or simply take a break, you switch the restaurant off in the app. Customers then see you as closed: they can still browse your menu, but they cannot place an order until you are open again. We explain why we built it that way in [the truth about open and closed](https://blog.laayo.com.np/store-open-or-closed-the-truth). ## How do I accept an order? A new order arrives with a loud alert on the phone or tablet at the counter. The order card shows the items, any add-ons and notes, how the customer is paying and when a rider is expected. 1. **Accept** the order to tell the customer and the rider that you are on it. 2. **Cook.** Move the order to processing so everyone can see the kitchen has started. 3. **Hand over.** When the rider arrives, mark the order as handed over. The rider confirms pickup on their side. If an order is not accepted in good time, Laayo reminds you with an automatic phone call in Nepali, so a busy kitchen does not miss it. We wrote about that in [reminding restaurants to accept](https://blog.laayo.com.np/reminding-restaurants-to-accept). ## Can I chat with the rider or the customer? Yes. Each order has its own chat, so questions like "no onions?" or "which gate?" stay attached to the order they belong to. You can also see which riders have delivered for you recently, with a call button, under Delivery Partners. ## How do I change my menu? Everything about your menu lives in the app: - **Items** with photos, prices, descriptions and categories. - **Variations** such as half and full plate, and **add-ons** such as extra cheese. - **Availability.** Turn a single dish off when it sells out and back on when it returns, without touching the rest of the menu. If you are starting from a printed menu, our team can read it from a photo and set it up for you to check. See [a menu from a photo](https://blog.laayo.com.np/a-menu-from-a-photo). ## How do offers and coupons work? From the app you can join Laayo campaigns and create your own offers on selected dishes. The app shows what the customer will see before you save. We take care that the discount shown and the amount billed always match, which we explain in [offers that add up](https://blog.laayo.com.np/offers-that-add-up). ## Where do I see my sales and reviews? - **Reports and business insights** show your orders and sales over the period you choose, and your best sellers. - **Reviews** show what customers said about your food, so you can thank them or fix a recurring problem. - **Payouts** show what Laayo has sent to your bank and what is on the way. Each payout comes with a full statement. See [getting paid on time](https://blog.laayo.com.np/getting-paid-on-time-as-a-partner). ## How do I get help from Laayo? You can call or message the Laayo team at any time. Inside the partner app we are rolling out **support tickets**: you pick what the problem is about, describe it, and follow every reply in one thread until it is solved. Tickets reach our team straight away and stay on record, so nothing depends on someone remembering a phone call. ## Can my staff use the app? Yes. The owner adds employees, and each one signs in with their own account. Staff can take orders and manage the menu while the owner keeps control of payouts and settings. Order alerts and reminders go to staff phones too, so the counter is covered when the owner is away. ## Quick answers ### Is the Laayo partner app free for restaurants? Joining Laayo and using the partner app does not need any special hardware. Any recent Android phone or tablet is enough. Commercial terms are agreed with each partner when they sign up. ### Can I pause orders without closing for the day? Yes. Switch the restaurant off in the app and switch it back on when you are ready. Your regular hours stay as they are. ### What happens if I miss an order alert? Laayo calls the restaurant automatically with a short reminder, and our team is alerted if the order still is not accepted. ### Can I run several brands from one kitchen? Yes. Linked restaurants appear in one switcher, and each brand keeps its own menu and its own payouts. ### How do I see how much Laayo has paid me? Open Payouts in the app. Every payout has a statement listing the orders it covers. --- # How to order food on Laayo, step by step > Download the app, set your location, pick a restaurant, check out and follow your rider live. A plain guide to ordering food on Laayo in Birtamod and Damak. - Source: https://blog.laayo.com.np/how-to-order-food-on-laayo - Section: Guides - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: August 18, 2026 - Topics: Guides, Ordering, Getting started Laayo is a food and grocery delivery app for Birtamod, Damak and nearby areas of Jhapa in eastern Nepal. Local restaurants and shops list their menus on Laayo, and our own riders bring the order to your door. This guide walks through a first order from start to finish. ![Ordering on Laayo in five steps: get the app, set your location, choose food, check out, follow your order](https://blog.laayo.com.np/media/seed/guide-order-steps.svg) ## Where do I get the Laayo app? Laayo is available for iPhone on the App Store and for Android phones on Google Play. Search for "Laayo" and install the app with the yellow and charcoal Laayo logo. You can also look around on the web. The Laayo website at [laayo.com.np](https://laayo.com.np) shows restaurants and menus, and a new web experience at new.laayo.com.np lets you browse restaurants, dishes and groceries in Birtamod and Damak. For placing and tracking orders, the app is the smoothest way today. ## How do I sign in? Open the app and enter your mobile number. Laayo sends a one-time code by SMS, you type it in, and you are signed in. There is no password to remember. New customers add their name once, and that is the whole sign-up. You can look around before signing in. To add food to your cart and order, you need to be signed in, so that the restaurant, the rider and our support team know who the order is for. There is more about accounts in [Your Laayo account](https://blog.laayo.com.np/your-laayo-account). ## How do I set my delivery location? Laayo asks for your location so it can show restaurants that deliver to you. You can use your phone's GPS or move the pin on the map yourself. A few tips that make deliveries smoother: - **Put the pin exactly on your gate or building.** Riders follow the pin, so the closer it is, the faster they find you. - **Add a landmark.** In our towns, "opposite the school" or "behind the temple" often helps more than a street name. - **Save your addresses.** Home, work and family addresses can be saved and picked again next time. If your pin is outside the areas we deliver to, the app tells you so. See [Where does Laayo deliver?](https://blog.laayo.com.np/where-laayo-delivers) for how coverage works. ## How do I find something to eat? The home screen shows restaurants that deliver to your location, along with collections, offers and dishes people near you order often. You can: - **Search** for a dish or a restaurant. Search understands common spellings, so "chicken momo" and "chiken momo" both work. - **Filter** by things like rating, veg options or offers. - **Open a restaurant** to see its full menu, photos, reviews and whether it is open right now. Restaurants that are closed still show their menu, so you can plan ahead, but you cannot order until they open. ## How do I add items and check out? Tap ADD on a dish. Some dishes have choices, such as size or extra toppings, and the app asks before adding them. When you are ready, open the cart. At checkout you can: 1. Check your items and quantities. 2. Confirm the delivery address and add delivery instructions for the rider. 3. Apply an offer or coupon if one is available. 4. Choose how to pay: cash on delivery, E-Payment by QR, or your Laayo wallet. See [How to pay on Laayo](https://blog.laayo.com.np/how-to-pay-on-laayo). 5. Tap Place order. The cart shows the full bill before you pay, including item prices, delivery fee, any packaging charge and any discount, so there are no surprises at the door. ## What happens after I place the order? The restaurant receives your order and accepts it, the kitchen prepares it, a rider is assigned and picks it up, and the rider brings it to you. The app moves you to the tracking screen on its own, where you can see each step and follow the rider on the map once your food is on its way. You can chat with the restaurant, the rider or Laayo support from the order. There is a full explanation in [Tracking your order](https://blog.laayo.com.np/tracking-your-order). ## Can I order from more than one restaurant? Ordering from more than one restaurant in a single checkout is rolling out. Read [One cart, many restaurants](https://blog.laayo.com.np/one-cart-many-restaurants) for how it works. You can also order with friends using [group orders](https://blog.laayo.com.np/ordering-together-with-group-orders). ## Quick answers ### Is Laayo available on iPhone and Android? Yes. Laayo is on the App Store for iPhone and on Google Play for Android. ### Do I need an account to order? You can browse without signing in, but placing an order needs a quick sign-in with your mobile number and a one-time SMS code. ### Can I order on the website? You can browse restaurants and menus on laayo.com.np and new.laayo.com.np. The Laayo app is the recommended way to place and track orders. ### Can I order from a restaurant that is closed? You can see its menu, but you can only place an order while the restaurant is open. ### How do I tell the rider where to come? Place the map pin on your gate, add a landmark, and use the delivery instructions box at checkout. --- # Paying with a QR, without leaving the app > E-Payment used to bounce you out to a web page and back. Now the QR opens inside Laayo, the app sees when you scan, and your cart waits for you if anything goes wrong. - Source: https://blog.laayo.com.np/paying-with-a-qr-inside-the-app - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: August 14, 2026 - Topics: Payments, E-Payment, Wallet, Scan and Pay Most people in Birtamod and Damak already pay for things by scanning a QR. The tea shop has one taped to the counter, the pharmacy has one, the bus counter has one. So when you choose E-Payment on Laayo, you already know what you want to do: open your bank app, scan, done. For a long time our checkout made that harder than it needed to be. Choosing E-Payment opened a web page inside the app, which loaded a payment page, which showed a QR. If you were on the same phone you were paying from, you had to screenshot that QR, switch to your bank app, find the screenshot, and hope the web page was still waiting when you came back. Sometimes it was not. Sometimes the page reloaded and showed a fresh QR. And sometimes people paid, came back, and saw nothing, which is the worst feeling in online payments. This post is about how we rebuilt that moment. ## The QR now lives inside Laayo When you place an order and pick E-Payment, Laayo now shows its own payment screen. There is no web page in between. The screen shows the amount, the QR and a short countdown, and it has two buttons that matter on a single phone: **Download QR**, which saves the code to your photos so your bank app can read it from the gallery, and a way to try again if the code runs out. ![How an E-Payment works in the app: the QR is shown inside Laayo, the app notices the scan, and confirms the payment before your order goes to the restaurant.](https://blog.laayo.com.np/media/seed/qr-payment-flow.svg) While the screen is open, the app keeps checking whether the payment has arrived. When it does, you go straight to your order. You do not need to press anything, and you do not need to come back to a browser tab. We used the same screen everywhere money moves by QR in the app: - placing an order, - paying for an order that is already on its way, - adding money to your Laayo Wallet, - buying a gift card. One screen means one set of habits. If you have paid for an order this way, you already know how to top up your wallet. ## "Scanned" before "Paid" There is a gap of a few seconds between scanning a QR and your bank confirming the payment. On the old page that gap was silent, so people scanned again, or closed the screen to check their bank app. Now the app shows the moment you scan. The QR turns green and a **Scanned** mark appears over it. That is the whole message. We tried adding a line of text asking people to finish in their bank app, and took it out again, because the green code already says "we saw you, keep going". Getting this to feel instant took some work. Phones pause apps that are in the background, so when you switch to your bank app and come back, Laayo checks again the moment it returns to the front instead of waiting for its next turn. ## Your cart waits for you Here is a detail that most people never notice until it goes wrong. On Laayo the order is created first and paid for second. In the old flow, placing the order also emptied your cart. So if the payment failed or you backed out of the QR, you had a pending order you could not pay and an empty cart you could not reorder from. Now the cart stays exactly as it was until the payment is confirmed. If you leave the QR screen, the app asks if you are sure, then takes you back to your cart with a small sheet: **Retry** opens the QR for the same order, or you can pick another way to pay. Only when the money arrives does the cart clear itself. > **Note:** if you leave without paying, nothing is charged. The unpaid order simply expires on its own after a while. ## Scan & Pay at the counter Some of our partner restaurants and shops have a Laayo QR at the counter. You can scan it from the app, type the amount on your bill and pay with your Laayo Wallet, often with a partner discount shown right on the store card before you pay. In the next update, **Scan & Pay** gets its own page instead of jumping straight into the camera. You will see your Laayo Money balance, any bill a cashier has sent you that is waiting for payment, what you have saved on past bills, and the places you paid at recently. Tap the scanner tile and it grows into the camera. Point it at the counter QR and the corners close onto the code, the store card appears, and you land on the amount page. ## When your balance is a little short Another small moment that used to cost people: you are at the counter or in the cart, your wallet has a little less than the bill. Before, the app told you the balance was not enough and left you to find the Add Money screen on your own. In the next update the bar at the bottom says how much you are short, in orange, and the button becomes **Add & pay**, showing the exact amount you are short. Tapping it opens a small sheet with the exact shortfall already filled in (you can add more), and the QR appears right inside that same sheet. Once the money lands, the balance counts up, the button turns into **Pay bill**, and the payment starts by itself. If you change your mind halfway, the money you added stays in your Laayo Money for next time. ## What we chose not to do - **We did not add a "confirm in your bank app" banner.** The green QR and the Scanned mark do that job with less reading. - **We did not keep a live connection open from your phone to the payment network.** If the app holds that line and you switch to your bank app, the connection drops and the QR can be cancelled under you. Our server listens instead, and your phone only asks the server. - **We did not force a minimum top-up.** When you are short, the sheet starts at exactly what you need. ## What's next Payments are the part of an order where trust is easiest to lose and slowest to win back. Our rule is simple: you should always know whether your money moved, and you should never lose your cart because a payment did not go through. The Scan & Pay page and the low balance flow are rolling out in the next app update. --- # Share your order, not your phone > Someone else is often waiting at the gate. Live tracking now opens on its own after you order, and one link lets anyone follow the rider without installing the app. - Source: https://blog.laayo.com.np/share-your-order-tracking - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: August 9, 2026 - Topics: Tracking, Sharing, Privacy, Riders In our towns, the person who places the order is often not the person who opens the gate. A daughter at college orders lunch for her parents. Someone at the office orders for a colleague downstairs. A host orders snacks and then gets busy with guests. In all of these cases, the person waiting has no map to look at, so they end up asking the person who ordered, who then has to open the app and relay what it says. So we worked on two things: making sure the person who orders actually finds the tracking screen, and letting them share it with anyone in one tap. ## Tracking that opens itself We noticed that many customers never opened live tracking at all. After placing an order, the app showed a confirmation and then sent people back to the home screen. Tracking was there, but you had to know where to look. Now the confirmation moves you into tracking by itself. In the current app, the small handle at the top of the "Order placed" sheet fills up as a countdown, and when it is full you are on the tracking screen. If you want to save the address first, tapping the save button pauses the countdown, and finishing the save takes you to tracking too. Every way out of that sheet leads to tracking, so nobody ends up on the home screen wondering what happens next. In the new native app, rolling out now, the moment is a little more personal. After you tap Place order, a short bar fills while you can still cancel. Once it is sent, a full screen confirms the order with a chime and a gentle buzz, shows a pin and "Delivering to" with your address label, and then opens live tracking. While the tracking screen loads, you see a placeholder shaped like the tracking screen itself, not a spinner, so the page does not jump when the real content arrives. ![After you place an order, the app moves you to tracking, and a share link lets anyone follow along](https://blog.laayo.com.np/media/seed/share-tracking-flow.svg) ## One link for everyone else The tracking screen now has a Share control. It creates a short Laayo link to a web page that shows your order's live status and the rider on a map. The person you send it to does not need the app or an account. They just open the link. A few rules keep this safe and simple: - **The link shows one order, nothing else.** No name, no phone number, no order history. Each link carries a long random token, so links cannot be guessed by counting. - **The rider appears only once your food is on its way.** Before pickup the page shows the order's progress, not anyone's location. This is the same privacy rule the app follows. - **Old links keep working.** We moved to a shorter link format, but every link already sent in a chat still opens. ## Sharing at the moment you think of it Here is a small habit we noticed: when people want to show someone where their order is, they take a screenshot. A screenshot is a frozen picture of a moving thing. By the time it arrives, it is wrong. So when you take a screenshot of your tracking screen, the app now offers a small sheet with a copyable live link. You can still share the screenshot if you want. The link just sits there as the better option. On iPhone this works on all supported versions. On Android it works on newer versions of Android, which can tell an app that a screenshot was taken without asking for permission to read your photos. Older versions could only do it by asking for access to your entire photo library, just to notice a screenshot. We decided that trade was not worth it, so on older Android phones you share from the Share control instead. We were careful not to make this noisy. If you take several screenshots in a row, you see one sheet, not a stack of them, and if creating the link fails in the background, nothing pops up to bother you. ## A smoother map Sharing a map only helps if the map is good. The live map used to stutter on busy phones, because the app redrew the rider's scooter many times a second from the app's own code. We moved the map drawing into the phone's native map view, so the scooter now glides along the road smoothly while the rest of the screen stays exactly as it was. The rider marker shows the rider's photo, and when a rider marks that it is raining in their area, a small weather note appears on your tracking screen, so a slower ride does not come as a surprise. ## What's next We want the shared page to say what the rider sees too, for example "Rider is at the restaurant, food is being packed", in the same plain words as the app. We are also looking at letting the person you share with send a short note to the rider, such as "use the back gate", without needing your phone. --- # Why we are building Laayo > A letter from the people building Laayo. The gap we see in Nepal's smaller towns, what we are building to close it, and the beliefs that shape every decision we make. - Source: https://blog.laayo.com.np/why-we-are-building-laayo - Section: Investors - Author: Laayo Leadership (Laayo Services Pvt. Ltd.) - Published: August 4, 2026 - Topics: Laayo, Strategy, Nepal, Small towns Every company should be able to explain why it exists in plain sentences. Here are ours. Most of Nepal does not live in Kathmandu. It lives in towns like Birtamod and Damak: busy, growing places with good restaurants, crowded bazaars, schools, offices and families who own smartphones and pay with QR codes every day. Yet the digital services that make city life easier usually arrive in these towns last, if they arrive at all, and when they do, they arrive built for somewhere else. Laayo is our answer to that. We are building the everyday commerce layer for Nepal's smaller towns, starting with the thing people do most often: ordering food. ## The problem we saw Before Laayo, getting food delivered in our towns meant calling a restaurant, describing your house by the nearest temple or school, and hoping someone was free to bring it. Restaurants had loyal regulars but no simple way to reach new customers beyond their phone line and their front door. Young people who wanted flexible work had few options that paid fairly and predictably. None of this was because people did not want something better. Smartphones are everywhere. Digital payments have become normal. The demand was there. What was missing was a service designed for how these towns actually work. ## What Laayo is Laayo is a delivery app for food, groceries and everyday items, run by a local team, with a rider fleet that knows every lane in town. Around that core we have built the pieces a small town economy needs: - **The Laayo app** for customers, with live tracking, E-Payment and a wallet. - **A partner app** that lets restaurants and shops manage menus and orders and get paid on a regular schedule with clear statements. - **A rider app** built around a rider's real day: alerts that are hard to miss, a planner for multi-order runs and a transparent record of earnings and tips. - **Products for businesses beyond delivery**, including Qora for QR payments and Laayo Biz, a point of sale for restaurants. We write about those in [one company, four products](https://blog.laayo.com.np/one-company-four-products). ## What we believe These beliefs are not slogans. They are the reasons behind decisions we have already made. **Depth beats breadth.** A great service in a few towns is worth more than an average one in many. We would rather be the app a whole town trusts than a logo in many towns that nobody loves. That is why we [started small on purpose](https://blog.laayo.com.np/starting-small-on-purpose). **Local knowledge is an advantage, not a footnote.** Knowing which roads flood in monsoon, which shops close early on festival days and how people actually describe their addresses shapes the product in ways no spreadsheet can. Our addresses are pins dropped on a map because many homes have no street address anyone uses. Our delivery estimates account for rain because rain is real here. **Trust is the product.** In a small town, everyone talks. A late order, a cold meal or a payment that seems stuck is not a statistic, it is a conversation at the tea shop. So we invest heavily in the unglamorous parts: honest delivery times, clear payment status, support that reaches a real person and refunds you can follow. **Riders and partners are customers too.** A delivery business only works if the people cooking and riding want to be part of it. Fair, predictable pay for riders and on-time payouts for restaurants are not costs we minimise, they are what keeps the whole system running. **Build lean, build well.** We are a small team, so every engineering choice has to earn its place. We run a well understood core, measure before we optimise and only replace what is actually slow. We explain this in [building lean](https://blog.laayo.com.np/building-lean) and in our [tech stack series](https://blog.laayo.com.np/tech-stack). ## Why now Several things have come together recently. Smartphones are now the default in our towns, not the exception. QR and wallet payments have become everyday habits, so paying a stranger on a phone no longer feels risky. And a generation of young people wants work that fits around study, family and farming seasons. Those shifts make a service like Laayo possible in places where it would not have worked before. They also mean that whoever builds the most trusted service in these towns now will be very hard to dislodge later. ![What Laayo connects: customers, restaurants and shops, and riders, with E-Payment and support running underneath every order](https://blog.laayo.com.np/media/seed/investor-what-laayo-connects.svg) ## What we want to be Over time we want Laayo to be the first app people in Nepal's growing towns open when they need something: a meal, groceries, a way to pay, a way to run their shop. We want restaurants to see Laayo as the partner that helped them grow. We want riders to see it as work they are proud of. We are not there yet. We write openly on this blog about what works and what we are still fixing, because we think honesty is the only way to build something that lasts. Thank you for reading, and for your interest in what we are building. If you would like to talk with us about Laayo, our [investors page](https://blog.laayo.com.np/investors) is the best place to start. --- # Riding through the monsoon > When the rain comes down in Jhapa, everything about delivery changes. Why we let riders, not a weather app, say when it is raining, and how rain shapes the delivery time you see. - Source: https://blog.laayo.com.np/riding-through-the-monsoon - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: August 4, 2026 - Topics: Riders, Monsoon, Delivery time Anyone who has lived through a Jhapa monsoon knows the moment. The sky goes dark in the middle of the afternoon, the first fat drops hit the tin roofs, and within a few minutes the road outside is a river. People stay indoors. And a lot of them, quite reasonably, decide this is the perfect time to order momo. For a delivery service, the monsoon is the hardest season of the year. It is also when people need us most. This post is about how we have shaped Laayo around the rain. ## The problem with weather apps When it rains, two things should change on Laayo straight away: 1. Delivery times should become more realistic, because every ride takes longer. 2. Riders should be paid a little more for going out in it, which is covered by a small rain charge on delivery. To do either, Laayo first has to know that it is raining. Our first approach was the obvious one: ask a weather service. It did not work well for us. Weather data for our towns is coarse, it often lags behind what is happening on the ground, and a storm can soak one side of Birtamod while the other side stays dry. Customers would see a rain charge on a sunny evening, or no rain charge during a downpour. We also could not rely on someone in the office flipping a switch. When the rain hits, the operations team is busy helping with orders, not watching the sky. ## Riders know first The people who know for certain whether it is raining are the ones riding in it. So we gave them the switch. In the rider app there is a **Weather** option on the profile screen. When it starts raining, any rider on shift can report it. When it stops, any rider can turn it off. The change applies to the whole zone straight away: - customers start seeing the rain charge at checkout, with a banner on the store screen explaining why, - riders on the road get a quiet notification so their app shows the current state, - the delivery time estimates know that the roads are wet. Before a rider changes it, the app shows a short confirmation explaining that it applies for every customer in the area. It is a real responsibility, and riders treat it like one. The app also records who changed it and when, which keeps it honest. ![How rain reaches the app: a rider reports rain, the zone switches to rain mode, customers see a banner and an updated delivery charge, other riders are notified, and delivery time estimates account for wet roads.](https://blog.laayo.com.np/media/seed/rain-report-flow.svg) We kept the rules deliberately simple. There is one rain switch for the zone, not a vote. It stays on until a rider turns it off. Our team can still change the setting from the admin side, and whenever they switch the mode, the rain state resets so an old "it's raining" from days ago can never linger. ## What rain does to delivery time Rain does not slow everything down by the same amount. Kitchens cook at roughly the same speed. What changes is the road: riders go slower on wet tarmac, some lanes flood, and everyone takes a little more care at junctions. Our delivery time estimates are learned from real past deliveries. Each order remembers whether it was placed in rain mode, and the model that predicts delivery times uses that as one of its signals, alongside things like the time of day, how busy the kitchen is and the road distance. When rain mode is on, the time you see on a restaurant card already includes the extra minutes rain tends to add. That matters more than it sounds. A delivery app that promises a quick delivery in a downpour and then arrives far later has not just been late, it has broken a promise. A realistic, longer estimate that arrives a little early feels good. In the monsoon, honest beats fast. ## Keeping riders safe No order is worth an accident. A few things we ask of everyone during heavy rain: - **Customers:** please be patient, pin your location carefully, and keep your phone nearby so your rider can call if a lane is flooded. - **Riders:** slow down, avoid flooded stretches even if the map says they are shorter, and keep your phone dry. If conditions become dangerous, stop and tell us from the app. - **Restaurants:** pack food so it survives a wet ride, with lids sealed and bags closed. Riders on gigs earn rain surge on deliveries made in rain mode, so going out in bad weather is recognised in their pay, not just in our thanks. ## What we learned The rain switch taught us something that applies well beyond weather. The best signal is often a person who is already there. Our riders spend all day on the roads of Birtamod and Damak. They know when a road is blocked, when a market is closed and when the rain has started. Giving them a simple, trusted way to tell the system has made Laayo more accurate than any outside data source we tried. So the next time it pours and your app quietly updates to show rain mode, there is a good chance it was a rider who flipped the switch, standing under a shop awning, before heading back out with your dinner. --- # A whole menu from one photo > Typing in a restaurant menu by hand could take an afternoon. Now our team drops in a photo or a PDF of the menu, checks what the AI read, and has the restaurant ready far sooner. - Source: https://blog.laayo.com.np/a-menu-from-a-photo - Section: Company - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: July 28, 2026 - Topics: Partners, Menus, AI Before a restaurant can take its first order on Laayo, its menu has to exist on Laayo. Every dish, every size, every price. For a small momo shop that might be a short list. For a family restaurant with a Nepali, Indian, Chinese and continental section, it can run to pages and pages. For a long time, that meant someone on our team sitting with a printed menu, a laptop and a lot of patience. Steamed buff momo, half plate, full plate. Fried buff momo, half plate, full plate. Then the same again for chicken. Then for veg. It was slow, it was easy to make mistakes, and it was the single biggest reason a new partner had to wait before going live. So we built a tool that reads the menu for us. ## Drop in the menu The **AI menu upload** lives in our admin panel. It is built like a chat: you drop in the restaurant's menu, as one or more photos or as a PDF, and it replies with what it found. Behind the scenes, each page of the menu is sent to a vision model that reads it the way a person would. It understands section headings, so it knows that "Chowmein" under "Chicken" means chicken chowmein. It picks up sizes and portions, half and full plates, small and large, and their prices. It also suggests which Laayo category each dish belongs in. Large menus are split into batches that are read at the same time, so a long menu does not take much longer than a short one. While it works, the chat shows a live progress bar: pages prepared, batches done and how many dishes it has found so far. ![From menu photo to live dishes: upload the photo or PDF, AI reads dishes, sizes and prices, our team reviews and edits, then the dishes are created on the restaurant's menu.](https://blog.laayo.com.np/media/seed/menu-photo-flow.svg) ## A person always checks AI is very good at reading menus, but it is not perfect. Handwritten specials, faded print, a price that sits awkwardly between two dishes: any of these can trip it up. So nothing goes live without a person looking at it first. When the reading is done, the results appear in an editable table. Every row is one dish, with its name, category, price and sizes. Our team can: - fix a name or a price with one click, - open a dish to edit its sizes, for example "Half plate" and "Full plate", each with its own price, - remove anything that is not really a dish, like a heading that slipped through, - move a dish to a different category. Only when the table looks right does anyone press the button that creates the dishes on the restaurant's menu. Sizes become proper choices in the app, so a customer ordering a full plate sees the right price straight away. ## Descriptions that help people choose A dish name alone is often not enough. "Chef's special thali" could be almost anything. Good short descriptions help customers order with confidence, and they help search find the dish when someone types what they are craving rather than the exact name. Many dishes on Laayo had no description at all, so we added a companion tool that writes short ones. It lists dishes without a description, our team can generate a suggestion for one dish or a whole page at once, and every suggestion can be edited before it is saved. We keep them short on purpose: one clear line about what is in the dish, not a paragraph of adjectives. ## Where the menu photo comes from This tool fits neatly with the new partner sign-up. When a restaurant applies through the Laayo app, one of the steps asks for photos of the menu, and those files go straight into the restaurant's documents. By the time our team picks up the application, the menu is already there, ready to be dropped into the upload tool. The result is a much shorter path from "I would like to join" to "your first order is here": 1. The owner applies in the app and attaches the menu. 2. Our team reviews the application. 3. The menu is read quickly and checked by a person. 4. The restaurant goes live. ## Why we care about speed here For a restaurant, the days between deciding to join and taking the first order are the most fragile. Excitement fades if nothing happens. Menus change. Owners get busy. Every day we shave off that wait makes it more likely the partnership actually starts. For us, it frees our team to spend their time where people are needed: visiting restaurants, taking good photos of dishes, explaining how Laayo works and listening to what partners need. Typing in prices was never the best use of anyone's afternoon. ## Keeping menus fresh Menus do not stand still. Prices change, dishes come and go, and specials appear for festivals. When a partner sends us a new menu, the same tool reads it and our team checks it against what is on Laayo, so updating a menu is no longer a chore that waits for a quiet day. If you are a partner and your menu has changed, send us a clear photo through partner support. It will not take us an afternoon any more. --- # Designing for everyone who orders, and everyone who delivers > An optional accessibility profile, a short note for the rider at your door, and the small rules in our apps that respect how you have set up your phone. - Source: https://blog.laayo.com.np/designing-for-everyone-accessibility - Section: Design - Author: Laayo Design (Laayo Services Pvt. Ltd.) - Published: July 22, 2026 - Topics: Accessibility, UX, Riders The last few metres of a delivery are the most personal part of the whole order. A rider arrives, calls, knocks, waits at the gate. For most people that moment is over in seconds. For someone who cannot hear the phone ring, cannot see which rider is theirs, or cannot easily come downstairs, it can be the hardest part of ordering food at all. We wanted Laayo to handle that moment better, without making anyone fill in a form they do not need and without turning a private detail into a label. This post explains what we built and the rules we follow across the apps. ![How an accessibility preference travels: the customer chooses it once in the app, it rides along with each order, and the rider sees a short card with practical guidance on the order screen.](https://blog.laayo.com.np/media/seed/accessibility-flow.svg) ## An optional profile, asked once In the Laayo app, under Menu and then More, there is an accessibility section with three simple questions: - **Hearing.** Deaf, hard of hearing, or neither. - **Vision.** Blind, low vision, or neither. - **Mobility.** Wheelchair user, other physical disability, or neither. Every question is optional. We never show it as a pop-up, never ask during checkout and never make it a step in sign-up. If you skip it, nothing changes. If you answer "neither", nothing changes either. We store "not answered" separately from "neither", so we never assume something about anyone who has not told us. You can change or clear your answers at any time from the same place. ## What the rider sees A preference is only useful if it reaches the person at your door. When a customer has shared an accessibility need, the rider's order screen shows a short card under the customer details. It is written as guidance, not as a diagnosis: - For a customer who is deaf or hard of hearing, the card asks the rider to send a message instead of calling. - For a customer who is blind or has low vision, it asks the rider to call on arrival and help guide them to the order. - For a customer who uses a wheelchair or has limited mobility, it asks the rider to deliver right to the door. The card only appears when there is something to act on. Riders do not see an empty box for every other customer, which keeps the card noticeable when it does appear. We are making sure every rider app in the field shows it as rider app updates roll out. ## Why we keep it small We made a few deliberate choices to keep this respectful: - **Three questions, plain words.** A longer list starts to feel like a medical form. Three questions cover the things a rider can actually do something about. - **No public badge.** Nothing about your answers appears on your profile, your reviews or anything other customers can see. - **Only where it is needed.** The rider sees it with the order they are delivering. Restaurant partners do not see it, because it does not change how they cook. - **It travels with the order.** We attach the preference to the order details the rider already loads, so there is no extra step and no extra screen for them to open. ## The app should follow your phone Accessibility is not only a settings page. It is also the many small ways an app either respects or ignores how you have set up your phone. A few rules we hold ourselves to in the new native apps: **Reduce Motion means reduce motion.** If you have turned on Reduce Motion on iPhone, or switched off animations in Android's developer or accessibility settings, our transitions become simple fades or happen instantly. Decorative animations, like seasonal skins on the home screen, do not start at all. **Everything tappable has a name.** Buttons that only show an icon, like back, search, share or the heart on a restaurant, carry a spoken label for VoiceOver and TalkBack. We add these labels as each native screen is built, rather than in a clean-up pass at the end. **Readable type and colour.** We chose Lexend as our typeface partly because it was designed for reading ease. We never put yellow text on a white background, because it fails contrast checks and is hard to read in sunlight. Text sits in charcoal, and yellow is used for fills behind charcoal text. **Status is never colour alone.** "Closed", "Delayed" or "Out of delivery area" are always written in words. Colour is a hint, not the message. **Calm feedback.** At most one gentle haptic per deliberate action, and never a vibration tied to an animation or a timer. For people who rely on touch, constant buzzing is noise, not information. ## Riders and partners use our apps too It is easy to think of accessibility only as a customer feature. Our riders read their phones on a moving scooter in bright sun, often with gloves. Our restaurant partners glance at a tablet across a hot kitchen. The same rules apply: large tap targets for the actions that matter most, clear words instead of colour, and alerts that are noticeable without being frantic. ## What we want to learn next We do not think we have this finished. A few things we want to understand better: - Which parts of ordering are still hard with a screen reader, from search to payment. - Whether customers would like to add a short delivery note of their own alongside their preference. - How riders actually use the card at the door, and what wording helps most. If you use Laayo with a screen reader, larger text or any other assistive setting, and something gets in your way, please tell us through support in the app. Those reports go straight to the team that builds the screens, and they are some of the most useful feedback we get. --- # Gift cards and Send a Treat, for when you can't be there > Two ways to feed someone you care about from wherever you are. A gift card that lands in their Laayo Wallet, and a treat delivered to their door while you pay. - Source: https://blog.laayo.com.np/gift-cards-and-send-a-treat - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: July 22, 2026 - Topics: Gifting, Gift cards, Wallet, Payments A lot of people who order on Laayo are ordering for someone else. A son in Kathmandu sending dinner to his parents in Birtamod. A sister abroad who wants her brother to have cake on his birthday. A team lead in Damak saying thank you to a colleague who stayed late. For a long time the only way to do that was to call someone nearby, read out an address, and send them money for the order. We built two features for this, and they solve slightly different problems. ## Gift cards: let them choose A gift card is the right present when you do not know what they want, or when you want them to order on their own time. You pick a design (Laayo, birthday, thank you, anniversary or get well), choose an amount, type the recipient's name and their email or mobile number, and add a short message if you like. You pay with E-Payment, right inside the app, using the same QR screen you use for orders. ![A gift card from purchase to the recipient's wallet: you pay, they get a code and PIN by SMS or email, and claiming it adds the amount to their Laayo Wallet.](https://blog.laayo.com.np/media/seed/gift-card-flow.svg) Once the payment is confirmed, the recipient receives a gift card code and a PIN by email, SMS or both. They open Laayo, go to **Gift cards & credits**, tap **Claim**, enter the code and PIN, and the amount lands in their Laayo Wallet. From there it works like any other wallet balance, on food, groceries or a bill at a partner counter. A few decisions behind that flow: - **The PIN is created only after the payment is confirmed.** There is never a valid card waiting for money that has not arrived. - **You, the buyer, never see the PIN.** Only the person it was meant for does. If a card is forwarded to the wrong person by mistake, the code alone is not enough to spend it. - **We check the recipient's details before you pay.** An email like "okk" or a mobile number with a digit missing is caught on the form, with a clear message, instead of failing quietly after the QR opens. Nepali mobile numbers work with or without +977 in front. ## Send a Treat: you choose, they eat Sometimes you do not want to send credit. You want to send *the momo from that place on the corner*, hot, tonight. That is what **Send a Treat** is for, and it is rolling out now. At checkout, turn on **Send a Treat**. Then: 1. Enter the recipient's name and mobile number. 2. Drop a pin where they are, on the same map you use for your own address. 3. Add a message and the name it should come from. 4. Decide whether the rider sees your number or only theirs. The recipient's pin becomes the delivery address for that order. That one decision does a lot of work: the delivery fee is worked out from their location, the rider calls them and not you, and the handover at the door works exactly like any other order. Nothing about the rider's side had to change. When the order is placed, the recipient gets an SMS saying a treat is on its way from you, with a link where they can follow the rider without installing anything. If they already use Laayo, they also get a notification. On your side, the order shows a small Treat banner and a **Share tracking** button, so you can send the live link on WhatsApp yourself if you prefer. If you send treats to the same people often, the app remembers your recent recipients. Tap a name and their number and pin are filled in. ## What we chose not to do - **Treats are prepaid only.** Cash on delivery for a gift means a rider asking a surprised person for money at their door. So when Send a Treat is on, cash options are hidden and you pay up front with E-Payment or your wallet. - **We did not build a separate gift delivery system.** A treat is an ordinary order with a little extra information attached. That keeps tracking, rider calls and support exactly as reliable as they are for every other order. - **Gift cards are not shareable by link.** It would be convenient to send the code and PIN on WhatsApp straight from the app, but that means showing the PIN to the buyer. For now we chose the safer path, and we may revisit it. - **Treats are for delivery from a restaurant, for now.** Takeaway and prescription orders do not offer it, because the whole point is that someone else receives the food. ## What's next We want gifting to feel as easy as ordering for yourself. Send a Treat is rolling out in stages, starting with the latest app version. If you send one, we would love to hear how it landed. --- # Notifications that are worth opening > We use AI to help write and time our push notifications, inside strict limits. Here are the rules that keep them useful: real dishes from real menus, no invented discounts, no shawarma at breakfast, and never more than one a day. - Source: https://blog.laayo.com.np/notifications-that-are-worth-opening - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: July 20, 2026 - Topics: Notifications, AI, Personalisation, Growth Push notifications are the easiest way to annoy people. Every app has sent you the vague "We miss you!" or the discount that turns out not to exist. Do that a few times and the customer switches notifications off, and then even the useful ones, like "your rider has arrived", stop getting through. We wanted notifications from Laayo to feel like a friend who knows what you like and what is open right now. That is a high bar, so we built the system around limits first and cleverness second. ## Two kinds of message Laayo sends two kinds of promotional notification. **Campaigns** are planned by our team. In the admin panel, someone picks an audience (for example, people who ordered once and never came back), writes a message or asks for a suggested one, chooses the channels (push, in-app inbox, SMS or email) and schedules it. Nothing goes out on its own. Before launch the panel shows how many people will receive it and what any SMS will cost, and a test send goes to our own phones first. **AI notifications** run on their own through the day. A small service looks at what is happening on Laayo right now (which restaurants are open, what is selling, what time of day it is) and drafts messages for groups of customers. A second lane writes personal messages for individual customers based on their own taste. Both are written by a language model, but the model is boxed in by rules that live in our code, not in its instructions. ![What the AI is allowed to see, what it decides, and the checks every message passes before it is sent](https://blog.laayo.com.np/media/seed/notification-guardrails.svg) ## Rule one: the dish has to be real Our first personal messages had an embarrassing flaw. The model was given two lists: what was selling well across town, and each customer's favourite restaurant. Sometimes it combined them, recommending a dish from one restaurant "at" another restaurant that did not make it at all. We caught ourselves promoting shawarma at a place with no shawarma on the menu. So we took that decision away from the model. Our code now picks the dish first, using plain rules: - The dish is on the restaurant's own menu, approved and available. - The restaurant is active, not temporarily closed, and serves that dish at this time of day. - If you mostly order vegetarian food, the pick is vegetarian. - We do not suggest a dish we already suggested to you recently. Only after that does the model see anything, and its only job is to write the words. Then we check its sentence: if it does not name the chosen dish, or if it names any other restaurant, the message is thrown away. It is better to send nothing than to send something untrue. ## Rule two: no invented discounts Language models love to sound generous. Left alone, they add a percentage off or "free delivery today" to everything. So by default our AI notifications are not allowed to mention any discount at all, and a filter catches and discards drafts that slip one in anyway. When we do want a message to mention an offer, it can only quote a real, active coupon, word for word, with its real conditions. No made-up minimum orders, no imaginary codes. ## Rule three: the right food at the right time An early message wished someone "good morning" and suggested a heavy dinner dish. Technically correct, practically ridiculous. Each part of the day now comes with guidance on what fits, from tea and breakfast in the morning to proper meals at lunch and dinner. The model must pick from what suits the time, the greeting has to match the clock, and in the morning a favourite heavy dish can only be mentioned as an idea "for lunch later". ## Rule four: fewer, not more This is the rule that matters most. Our limits, set in code: - **At most one AI notification per person per day**, across both lanes. If you received a group message, you will not also get a personal one. - **A weekly cap shared with campaigns**, so a busy campaign week means fewer AI messages, not more. - **A minimum gap between sends** and a rest period for each audience group, so nobody gets a burst. - **SMS has quiet hours** at night, and a spend cap. The service paces itself through the day. If it is behind its plan, it is allowed to send when something genuinely fits. It is never allowed to send just to hit a number. Every message opens a specific, checked place in the app: the restaurant it mentions, search, your favourites, your wallet. A link to something that does not exist is rejected before sending. ## How we know it is working Counting everyone who ordered after receiving a message flatters every campaign, because many of those people would have ordered anyway. So we are adding holdout groups: a small slice of each audience that matches but does not get the message. Comparing the two tells us whether a campaign actually brought in orders. The same approach is coming to always-on messages such as welcome and win-back flows. ## What's next We want customers to have more control: a simple setting for "fewer suggestions" or "only offers", and the ability to mute suggestions from a specific restaurant. We also want restaurants to see when a notification featured their dish, so they can make sure it is ready when the orders arrive. --- # How riders earn at Laayo, and why the number on the card is the number you get > Some Laayo riders work fixed shifts, others choose their own hours. Here is how we make pay clear, how tips stay with the rider, and why the promise on an order must match the pay. - Source: https://blog.laayo.com.np/how-riders-earn-at-laayo - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: July 14, 2026 - Topics: Riders, Earnings, Tips Every Laayo order ends with a rider at a gate, a bag in hand, sometimes in the rain, often in the lunch rush. Nothing we build matters if that person does not trust how they are paid. So this post is about money, rider money, and the rules we hold ourselves to. ## Two ways to ride with Laayo Some riders work fixed shifts with steady pay, and their income does not depend on how many trips they finish in a day. Others choose when they work: they book time slots in their area, go online when the slot starts, and are paid for the deliveries they complete. For riders who ride alongside studies or another job, that flexibility matters. Both groups are part of the same team. They use the same app, see the same orders and get the same support. What changes is how the pay is worked out. ## What makes up the pay on an order For a rider paid by the delivery, the pay for a single order is built from a few clear parts, and each one is shown on its own: - **The delivery itself.** Every completed delivery carries its own pay. - **Tips.** Whatever the customer chooses to tip goes to the rider in full. - **Extra pay when it is earned.** Busy hours, bad weather, booked time slots and long trips can each add something on top. ![What makes up a rider's pay on one delivery: the delivery, tips and any extra pay, all shown on the order card before accepting and credited the same way after delivery.](https://blog.laayo.com.np/media/seed/rider-earnings-breakdown.svg) ## The promise on the card When a new order arrives, the rider sees a card with the pickup, the drop and an earnings estimate. That estimate is a promise. If a rider accepts an order because it says one amount and is credited a different amount later, they will stop believing the card, and they will be right to. We found cases where the estimate and the final credit did not agree, because the same kind of pay was being worked out in more than one place, in slightly different ways. None of them were large on their own, but each one chipped away at trust. The fix was a rule, not a patch. Every part of a rider's pay is now worked out by **one shared calculation**, and that same calculation feeds: 1. the earnings estimate on the new order card, 2. the projection of cash the rider will hold after the order, 3. the amount actually credited when the order is delivered. If anyone on our team adds a new kind of pay in future, it has to go through that one calculation. It cannot be worked out separately in two places, because that is exactly how the numbers drift apart. We also made the credit safe to repeat. If an order is marked delivered, reverted and marked delivered again, extra pay is credited once, not twice. ## Seeing your earnings Riders asked for a clearer picture of where their money comes from, so the **My Earning** screen was rebuilt around simple day, week and month views. - Arrows let you move back through past days, weeks and months. - A bar chart shows how each day went. - You see your deliveries and the time you spent on orders. - Each kind of pay has its own row, and tapping a row shows how often it applied. The totals on this screen are checked against the same records the credits come from, so the chart, the rows and the total always add up to the same figure. ## Tips belong to the rider A tip is a thank you from a customer to one specific person. We think it should be treated that way. Riders can open a **Customer tips** screen that lists each tip they received: which store, which order and which day. No guessing about where a tip went. We are also rolling out a **protected tip balance**. With it, tips are kept in their own pot, separate from the rest of a rider's wallet. Nothing else can be deducted from that pot, tips can be withdrawn on their own, and any tips left in it are transferred out automatically on a regular schedule. It turns on once the new rider app is in everyone's hands, so that no tip ever lands somewhere a rider cannot see it. ## Fuel, without the paperwork Riders on fixed shifts often pay for fuel from the cash they collect on the road. Keeping track of that used to mean paper receipts and a long conversation later. We are rolling out **Request fuel** in the rider app. The rider takes a photo of the petrol receipt, the app reads the total for them, and they confirm the amount. That amount is recorded straight away against the cash they are holding, and it shows up in their statement as fuel. If the photo cannot be read, or the amount looks unusual for the distance ridden since the last fill, it is simply marked for a quick review by our team. The rider is never left waiting for an approval to keep riding. ## Payouts that need the right details Riders paid by the delivery withdraw their earnings to their own bank account. To keep that safe for everyone, payouts need a verified PAN and bank account first. Riders submit these once in the app, our team checks them, and from then on withdrawals go straight through. ## What we hold ourselves to If we had to sum up our approach to rider pay in a few lines, it would be these: - **The estimate is a promise.** What a rider sees before accepting is what they get. - **Tips are personal.** They go to the rider in full and stay visible. - **Every rupee has a reason.** Each part of the pay is shown on its own, with a count. - **Simple beats clever.** A rider should be able to check their own earnings with nothing more than the app. Riders are the part of Laayo that customers actually meet. If you ride with us and something about your pay does not look right, raise it from the app. We would much rather hear about it than have you quietly stop trusting the number on the card. --- # Ratings that mean something to you > A restaurant's average rating tells you what everyone thinks. We built a second number that predicts what you will think, and learned when to stay quiet instead. - Source: https://blog.laayo.com.np/ratings-that-mean-something - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: July 14, 2026 - Topics: Machine learning, Ratings, Personalisation Every food app shows a star rating next to each restaurant. It is useful, but it answers a slightly odd question: what did everyone else think, on average? If you never eat spicy food and a restaurant is loved for its fiery chilli chicken, its high score says very little about whether you will like it. So Laayo shows two numbers. The overall rating is what everyone thinks. The "for you" rating is our prediction of how you, specifically, would rate that place. This post explains how we compute the second one, the bug that made the first version useless, and why sometimes the right prediction is no prediction. ## The bug that showed the same number twice Our first personal rating was calculated inside the app. It looked at the first page of your order history and, when it did not have enough to go on, it simply copied the overall rating. In practice, almost everyone saw the same number twice, once as the overall rating and once as "for you". That is worse than showing nothing, because it tells people the feature does not work. We moved the whole calculation to the server, where it can see your full history and everybody else's, and we made one strict rule: if we do not have a real prediction, we do not show a personal number. The app shows a short "still learning your taste" state instead. ## Getting the overall number right first Even the overall rating needed care. A restaurant with a couple of perfect reviews is not better than one with a long history of very good ones. We use a shrunk average: each restaurant's rating is pulled towards the average for all restaurants, and the pull gets weaker as reviews accumulate. New places start near the middle and earn their way up or down. ![The signals that go into a personal rating, and how their weight grows with evidence](https://blog.laayo.com.np/media/seed/personal-rating-signals.svg) ## What we know about your taste The personal rating is a blend of signals, each with a weight: - **Your own reviews,** the strongest signal we have. A low star review of a restaurant counts for a lot. - **What you order,** including which dishes and cuisines, from your full delivered order history. - **How often you go back.** Reordering from the same place is a quiet but strong vote. - **Favourites and recommendations,** including recommendations from people you follow. - **People like you,** customers whose orders overlap with yours, and how they rated places you have not tried. - **Hard rules,** such as veg mode. A place that does not suit a vegetarian customer should never be rated highly for them, no matter what else says. - **Fit,** such as whether the restaurant's prices match what you usually spend. Each signal also adds to a confidence score. When confidence is low, the personal rating stays close to the overall one, or is not shown at all. ## Learning hidden tastes Hand written signals only go so far. People's tastes have patterns that are hard to name, so we added a small machine learning model. It is a matrix factorisation model, the same family of techniques behind many recommendation systems. Each customer and each restaurant is represented by a short list of numbers, sixteen of them, learned from past behaviour. The model learns those numbers so that combining a customer's list with a restaurant's list predicts how that customer would rate that restaurant. The training data is everything that hints at an opinion. A review is the clearest signal, weighted more heavily when it is recent. A delivered order is a mild positive. A cancelled order is a mild negative. Saving a restaurant as a favourite is a strong positive. The model retrains regularly and quickly, and we check it against ratings it has not seen before trusting it. When this model has seen enough of both you and a restaurant, its prediction gets a larger share of the blend. When it has seen little, it barely counts. ## Matching the vibe A brand new restaurant has no history, so collaborative signals cannot help. For those we use content. We describe each restaurant by its name, cuisines and most ordered dishes, and we describe each customer by the dishes and cuisines they order most. A text embedding model turns both descriptions into vectors, and we compare them. A close match nudges the personal rating up. Embeddings are refreshed weekly, and only for restaurants and customers whose description actually changed, so the cost stays tiny. ## Explaining the number A prediction you cannot question feels like a trick. So every personal rating comes with short reasons, shown when you tap it: "You often order from places like this", "Vibes match your usual go-tos", or "Our model predicts this may not be your style". The rating sheet also shows how far the personal number is above or below the overall one, so you can see at a glance whether a place is likely to suit you better or worse than average. ## The guest bug One more bug is worth sharing because it is so easy to make. The personal rating endpoint serves both guests and signed in customers, so it does not require a login. Because of how authentication was configured, the code that looked up the current customer always found nobody on that endpoint. Every signed in customer was being treated as a guest, and getting the cold start answer. The fix was one line: ask explicitly for the app's login token. The lesson was broader: when a feature quietly falls back to a safe default, test that it does not fall back all the time. ## What's next In the next app update, the rating chip on each restaurant becomes a small switch between "For you" and "Overall", so you can flip between the two without opening a sheet. Later, we would like the same taste model to help order restaurant lists, so the places most likely to suit you come first. --- # Momo from one place, sekuwa from another, one checkout > Families rarely agree on one restaurant. We are rolling out a cart that holds dishes from a few restaurants at once, with one rider, one bill and a delivery fee that follows the real route. - Source: https://blog.laayo.com.np/one-cart-many-restaurants - Section: Product - Author: Laayo Product (Laayo Services Pvt. Ltd.) - Published: July 12, 2026 - Topics: Cart, Checkout, Riders, Ordering Picture a Friday evening in Birtamod. One person wants momo from the place near the chowk. Someone else wants sekuwa from across town. The youngest wants a milkshake that only one café makes properly. Until now, Laayo made you choose. Add an item from a second restaurant and the app asked whether you wanted to clear your cart. Most people either gave up on someone's favourite or placed separate orders and paid separate delivery fees. It is an ordinary situation, and we wanted Laayo to handle it the way a family actually orders. So we built a cart that holds dishes from a few restaurants at once. It is rolling out with the new customer app. ## What you see When you add a dish from a second restaurant, the app simply adds it. The cart groups your dishes by restaurant, each with its own section, its own subtotal and its own "Add a note for the restaurant". You check out once and pay once. On the tracking screen you follow one rider who picks up from each place and then comes to you. There is a limit to how many restaurants one cart can hold, and they all need to deliver to the same area. If you go past that, the app explains why and offers to start fresh, instead of silently dropping anything. ![A multi-restaurant cart becomes one order per restaurant, tied together for you](https://blog.laayo.com.np/media/seed/multi-cart-bundle.svg) ## One bill, many orders underneath The obvious way to build this would have been a new kind of "big order" with several restaurants inside. We chose not to. Every other part of Laayo, from the partner app that rings in the kitchen to the rider's earnings and the restaurant's payout statement, is built around one order belonging to one restaurant. Changing that would have meant touching almost everything. Instead, your cart becomes **one order per restaurant**, and the server ties those orders together as a bundle. For the restaurant nothing changes: they get a normal order with only their dishes and only your note to them. For you, the app shows the bundle as one purchase with one combined bill. Placing a bundle is all or nothing. If one restaurant has run out of a dish or closed while you were deciding, none of the orders are placed, and the cart tells you what needs to change. We never want you to pay for half a dinner. ## A delivery fee that follows the road Charging a full delivery fee for every restaurant would make the feature pointless. Charging one flat fee would be unfair to riders who really do ride further. So the fee follows the route the rider will actually take. The first restaurant is charged like a normal delivery, from that restaurant to you. Each extra restaurant adds only the short hop between restaurants. You pay the total as one delivery fee. Behind the scenes each order keeps its own slice of that fee, so the rider's earnings and the cash they collect reconcile exactly as they do for normal orders. ## Bugs that taught us something Testing found two problems worth sharing. The first was a note that wandered. If you wrote a note for the first restaurant and none for the second, the second restaurant received your first note. The code was filling in a missing note from whatever value the previous loop had left behind. Each restaurant now gets exactly the note you wrote for it, or nothing. The second was a bill that stopped short. If one restaurant's dish had quietly gone out of stock, the combined bill skipped that restaurant's food and showed a much smaller total, and it did not update. Now any problem with any restaurant stops the quote and tells you which dish needs attention, so the number you see is always the full number. ## Complete your meal The other half of a good cart is helping you finish the order you meant to make. Under your cart there is now a "Complete your meal with" strip, with tabs for popular dishes, drinks and sides from the same restaurant. To fill those tabs, each dish needs a role: a main, a drink, a side, a dessert, a dip. Restaurants do not label their menus that way, so we use a language model to sort dishes into roles. It never sits in the way of your cart. When a dish has no label yet, a simple keyword guess fills in straight away, and the model's label arrives in the background for next time. While building this we also found that the strip had been empty for everyone for a while, because the app and the server disagreed about how to ask for suggestions. We fixed that on the server, so even older versions of the app started showing suggestions again without an update. In the new native app, adding a dish from the strip feels lighter: the dish you picked folds out of the row with a small spring, the row never suggests what is already in your cart, and an empty tab simply disappears. ## Paying for a bundle Cash on delivery and the Laayo Wallet work for bundles from the start. Paying a bundle with E-Payment is ready on the server and sits behind a switch, so we can turn it on once the new app is in enough hands. When it is on, one QR pays for every order in the bundle, and the cart stays in place until the payment is confirmed. ## What's next Riders will see a bundle as one trip with a pickup list, in the order that makes sense on the road. After that, we want the cart to suggest a second restaurant nearby when it would not add much to the route, which is a nice way to discover a new place without paying extra to try it. --- # Offers that add up, from the menu to the bill > Restaurants on Laayo can now run their own offers: a percentage off, free delivery, buy some get some free, or a free dish above a spend. Here is how we made every one of them land on the bill exactly as promised. - Source: https://blog.laayo.com.np/offers-that-add-up - Section: Engineering - Author: Laayo Engineering (Laayo Services Pvt. Ltd.) - Published: June 24, 2026 - Topics: Offers, Cart, Pricing, Partners An offer is a promise. When a restaurant card says "Buy one, get one" and the cart says "FREE" next to a plate of momo, the bill at the end has to agree. If it does not, the customer feels cheated, the restaurant takes the blame, and our support team spends the evening issuing apologies. For a long time Laayo's offers were simple and mostly run by us. A restaurant that wanted a promotion had to ask, and only one kind of discount really worked end to end. This year we rebuilt offers so restaurants can create them from the partner app, so several offers can exist side by side, and so every kind of offer is priced by the same rules on the phone and on the server. This post is about the parts that were harder than they looked. ## Four kinds of offer Restaurants can now create four kinds of offer from the **Offers and Discounts** screen in the partner app: - **Percent off**, for the whole menu or for chosen items and categories. - **Free delivery** above a spend the restaurant chooses. - **Buy some, get some free**, for example buy one plate, get one free. - **Spend and get a free dish**, where the customer picks a free item once the cart passes a set amount. Each offer has a time window, an audience (everyone, new customers, returning customers) and an optional mealtime, so a restaurant can run a breakfast offer without it leaking into dinner. Restaurants can pause an offer with one tap and pick it up again later. The rule for who pays is simple and fixed in the server: **an offer a restaurant creates is paid for by that restaurant**. Offers we run as a platform can split the cost, and that split is recorded on every order so payouts reconcile without anyone doing arithmetic by hand. ![Every offer goes through one resolver before it reaches the cart, the checkout and the bill](https://blog.laayo.com.np/media/seed/offers-resolver.svg) ## One resolver, not five opinions Once several offers can be live at the same restaurant, someone has to decide which one applies. The first version of that decision lived in five places: the restaurant card, the menu, the cart, the checkout and the order placement code. They mostly agreed. "Mostly" is how a card ends up advertising one discount while the bill applies another. So we made one function the single source of truth. Given a restaurant and, when we know it, a customer, it picks the best live offer: inside its time window, approved, not paused, and open to this customer's audience. Every screen and every price calculation now asks that function, and nothing is allowed to compute "the current discount" on its own. When we added audiences and mealtimes later, we changed one place, and the whole app followed. We also added an optional approval step. By default a restaurant's offer goes live as soon as it is saved, because restaurants want to react to a slow afternoon right away. If we ever need to review offers first, a setting turns on an approval queue without any app change. ## The free dish that was not free The trickiest bugs were in the "get something free" offers, because there the customer takes part in the pricing. They pick which item is free, and that choice changes the cart they are looking at. Here is the one that taught us the most. A restaurant ran a "buy one, get one free" offer on the same dish. A customer added a few plates, the app showed the picker, the customer chose their free plate, and the cart happily showed **FREE** next to it. The bill still charged full price. What happened was two versions of the same formula. Before the pick, the app counted every plate as "paid" and decided a free one was earned. After the pick, the free plate was no longer counted as paid, so the same formula, run again, decided there were not enough paid plates to earn it. The label stayed, but the discount quietly went to zero. The fix was to admit what "buy one, get one" really means when both plates are the same dish: you need enough plates in the cart to cover **both** the ones you pay for and the ones you get. Counting the whole group before and after the pick gives the same answer, so the free plate stays free. When the free item can be a different dish, the old way of counting is still correct, because the paid and free pools never overlap. The code now branches on that one question, on the phone and on the server alike. ## Two offers, one path The "spend and get a free dish" offer had its own version of the same problem. It looks different to customers, but underneath it works exactly like "buy some, get some": the customer picks an item, and the cart marks part of it as free. One part of the server only sent the buy-some offer through the code that understands picked items. The spend offer fell into the ordinary discount branch, which saw no percentage and returned nothing. Now both offers travel the same path everywhere: the picker, the discount calculation, the auto-apply logic in the cart, and the group order flow. We also stopped a generic "exclusive offer for you" suggestion from popping up over the picker, because two overlays asking for a decision at once confused people. ## Savings that read naturally A smaller lesson was about the "you saved" line. Internally, a freed plate carries two kinds of discount: any per-item discount on the dish, and the value of being free. If you add both to the savings banner, the customer sees a number that does not match what they can add up in their head. So the cart keeps two figures. One is for the bill math, so the total is always exactly what the server will charge. The other is for display, and counts per-item discounts only on the plates you are paying for, while the free plate's value shows up once, on the offer line. The customer's mental sum and the receipt now agree. ## Measuring offers honestly Restaurants want to know whether an offer worked. Orders do not record which offer "caused" them, so we attribute by time window: orders placed while an offer was live are counted towards it. That is exact when a restaurant runs one offer at a time, and approximate when offers overlap, and the partner app says so instead of pretending to precision it does not have. When we run the same offer across many restaurants at once, the admin panel now groups those rows into one campaign, so our team sees a single line with combined results instead of a long list of copies. That grouping is purely for reporting. The customer's price never reads it, which made it safe to add later. ## What's next We want restaurants to see a simple before and after for each offer, and to get a gentle nudge when an offer has run for a while without moving anything. We are also looking at letting a restaurant save an offer as a template, so the Friday deal is two taps away every Friday. --- # Gigs: how freelance riders choose their own hours > Freelance riders on Laayo book the hours they want to work, in the area they want to ride. Here is how gigs work, why online time is tied to a booking, and what we fixed along the way. - Source: https://blog.laayo.com.np/gigs-for-riders - Section: Company - Author: Laayo Team (Laayo Services Pvt. Ltd.) - Published: June 22, 2026 - Topics: Riders, Gigs, Freelance Some of the people who deliver for Laayo ride on a salary. Others ride when it suits them: a student between classes, a shopkeeper with a free evening, someone who wants extra income at the weekend. For that second group, the question we kept hearing was simple. "When should I go online, and will it be worth it?" Gigs are our answer. A gig is a slot of time, in a part of town, that a freelance rider books ahead. When the slot starts, the rider goes online. When it ends, they go offline. Everything else in this post is about making that simple promise hold up on real roads. ## Booking a gig In the rider app, freelancers get a Gigs tab. It shows the coming days as a calendar of slots: the lunch rush, the evening, late night, early morning. A rider taps the slots they want and books them, several at once if they like. Slots have a limited number of places, so the town is not flooded with riders at noon and empty at ten. Each rider also sets a **work area**: a point on the map and a radius around it. Someone who lives near the bus park does not want to be pulled to the far side of town at the start of a shift, and we would rather dispatch them close to home too. When a rider goes online, the app checks that they are inside that area. Salaried riders never see any of this. Their shifts are set with them directly, and the Gigs tab simply does not appear. ![A freelance rider's gig: book a slot, take the daily selfie, ride inside the work area, and go offline when the gig ends. Reliability over recent weeks sets the rider's medal.](https://blog.laayo.com.np/media/seed/gig-day.svg) ## Online means on a gig Early on we found a gap. The app sent freelancers through the gig flow when they tapped "Go online", but the server behind the plain online switch did not check for a booking. A rider who found another way to flip the switch could stay online all day with no gig at all, and an idle rider could stay online after their gig had ended. We closed it from both sides: - **The switch now asks the gig system first.** If a freelancer is inside a gig they booked, going online simply starts or resumes that gig. If they have no gig right now, the app tells them to book one. - **Gigs end on time.** A background check runs all day. When a gig's end time passes and the rider is not carrying an order, they go offline straight away. If they are holding an order, the gig stretches until it is delivered, so nobody is cut off halfway to a customer's gate. - **A sweep catches the rest.** Anyone left online with no gig and no order, from an old session or a phone that lost track, is taken offline. The rule is boring on purpose. A rider's online time is always attached to a booking, so the schedule we plan from and the map we dispatch from tell the same story. ## The daily selfie Before the first gig of the day, freelancers take a quick selfie in the app. The camera waits until it sees a face inside the frame, then captures it on its own. It takes a moment, and it means the person on the road is the person whose documents we checked when they joined. Our team can review the selfies later without stopping a rider mid-shift. ## Medals, quests and breaks Booking hours is only half of it. We also wanted reliable riders to get something for being reliable. - **Medals.** Each freelancer has a medal that reflects their recent weeks: deliveries, how often they accept, how often they are on time, customer ratings and time online, with cancellations and no-shows counting against them. Better medals open bookings for the best slots earlier. If a medal is about to slip, the app warns the rider in advance instead of surprising them. - **Quests.** Some days come with small goals, such as a number of deliveries in a slot. Finishing a quest earns a reward the rider can claim in the app. - **Breaks.** A rider can pause a gig for a short break instead of going offline and losing their place. - **Busy-time boosts.** When a zone gets busy, the app shows that pay is boosted for that window, so riders can see why it is worth staying on. ## Taking gigs seriously, both ways A booking is a promise from both sides. We promise the slot will be there and the pay will match what the app shows. The rider promises to turn up. So a rider who books a gig and never goes online counts as a no-show, and one who goes online and leaves almost straight away counts as an early leave. Both weigh on the medal, the same way cancellations do. Riders get a small number of waivers for real emergencies, so one bad morning does not undo weeks of good work. On our side, we found and fixed cases where the system was unfair to riders. A rider who went offline and back online could have their login time counted twice, which looked generous and was simply wrong. A rider who cancelled a slot and then wanted it back could not rebook it. A rider sitting inside a booked gig after a break could tap "Go online" and be told to book a gig they already had. Each of those is fixed. Each was found because riders told us something felt off. ## Incentives that add up the same way everywhere The hardest bug was in incentives. The new-order card showed one number, the progress bar showed another, and the money credited at the end of the day was a third. Different parts of the system were counting the day's trips differently. Now one count is used everywhere: the preview on the order card, the progress during the day and the credit after delivery. Milestone bonuses are also spread across the deliveries that lead up to them, so a rider earns a share on every order instead of hoping to land on one exact trip. The earnings screen is gaining a line for the bonus a rider has qualified for but not yet unlocked, so they can see exactly what is waiting. ## What's next We want booking to feel as easy as ordering lunch. Next we are looking at suggesting slots based on when each rider usually works, and showing more clearly where in town riders are needed tomorrow. As always, if something in the Gigs tab does not match what you earned, tell us in the app. That is how most of these fixes started.