Agriculture · Commerce & Operations
A farm shop and the farm behind it, running as one system — customers ordering produce on one side, plantings, harvests and losses recorded on the other, and reporting that finally connects the two.
Visit serenity.godjitech.comThe brief
A working farm has two lives. One faces customers — orders, deliveries, payments, events. The other faces the land — what was planted where, what was expected, what was actually harvested, what was lost, and what it cost in inputs to get there.
Most farms run those two lives in different places entirely: a storefront on one side, a spreadsheet or a notebook on the other. Nothing connects a bad month in the shop to a poor harvest, or a loss in the field to a gap on the shelf.
Serenity Farms was built so both halves live in one system, and the reporting can see across them.
Who it serves
Buy the produce.
A storefront with categories, product pages, cart and checkout, plus accounts, saved addresses and order history. Events can be browsed and booked. WhatsApp is a first-class way in for anyone who would rather message than fill in a form.
Run the business.
Products, categories, stock movements, orders, delivery regions and fees, refunds, feedback, customers, users, event types and cancellation policies — plus expense tracking and finance summaries.
Record what the land actually did.
Crop types, field blocks, orchard blocks, plantings, harvest estimates, harvest events, production losses, farm inputs and input usage — the half of a farm that never appears in a shopping cart.
Architecture
nginx terminates TLS in front of a Next.js frontend and a Django REST backend, both kept alive by PM2. The Expo app talks to the same API as the web.
serenity ▸ stack
Web browser Expo mobile app
│ │
└────────┬───────────┘
▼
nginx TLS · routing · Let's Encrypt
│
┌────────┴────────┐
▼ ▼
Next.js :3000 Django + DRF :8000
│
├── products · orders · cart · customers
├── payments M-Pesa init + callback
├── production crops · blocks · harvests
├── finance expenses · summaries
├── events types · policies · bookings
├── reports dashboard analytics
└── notifications WhatsApp webhooks
PM2 keeps both processes runningThe harder parts
Plenty of platforms sell vegetables. Far fewer connect the sale back to the field block the crop came from, the estimate it was measured against and the losses along the way. Modelling production properly — crops, blocks, plantings, estimates, events, losses, inputs — is what makes the reporting worth reading.
M-Pesa is not a redirect-and-hope flow. Initiation and the callback are separate events arriving at different times, so transactions are tracked as records in their own right, with proof-of-payment support for the cases that still need a human eye.
A webhook layer handles inbound messages and chat sessions rather than simply opening a chat window. For customers who live in WhatsApp, that is the difference between a contact button and a channel the business can actually operate.
Storefront, admin console and an Expo mobile app all speak to the same Django REST API with JWT auth. One set of rules about who may do what, rather than three implementations that drift apart.
Inventory loss and production analytics sitting beside sales and top products is the point of building both halves in one place.
Stack