01 / Context
Fixing a mistake after a sale is part of the job.
A duplicate cash sale was recorded against the wrong credit account. I used the return workflow to reverse it while correcting stock and the cash drawer. That recovery path is as important as the original checkout. I have left out transaction identifiers and customer details.
I built a retail system with a public storefront and a staff back office in one application. The customer journey matters, but so does what happens when staff need to correct a sale or reconcile the day.
The main challenge: one sale changes money, stock, and customer records. All three must always agree.
02 / Constraints
What the system had to handle.
- The shop needs customer-facing commerce and staff operations on the same domain.
- Payments must support the paths customers already use, including Mobile Money.
- Operational mistakes need a recovery path; editing a screen is not enough if the underlying records disagree.
03 / Decisions & trade-offs
Key decisions and their trade-offs.
One application for the front and back office
I used Next.js and Supabase for the storefront and staff workflows, with payment processing on the server.
- Alternative
- Separate storefront and back-office products joined by periodic data transfers.
- Trade-off
- A shared application reduces integration boundaries, but makes authorization between public and staff areas especially important.
Treat money rules as release gates
I included dedicated money, payment-signature, and role tests, alongside checks for the database and application boundaries.
- Alternative
- Rely on manual checkout testing before each release.
- Trade-off
- Automated checks take maintenance. They provide repeatable evidence for critical rules, but still need real payment-path testing.
Make operations part of the delivery
I added a health heartbeat and runbooks for outages, backup restoration, key rotation, and handover.
- Alternative
- Deliver the application with deployment instructions alone.
- Trade-off
- Runbooks and monitors need ongoing upkeep. In return, recovery has a starting point instead of depending on memory.
04 / Outcome
A launched system, with an operational backbone.
I shipped the production storefront and business-management application with live payments. The system includes tested financial workflows, health monitoring, and documented recovery procedures. The live link opens the production site, rather than the earlier pitch demo.
What I’d improve next
I would keep extending correction-path tests around the mistakes staff actually encounter. I do not have a measured before-and-after revenue or time-saving study to attribute to this build.
Project snapshot: 2 November 2026. Outcomes describe what was built and launched, not a measured rise in revenue.
