Build Log
How a local delivery startup slowly became an operations platform.
Sometimes the biggest problem isn't getting more customers. It's making sure every order reaches the right people without creating more work behind the scenes.
bezgoFresh didn't begin as a software project.
It began as a small delivery startup trying to connect local vendors with customers online.
Orders arrived through WhatsApp.
Menus changed every morning.
Vendors updated prices manually.
Operations teams copied orders into spreadsheets.
Invoices were created by hand.
Delivery assignments happened over phone calls.
The business worked.
But only because people spent hours every day holding it together.
That became the real problem.
Living inside the operation
Before building anything, I wanted to understand how every piece of information moved through the business.
From the customer's order to the vendor's preparation… from the delivery rider to the final payment…
Every order passed through multiple people.
Each hand-off created opportunities for mistakes.
Wrong quantities.
Missed items.
Duplicate orders.
Late deliveries.
None of these problems existed because people weren't capable.
They existed because the system depended on people remembering everything.
Instead of asking people to work harder, I wanted the system to carry more of the work.
Designing the system
The goal wasn't to replace WhatsApp.
Our customers already loved using it.
Instead, we built software around the way people already worked.
Every tool solved one small piece of friction.
Together they became an operating system for the business.
Operations Bot
Instead of manually copying every order into spreadsheets, the bot reads incoming WhatsApp messages, extracts structured order data and automatically updates the day's operations. Invoices and payment links are generated automatically after orders are confirmed. What previously took minutes now happens almost instantly.
Instead of repeating the same administrative work every day, the team focuses on serving customers.
Know more →Vendor Communication System
Vendors no longer wait for phone calls.
Menus can be updated digitally.
Orders arrive automatically.
Preparation status stays synchronized with operations.
Less confusion.
Less back-and-forth.
Behind every customer order sits an internal dashboard that keeps operations, vendors and deliveries connected through one shared source of truth.
Know more →Scaling was never the real goal — removing the friction was.
Interestingly, we never built these tools because we wanted to "scale".
We built them because every new order created more manual work.
By reducing repetitive work instead of adding more people, the business naturally became capable of handling more orders without increasing operational complexity.
Growth became a side effect of better systems.
The hardest problems weren't technical
Writing code was never the difficult part.
The difficult part was translating messy real-world behaviour into software.
Customers rarely order in exactly the same format.
Different vendors call the same product by different names.
Menu availability changes daily.
People edit messages after sending them.
Every exception became another design problem.
Building software taught me that reality is always more complicated than diagrams.
Decisions that we made
Rather than building one large application, the platform evolved into a collection of smaller systems that communicate with one another.
Each service has one responsibility.
Order parsing.
Vendor communication.
Menu generation.
Payments.
Delivery management.
Analytics.
Keeping responsibilities separated made the platform easier to extend as the business continued to evolve.
The results we got
- 100+ Orders handled daily
- Multiple internal tools connected together
- Significant reduction in manual order processing
- Automated menu generation
- Automated invoice creation
- Centralized vendor communication
- Shared operational dashboard
If I rebuilt it today…
This project changed how I think about software.
If I started again today, I'd move away from Google Sheets much earlier, introduce an event-driven architecture from the beginning, and design every service around asynchronous communication.
The current platform solved the business problems it faced.
But every version teaches you how to build the next one better.
What did I learn from this
Before bezgoFresh, I believed software solved problems. Today I think software does something different. It removes friction between people. The best products aren't the ones with the most features. They're the ones people stop noticing because everything simply works.
That's the kind of software I want to keep building.
Interested in how the platform was built?
Let's talk.
Reach Out