Food — made-to-order home bakery with delivery · Deployed and running
Noheira
A home bakery's public ordering site and the owner's back-office, built as one Arabic, phone-first application — what the customer orders on the site becomes the kitchen plan, the cost and the payment record behind it.
- System type
- Public ordering site and owner back-office in one application
- Our role
- Full build — mapping the bakery's workflow, then building the ordering site, the back-office and the releases
Noheira is a home bakery in Helwan Gardens, Cairo, that bakes to order for fixed delivery days. This is its public ordering site and the owner's back-office, built as one application: the site takes the order, and the back-office confirms it, turns it into a kitchen plan in grams, costs it to the gram, records what was paid and shows how much of the money put into the business has come back before anything counts as profit. Thirty pages — seven public, twenty-two for the owner and one sign-in — in Arabic, right to left, designed for a phone first. The rules sit on the server: the site can suggest, and only the server decides what an order costs and whether a day is open.
- 106
- orders on record since 22 September 2026, the earliest carried over from the owner's sheet
- 51
- customers
- 8 / 29
- products / flavours
- 18
- gram-level recipes
- 30
- pages — 7 public, 22 for the owner, 1 sign-in
- Sector
- Food — made-to-order home bakery with delivery
- Based in
- Helwan Gardens, Cairo
- System type
- Public ordering site and owner back-office, one application
- Catalogue
- 8 products and 29 flavours: mini pizza, cookie bites, cinnamon rolls, qarakish
- Coverage
- Orders, kitchen planning, recipes and costing, stock, purchases, expenses, customers and debts, reports, analytics
- Users
- The owner (admin) and customers (public site)
- Language
- Phone first. By the owner's account, more than 90% of admin use and about 100% of site use is on a phone (her statement, not an analytics figure)
- Devices
- Phone first — the owner reports the admin is used over 90% on a phone and the site about 100% (her statement, not an analytics figure)
- Timeline
- Orders on record from 22 September 2026 · first commit 28 September · measured 7 October 2026 · 69 commits
The problem before the system
This is how the bakery itself describes its situation before the system; it is the business's account and was not measured. The owner works alone, mostly from a phone, and five things lived in places that could not be added up.
Read the detailHide the detail5 points
- Orders
- — Requests arrived through WhatsApp, Facebook and phone calls and were written into a sheet by hand. Three channels fed one sheet, and every request had to be typed in before it could be planned.
- Costs and profit
- — Costs were estimated, not computed. There was no margin per order or per flavour, so a price was set without knowing what the box cost to make.
- Stock
- — There was no view of what the stock on the shelf was worth.
- Debts
- — Who had paid, who had paid part and who still owed lived in memory and in chat history.
- Baking
- — Nothing said what to bake for which delivery day, or in what weights.
Understand how the bakery runs, then build one system for the site and the back-office
Read the detailHide the detail
Before writing code we worked out how the business actually runs. Products are baked for fixed delivery days, orders close at an hour the day before, each day has a capacity, and every box size has its own packaging. The owner works alone, mostly from a phone, in Arabic.
Three decisions came first. One place for every fact: a price, a recipe or a payment is entered once and everything else reads it. The rules live on the server: the public site can suggest, and the server decides what an order costs and whether a day is available. And a screen has to work at 375px, with large tap targets and bottom sheets, before it counts as finished.
That is what makes the site and the back-office one product rather than a site with an admin bolted on. The customer's menu, prices, delivery days and ready-now items are read from the same catalogue the owner costs and prices in the back-office; a review appears on the site only after she approves it; and a price changed in the cost calculator can be applied to the site from the same screen.
Every order then passes through one enforced flow, from the customer's cart to a payment recorded in the owner's accounts, and the rest of the system is built around it.
The operating core: one order flow, from the site to the back-office
An order starts on the customer's phone and ends in the owner's accounts. Every step is enforced by the system rather than left to memory.
Read the detailHide the detail11 points
- 01
Site order
The customer builds a cart and picks a delivery day; the server throws away any price the browser sends and recomputes it from the catalogue.
- 02
Owner confirms
The order arrives as new; she sets add-on prices, bags and the delivery day, then confirms. Orders she enters herself start confirmed.
- 03
Kitchen plan
Confirmed orders become a plan in grams for each delivery day: dough, toppings and boxes.
- 04
Bake logged
Each bake is logged with its dough and yield, which feeds the bake analysis.
- 05
Ready, then delivered
Status moves through six stages, and a site customer can follow the order by phone number.
- 06
Payment
Cash, Vodafone Cash or InstaPay, with part payments; overpayments and debts show per customer.
The server owns the rules
Delivery weekdays, the order deadline hour, daily capacity and closed days are enforced on the server. A closed or past day, a product not offered that weekday, an unknown add-on or an out-of-range weight is rejected.
Cost is frozen at sale
When an order line is created, its cost is kept as it was. Later price changes do not rewrite history; the owner re-costs an order on today's prices only when she chooses to.
Numbers that refuse to guess
An unknown cost, price or stock shows as unspecified or incomplete, estimated values carry a needs-confirmation label, and stock value reads incomplete instead of a partial total.
Income repays capital first
Income is applied first to the money put into the project, in the order the owner chose; only what remains counts as profit.
Every change can be undone
Every operation is written to an audit log with its arguments and can be reversed from it; orders keep their number, status and payment trail through edits.
The practical result: an order's price, its day and its payments are decided in one place, so what the customer was shown and what the owner books cannot drift apart.
The departments
9Read the detailHide the detail9 points
- Public site
- Menu and product pages, cart, guest checkout, order tracking by phone, catering requests and reviews the owner approves.
- Orders
- Create or edit any order, confirm or reject, advance the status, cancel, reschedule in bulk and record payments.
- Kitchen
- A per-day plan in grams and boxes, a delivery sheet, and every bake logged with its dough and yield.
- Recipes and costing
- Gram-level recipes, ingredient prices with history, packaging, energy and waste, and trial batches awaiting approval.
- Stock
- Ingredients and packaging, purchases, ready-made stock and the value of it all.
- Money
- Expenses, customer debts, reports, project profit and capital recovery, exports and backups.
- Customers
- A profile with order history and debts, and which customer referred which.
- Visitors
- The bakery's own analytics: a five-step funnel from visit to order, and abandoned carts.
- Settings and security
- Delivery zones and fees, closed days, capacity, notifications, login history and sign-out of every device.
Arabic first, phone first
The interface is Arabic and right to left from the first line, not a translated layout, and it is designed for the device the owner actually holds. The same application opens wide on a desktop.
Read the detailHide the detail6 points
- Spacing, icons, number formats, date labels and mixed Arabic and Latin text are all handled for RTL, rather than mirrored afterwards.
- The admin has numbered form steps, bottom sheets for confirming and paying, and a bottom navigation bar with an all-sections sheet, so the common jobs are one thumb away.
- Each change is checked at 375px first, with large tap targets, before it is considered done.
- The owner reports that more than 90% of admin use is on a phone, and about 100% of use of the public site. This is her statement, not an analytics figure.
- The admin installs to the home screen, and a notification reaches the owner's phone on every new order and on every admin login.
- Changes made without a connection are built to wait on the phone and apply once the connection returns. That is built and covered by the checks, but not yet tested on a real phone.
Owner home for today
The screens
7 screensThe bakery's name, logo and product catalogue in these screenshots are real. The customers, phone numbers, amounts and visitor figures in them are invented demonstration data, and no real customer or financial record appears; the counts quoted on this page are real counts only, with no money figures.
On a desktop
Offline and security
What changed
| Before (as the business describes it) | With the system |
|---|---|
| Orders from WhatsApp, Facebook and calls, tracked by hand in a sheet | One order form; every order has a number, a status and a payment trail |
| Costs and profit estimated | Cost computed per order line and frozen at sale; profit and capital recovery shown |
| No view of stock value | Stock value computed, and shown as incomplete when something is unknown |
| Debts remembered | Debts per customer and per order |
| No baking plan | A kitchen plan in grams for each delivery day |
| Visitors unknown | Visitors, sources, a funnel and abandoned carts |
This table compares the bakery's own account of how it worked before with what the system does now. It describes a change in practice, not a measured saving, and the before column was not independently measured. What was measured, on the live system on 7 October 2026: 106 orders on record since 22 September, of which 99 are non-cancelled paid orders and 3 are cancelled, and 51 customers. Average order size in the third week was roughly three times that of the first — a ratio only, and not attributed to the system. No time saved, error rate or conversion figure was measured, so none is claimed.