A delivery app for a small city: lessons from Fast Order

The big delivery apps do not reach small cities. These places have restaurants, bakeries, pharmacies and grocery shops, but orders are placed by phone, and many of those calls get lost before the order arrives. Fast Order grew out of that gap. It is a delivery app that runs in Al-Suwaira, a district of Wasit governorate, whose capital is Kut.

When I joined the project there was no app to build from scratch. A live system was already running, with customers, couriers and restaurants. My job was to develop it without stopping it, and to rebuild the two apps that people actually see.

Delivery appFast OrderA delivery app at the level of the big apps, running in Al-Suwaira, a district of Wasit governorate.

What a small city changes

In a big city a customer chooses between several apps. A small city usually has one, and it has to carry the whole place: restaurants, groceries, a pharmacy, bakeries, a bookshop and mail. It also needs a dashboard run by the operations team, so they can publish offers and announcements themselves without waiting for a developer.

The bigger difference is how fast news travels. In a small city, one mistake in the price of an order is being talked about before you have fixed it. A small city will forgive a simple app. It will not forgive a wrong price or a lost order.

What I would ask if I were investing in delivery for my own city

The app is only the part you can see. Before you put money in, ask who manages the offers every day. Who sets the courier’s fee, and how does it change? What happens if the server goes down at lunchtime? These are questions about operations, and the answers decide whether the business is still alive after its first week.

A live system that several generations of apps talk to

The first lesson for anyone running a live system: an app that people have installed on their phones does not die because you have decided it should. Old versions keep talking to the same server for weeks after you release a new one.

• 4systems

  the customer app, the courier app, the restaurant dashboard and the admin dashboard

• One app

  serves the whole city: restaurants, groceries, a pharmacy and bakeries

• One price

  calculated by the server and shown unchanged on every screen

So every change on the server has to add something. It cannot alter or remove what is already there, or an app on some customer’s phone breaks, and that customer will not update for weeks. A business owner should budget for staying compatible with old versions from the very start.

Only the server calculates the price

The most dangerous thing in a delivery app is for the app to work out one price and the server another. When the two numbers differ, either the customer is angry or the company loses money.

The fix is for the server to provide a price preview. The cart and the checkout page show what the server says and nothing else, so what the customer sees is what they will pay.

Delivery cost is not a single number

Every restaurant has its own policy, so the delivery fee is calculated per restaurant.

One rule I will always defend: a restaurant’s promotion is never paid for out of the courier’s pocket.

When an order spans more than one restaurant, it becomes a single trip with one courier, and its fee follows a simple rule that the customer, the courier and the owner can all understand. If you cannot explain the rule to them in one sentence, it is more complicated than it needs to be.

Also readBefore you commission a system: questions that come before any quoteBusiness & investment5 min read

The courier at the centre of the order

The courier is the last link between the order and the customer, so the system has to protect them just as it protects the customer.

One order, one courier

An order must never go to two couriers. That means ‘accepting an order’ has to be a single operation that cannot be split: the first courier to tap gets it, and the second knows at once that it has gone. For trips with several orders, I made the locks follow a fixed sequence so that two orders can never block each other.

It has become my first question on any system I inherit: who is able to do something they should not be allowed to do?

Cash in the courier’s pocket

Payment on delivery here is often in cash. The courier collects the money from the customer and hands it over to the company later. The more cash they are carrying, the greater the risk to them and to the company. So I put a limit in the courier app on how much cash a courier can hold.

It is a small rule that the customer never sees, and it protects the courier before it protects the owner’s accounts. A small city cannot afford to have even one courier lose trust in the company.

How to work on a live system that cannot stop

This is the method I follow. I am setting it out because it is useful to any owner whose system is already up and running.

1. Start with a written review

   Before I touch a single line, I write a review in Arabic, and every note in it is tied to evidence.

2. Work on an isolated copy

   A copy of the live system that customers cannot reach. Notifications, messages and payments are switched off in it, so no real customer receives a test notification.

3. No fix without two pieces of evidence

   I do not fix a problem until I have confirmed it with two kinds of evidence, such as the logs first, then a test on the isolated copy.

4. Change by adding only

   Every server change adds something and removes nothing, so the old app keeps working.

5. Write for the owner

   I write down for the owner what changed, in language that does not take a developer to understand.

A live delivery system never closes for maintenance. You repair it while it is running.

Why I rebuilt the two apps

I rebuilt the customer and courier apps rather than patch them. The customer app now has order tracking on the map, ratings and refund requests, and chat with the courier and with support. The courier app has order offers and proof of delivery by photo. A courier works with the phone in a pocket, so I gave the new-order notification its own channel and sound to make sure it is heard. The customer app also has a maintenance screen, and a gate that forces old versions to update when needed.

I would not recommend the same choice in every case. But when the foundations are the problem, patching puts the bill off without cancelling it.

The short version

In a small city every order matters and every mistake gets around. Build first whatever makes each order arrive at the right price with a single courier, and polish afterwards. If you are inheriting a live system, write your review before you change anything, and make your changes by adding, not by editing.