Msumba Farms

The challenge

A farm business has a catalogue that changes constantly. Prices move with the season, stock runs out mid-morning, and new produce appears without warning. Most off-the-shelf platforms answer this with a sprawling admin panel built for a warehouse, not a farm.

Three constraints shaped the whole project:

• Payments had to work in Malawi

  International gateways are impractical here. Customers pay by mobile money far more often than by card, and the checkout had to reflect that reality rather than fight it.

• Customers should not have to create accounts

  Asking someone to register before buying a bunch of vegetables loses the sale. The site collects only what is needed to fulfil the order.

• The team had to be able to run it unaided

  Not "trained on it" — genuinely able to open it on a phone and change a price in ten seconds.

What we built

Two applications, one product: a shop customers use without thinking about it, and a portal the farm runs it from.

The storefront

A fast, mobile-first shop with a glassmorphic design language built around the farm's own green palette.

• Live catalogue driven entirely from the portal — categories, prices, units, photos and availability
• Search and category filtering that responds as the customer types
• Slide-out basket with live quantity and total updates
• Guest checkout — name, phone, email, delivery address and notes; no account, no password
• Enquire on WhatsApp on every product, opening a chat with the product already named
• Floating WhatsApp button on every page for questions before the sale
• Contact form that routes straight into the portal's message inbox
• Editable hero, about copy, contact details and business hours — no code needed

Online payments, done properly

Card and mobile money payments run through PayChangu, a licensed Malawian gateway. Card numbers and mobile money PINs never touch the Msumba Farms servers.

The part that matters is what happens after the customer pays. Rather than trusting the browser redirect — which can be tampered with — the site takes PayChangu's server-to-server notification, verifies its HMAC signature, then re-checks the payment directly with PayChangu before believing it. Only then is the order marked paid.

Mobile money also settles unpredictably: sometimes instantly, sometimes minutes later. The confirmation page handles every outcome honestly — paid, still processing, failed, or unverifiable — each with a clear next step, so a customer is never left staring at an error wondering whether their money is gone.

The management portal

A custom CMS at /portal, designed around how a farm actually works rather than how a generic admin panel is usually laid out.

• Dashboard — pending orders, unread messages, out-of-stock count and a month-by-month revenue chart, with a table view for anyone who would rather read the numbers
• Products — full catalogue management with image upload, plus inline price editing: click the price, type, press Enter
• Three availability switches per product — visible on website, in stock and featured on homepage — so produce can be pulled or restored in one tap without deleting anything
• Orders — every order with customer details, items, totals, payment status and the PayChangu reference
• Contact messages with a new / read / replied / archived workflow
• Site settings — headline copy, delivery fee, phone numbers, WhatsApp number and opening hours, each section saving independently
• Skeleton loading throughout, so a slow connection shows structure rather than a blank screen

Access control that suits a small team

The portal is invitation-only. There is no public sign-up and no self-service registration — the only way in is an emailed invitation from an admin.

• Two roles: Editor (catalogue, orders, messages, settings) and Admin (all of that, plus managing who has access)
• Status badges showing at a glance who has accepted their invitation and who has not
• One-click resend for invitations that expired or were consumed by an email scanner
• Self-service recovery for anyone holding a dead link, written so it never reveals which addresses have access
• Role restrictions enforced on the server, not merely hidden in the interface

A safeguard worth mentioning

An order cannot be marked delivered or collected while its online payment is still unpaid, pending or failed. The options are disabled and the reason is shown on screen.

It is a small rule with a real consequence: goods are never signed out against money that never arrived. Orders paid on delivery are exempt — the money is taken at the door.

How it is built

Storefront

React 19 · TypeScript · Vite 6 · Tailwind CSS v4

Management portal

Next.js 15 (App Router, server components) · TypeScript

Database & auth

Supabase — PostgreSQL, Row Level Security, Auth, Storage

Payments

PayChangu hosted checkout with verified webhooks

Email

Transactional order mail over SMTP; branded auth templates

Hosting

Docker on Google Cloud Run, fronted by nginx

Delivery

Google Cloud Build — every push to main deploys automatically

Both applications ship in a single container: nginx serves the static storefront and proxies /portal through to the Next.js server. One deployment, one certificate, one bill — and no cross-origin complexity between the shop and its own CMS.

Security is enforced at the database, not just the application. Row Level Security policies mean the public catalogue is readable by anyone while orders and customer details are not, regardless of which key is used. Order placement and payment confirmation run through security definer database functions, so totals are calculated server-side and cannot be altered from the browser.