Branded ordering app with live driver tracking.

Partly, and it is worth being precise about which part, because the honest answer is more useful to you than the exciting one. An order placed through your own branded app does not pass through a third-party marketplace, so it does not carry that marketplace's per-order commission — the double-digit cut that makes delivery through those channels so painful. That is a real saving and it is the reason this product exists. What it is not is free money, and anyone who tells you you now “keep 100%” is skipping the costs that simply move onto your side of the ledger. You still pay to take the payment: card and processing fees apply to a direct order exactly as they do to any other card transaction, and those are separate from anything Vertex charges. More importantly, the marketplace was never only charging you for the software — it was charging for demand. It put your restaurant in front of hungry people who had opened its app with no particular restaurant in mind, and it supplied, in many arrangements, the drivers and the customer support. Go direct and those jobs become yours: you have to make people download and reopen your app rather than the marketplace's, you have to get the food to the door, and you have to answer the phone when an order is late or wrong. Some operators run both channels deliberately — the marketplace for discovery, the direct app for repeat customers who already know them — and treat the commission on the marketplace orders as an acquisition cost. Whether the maths works for you depends on your order volume, your margins and how much of your own demand you can drive, so model it on your own numbers rather than on the saving alone. The commission you avoid is real; the effort and cost that replace it are real too.

Take the second half first, because it is the one that surprises people. Vertex is software. It does not deliver food. The tracking, the dashboard and the branded app coordinate a delivery operation that you provide: the drivers are yours, whether they are your own staff or a courier partner you work with, and so are the vehicles, the insurance and the physical business of getting a bag from your kitchen to someone's door. Nothing on this page changes that, and a page that implies the software turns up with drivers would be misleading you. Now the tracking itself. Live location on a map depends on a device out in the world reporting where it is — in practice, the driver's phone running the driver side of the app and sending its position as they go. That means the quality of what the customer sees is only ever as good as that phone: its GPS fix, the mobile signal along the route, whether the app is allowed to report location in the background, and whether the battery lasted the shift. On a clear run through town it looks great. Through a patch with no signal, in a dense building, or when a phone has been left to sleep, the dot lags, jumps or goes quiet — and no software removes that, because the limitation is physics and the mobile network, not the app. So treat tracking as a good, near-real-time indication rather than a guaranteed to-the-second feed, and be careful about promising customers an exact arrival time the driver cannot control once traffic and stairwells are involved. The specifics you will actually want to pin down — how orders are dispatched and assigned to drivers, whether Vertex integrates with a particular courier partner or dispatch system, what the driver app needs to run on, and what any of that costs — are questions for our sales and implementation team, and worth getting in writing before you plan a launch around them.

That is genuinely one of the strongest arguments for going direct, so it is worth stating what is true and then being careful about what follows. When a customer orders through a third-party marketplace, the marketplace largely stands between you and them: it holds the account, it owns the relationship, and in many arrangements you never learn who ordered what. A branded app of your own flips that. The customer is ordering from you, the account and the order history sit in your system, and you can build a direct relationship — recognise a regular, run your own offers, contact them yourself — rather than renting access to your own customers from a platform that can change the terms whenever it likes. That is a real and durable advantage, and it is the honest headline here. The part that needs care is the word “data”, because owning the customer relationship also means owning the responsibility that comes with it. The moment those orders, addresses, contact details and payment records live in your system, you are the one handling personal data, and in most places that carries obligations: telling people what you collect and why, having a lawful basis for it, keeping only what you need for as long as you need it, securing it, and being able to answer a request from the customer it concerns. Vertex gives you the tooling to store and work with that information; it does not, by existing, make your business compliant with privacy or consumer law, and we would ask you not to read this page as saying it does. Exactly which rules apply, what your privacy notice has to say and how long you may keep things depend on where you and your customers are, and they change — so take your specific plan to your own adviser or counsel. The relationship being yours is the whole point of the product. The duty of care that comes attached is yours as well.

Faster than building one from nothing, but not the “live in minutes” that this kind of page likes to imply, and it helps to know why before you set a date. A branded app is a real app. Getting it into customers' hands means it has to reach the app stores, and that is a process with steps that sit outside anyone's control. You need developer accounts with the store operators, which take their own setup and carry their own annual costs. Each store reviews an app before it goes live and can send it back with changes to make, on its timetable rather than yours. You need the branding to make the app actually yours — a name, an icon, colours, imagery, store screenshots and the written descriptions — and someone has to produce those. And a published app is not a finished job: the stores move their requirements, phones and operating systems update, and an app that is left alone eventually stops working, so there is an ongoing maintenance commitment behind the launch. None of that is a reason not to do it; it is a reason to plan it honestly rather than expecting to flip a switch. What genuinely differs between operators is how much of this Vertex handles for you versus what you supply or arrange yourself — whether it is your developer accounts or ones managed on your behalf, how much of the branding you hand over versus produce, and how updates are shipped afterwards. Because those decide both the timeline and the cost, they are exactly the questions to put to our sales and implementation team, in writing, before you commit to a launch window: what is included, what you are responsible for, how long a realistic first release takes, and what keeping it live costs over time.

This is the least glamorous question on the page and the one most worth asking before you sign anything, because the whole experience — orders arriving, the kitchen seeing them, the driver reporting a position, the customer watching a map — rides on a chain of connections, and any link can break. Take the failures in turn. If the connection at the restaurant drops, the flow of new orders into the kitchen depends on that link being back; ask specifically what the kitchen and the front of house see in the meantime, whether anything keeps working offline, and what reconciles when the connection returns, because “it just works” is not an answer you can plan around. If a driver's phone loses signal, dies or is left to sleep, the live position stops updating — the delivery still happens, but the customer's map goes quiet or stale until the phone reports again, which is one more reason not to promise a to-the-second ETA. And underneath all of it are the plain physical dependencies people forget until the first busy Friday: working internet at the restaurant, a mobile signal along the routes your drivers actually take, phones that are charged and allowed to report location, and a payment path that keeps working. Software cannot fix a dead connection or a flat battery. So do two things. Ask our sales and implementation team, in writing, exactly how the system behaves when connectivity drops on each side — what queues, what fails, what reconciles, and what the customer is shown while it is down. And keep a simple manual fallback your team has actually rehearsed, so that the night the network wobbles is not the night they are improvising, because that is precisely the night you can least afford it.