Behind the MangoesToMetro store is a custom ordering system built specifically for it. This case study explains what it does and how it was put together, written for anyone considering something similar for their own business. The short version: an order should arrive complete, land in one place, and keep the customer informed without anyone having to remember to do it.
What happens after you press Place Order
From the buyer’s side, pressing the button is the end of the job. Underneath, a sequence runs every time, in the same order, whether it is the first order of the season or the fiftieth.
The submission is first checked to make sure it came from a person rather than an automated script. Then the details are validated: a real delivery area, a sensible number of boxes, a usable email and phone number. The uploaded proof of payment is inspected before it is accepted, and if anything fails the buyer is told exactly what to fix rather than being met with a generic error.
Once the order is accepted it is saved with a tracking code, and a confirmation email goes out automatically. Nobody has to be awake for this to happen.
Every order in one place
The team sees one list. Every order has the same fields in the same columns: tracking code, buyer, contact number, quantity, total, payment method, status and date. There is a search box and a date filter for finding a specific order, and an export button for pulling the day’s orders into a spreadsheet.
This is the part that replaced the manual coordination. There is no scrolling back through a conversation to find an address, and no two people keeping separate notes.
Stages a customer recognises
An order moves through stages named after real things rather than internal jargon: pending, confirmed, preparing, shipment, out for delivery, and order received. Two more exist for when reality intervenes: delayed and cancelled.
The stages are not just labels. The system knows which moves are allowed, so an order cannot jump from pending straight to delivered, and it cannot quietly go backwards. That sounds like a small thing until you have several people updating orders during a busy week. It means the status a customer sees is one the team can actually stand behind.
The counts along the top of the dashboard show how many orders sit at each stage, so it is obvious at a glance where the work is today.
Keeping payment details safe
Buyers upload a screenshot of their payment, which means the store accepts files from the public internet. That is the single riskiest thing a small shop can do, so it was handled carefully.
Uploads are restricted to images and PDFs, checked in more than one way rather than trusting the file’s name, and stored under a generated filename rather than whatever the sender called it. The submission is also checked for automated abuse before any of that work happens, so spam is rejected early instead of filling the order list.
Who can see what is controlled deliberately. Rather than handing everyone a full administrator account, there are separate roles: the people who run orders day to day, a read-only view for partners who need visibility without the ability to change anything, and the ability to export orders granted only where it is needed. Sign in happens through a dedicated branded page, and the standard WordPress login address is closed off.
What the team sees
Confirmation emails are sent through a properly configured mail service rather than whatever the web server happens to do by default, because order confirmations landing in spam is worse than not sending them at all.
A summary of the day’s orders is sent automatically to DTI at a set time each day, so the partner organisation stays informed without anyone compiling a report by hand.
The payment QR codes shown to customers are managed from the dashboard. When the account details change, someone updates them in a form. No developer, no deployment, no waiting.
Things a client can change without a developer
This is the part that decides whether a system stays useful after handover. The price per box, the maximum number of boxes per order, the sender name and address on emails, the time the daily report goes out, and the spam protection keys are all settings in a form.
When the season ends, the ordering panel can be replaced with an out of stock notice rather than collecting orders that cannot be filled. When it returns, ordering comes back.
How it was built, and why that matters to a client
Every change to this system shipped with an automated test written before the code, and the tests had to pass before anything was merged. On top of that, every change went through two independent reviews before it was accepted.
For a client, this is not a technical detail. It is the difference between a system where a fix to one thing quietly breaks another, and one where the safeguards catch it first. It is also what makes the system safe to hand to someone else later, because the behaviour is written down in tests rather than living in the original developer’s memory.
What a client gets
A custom WordPress plugin that takes orders, keeps them in one dashboard, moves them through stages the customer understands, handles payment proof safely, sends confirmations, reports to a partner organisation daily, exports to a spreadsheet, and can be adjusted from a settings page rather than by editing code.
It was built for a specific problem: a seasonal product, a single box size, two delivery areas, and payment by QR code with a screenshot as proof. That focus is why it is simpler to use than a general purpose shop system carrying features this store will never need.
Want the technical version?
The engineering detail behind all of this, including the order state machine, the upload hardening and the export handling, is in Engineering a secure WordPress ordering plugin.