From COD fraud nightmares to automated intelligence: the story of building a business platform for Bangladesh's e-commerce market.
🎯 The Problem That Started Everything
Picture this.
A small shop owner is managing their online business. They've got WooCommerce for the website, Excel sheets for stock tracking, Pathao open on one phone, Steadfast on another, and Facebook Page orders coming in through DMs. They have a physical notebook for customer history, and absolutely no way to know if a new customer is a fraudster who'll refuse the delivery.
Every morning starts with copy-pasting order details from three different places. Every afternoon is spent manually messaging courier agents. Every evening is reconciling which orders got delivered, which got returned, and how much money actually came in.
This isn't a unique story. This is the daily reality of thousands of SME owners, retailers, and e-commerce merchants.
I built Vendzoo to end this chaos.
Vendzoo is an all-in-one SaaS Business OS: POS, Inventory, Courier, Fraud Detection, Customer Intelligence, Marketing, and Analytics, all in one dashboard.
🌐 vendzoo.com
This is the story of how it was built, the real problems we solved, and the decisions that shaped the product.
🏗️ The System at a Glance
Vendzoo is built on Laravel 13 with PHP 8.3, backed by MySQL, with a Tailwind CSS v4 and Vite 8 frontend. Nothing exotic, just a solid, modern stack chosen for reliability and developer ergonomics.
What makes it interesting isn't the stack. It's the three layers sitting on top of it.
The core layer handles POS, orders, inventory, invoicing, and multi-user access with role-based permissions.
The integration layer connects to everything a merchant already uses: WooCommerce, Shopify, Facebook Commerce, Pathao, Steadfast, RedX, Carrybee, Firebase, Telegram, SMS, WhatsApp, and Email.
The intelligence layer is where Vendzoo earns its "Business OS" label: a fraud risk engine, customer segmentation, churn prediction, courier performance analytics, inventory velocity tracking, and full profit & loss reporting. All running automatically in the background.
Chapter 1: The Courier Problem: 4 Companies, 1 Unified System
Bangladesh's e-commerce runs almost entirely on COD (Cash on Delivery). And there are four major courier companies: Pathao, Steadfast, RedX, and Carrybee. Each has its own API, its own authentication system, its own webhook format, and its own quirks.
The tempting approach is to write four separate integrations and treat each courier differently throughout the codebase. We didn't do that.
One Contract, Four Implementations
Every courier in Vendzoo follows the exact same internal contract. Whether the merchant is using Pathao or Carrybee, the rest of the system asks the same question in the same way and gets the same type of answer back. The dashboard doesn't know or care which courier it's talking to.
This means adding a new courier in the future requires writing exactly one new implementation: nothing else in the system needs to change.
Three Delivery Pricing Modes, One Calculator
Different merchants price delivery differently. Some charge a flat rate: ৳60 inside Dhaka, ৳120 outside. Some use weight-based tiers with different prices for different brackets. Some let the courier's own API calculate the charge live based on distance and weight.
A single delivery calculator handles all three modes, knows which to use, and falls back gracefully if the courier API is temporarily unavailable. The merchant configures their preference once. After that, pricing just works, in POS orders, WooCommerce orders, and manual orders alike.
The Webhook Lifecycle
When Pathao delivers an order, or returns it, they notify Vendzoo via webhook. The flow is immediate: the webhook arrives, we identify the courier, we update the order status, we log the update, and we notify the merchant via push notification and Telegram, all within seconds.
We keep each courier's updates in dedicated storage rather than one mixed log. This makes reporting cleaner and debugging faster. If something's off with Steadfast tracking, you look at Steadfast's data, not a pile of mixed records from all four couriers.
Chapter 2: The Fraud Engine: Protecting Merchants from COD Return Losses
This is the feature I'm proudest of.
Why COD Fraud Hurts More Than People Realize
When a customer refuses a COD delivery, the merchant doesn't just miss the sale. They absorb the outbound delivery fee, the return delivery fee, the COD handling charge, and sometimes the cost of damaged packaging, on top of the lost inventory value. Do this a few hundred times a month, and it becomes a serious financial problem.
The frustrating part is that these risky customers are often repeat offenders. The same phone number that refused delivery on three other merchants' orders will show up as a fresh "new customer" on your store, with no visible history.
A Three-Pillar Risk Score
Every order in Vendzoo receives a Unified Risk Score from 0 to 100, built from three independent signals that we combine with different weightings.
The first signal is the customer's delivery success rate within your own store. If they've placed multiple orders with you and consistently accepted delivery, that's a strong positive signal. If they've returned or refused most of their orders, that weight pulls the score down.
The second signal comes from an external courier fraud database that tracks delivery behavior across many merchants and platforms, not just yours. A customer who is completely new to your store might have a well-documented history of refusing deliveries elsewhere. This cross-platform view is what makes the score meaningfully different from just checking your own records.
The third signal is a basic consistency check: does the phone number on the customer's profile match the phone number on the shipping address? A mismatch is a small red flag. Fraud attempts often involve different contact numbers at different stages.
A combined score above 80 is low risk. The 50–80 range is medium, proceed with awareness. Below 50 triggers an instant alert to the merchant before the parcel is dispatched.
What Happens When the External Service Goes Down?
This was one of the most important design decisions in the entire system. External APIs go down. Servers have outages. Networks have timeouts.
If the fraud data service is unavailable, Vendzoo doesn't block orders or throw errors. It falls back in layers: first to recent cached data for that phone number, then to older cached data marked as stale, and finally to a neutral mid-range score if nothing is cached at all. The merchant always gets a result. The order always flows. The system is never hostage to a third-party outage.
Preventing Duplicate Alerts Under Load
Here's a subtle problem: if two background workers pick up the same high-risk order at the same moment, the merchant could receive two identical "HIGH RISK!" alerts. Confusing and unprofessional.
The fix is an atomic database update. The first worker to record the notification wins. The second worker checks, sees it's already been recorded, and exits quietly. No matter how many workers are running in parallel, exactly one notification goes out, guaranteed at the database level, not just in application logic.
Chapter 3: Customer Intelligence: Knowing Who Your Customers Really Are
Every merchant has the same questions, but almost none of them have good answers: Who are my most loyal customers? Who bought once and never came back? Who is about to churn? Who should I send a win-back offer to right now?
Vendzoo builds answers to all of these automatically, without the merchant lifting a finger.
RFM: A Framework That's Stood the Test of Time
RFM stands for Recency, Frequency, and Monetary value. It's a customer segmentation method that's been used in direct marketing for decades, and it remains one of the most practical and interpretable frameworks for understanding customer behavior.
Recency measures how recently a customer placed their last order. A customer who ordered yesterday is more engaged than one who ordered eight months ago, even if the older customer's total spend is higher.
Frequency counts how many successful deliveries a customer has completed. Repeat buyers who consistently accept delivery are a fundamentally different category from one-time buyers, even if the one-time buyer spent more on that single order.
Monetary tracks the total revenue generated from completed orders. This filters out the customers who order often but return often too; only successfully delivered orders contribute to the monetary score.
Each dimension gets a score, and the combined result automatically places every customer into a persona: Champions, Loyal Customers, At Risk, Big Spenders, Promising, Hibernating, High Return Risk, or Lost. These labels update in the background continuously, so when a merchant opens their customer list, they immediately see who needs attention and who deserves a reward.
Churn Prediction Without Machine Learning
Separately from the RFM segmentation, Vendzoo runs a lightweight churn prediction based on a simple principle: the longer since a customer's last order, the higher the probability they've moved on.
Customers who haven't ordered in over a month get flagged as potentially at risk. Those who've gone quiet for 60 days are hibernating. At 90 days, they're classified as lost. These aren't predictions from a trained model; they're clear, explainable thresholds that work well for the SME context and can be acted on directly without a data scientist in the loop.
Chapter 4: Inventory Intelligence: Smarter Stock Management
Sales Velocity
Vendzoo tracks the average number of units sold per day for every product, what's commonly called sales velocity. It's derived from historical sales movement data, calculated automatically, and updated daily.
The value of knowing velocity is simple: a product selling 15 units a day has completely different restocking needs than one selling 3 units a week. Without this number, merchants either reorder too late (stockouts) or too early (cash tied up in dead inventory).
When to Reorder: Suggested Automatically
Using sales velocity together with the typical lead time to receive new stock, Vendzoo suggests a reorder threshold for each product. When current stock drops to that threshold, it's time to reorder, not when stock hits zero. The buffer accounts for the days it takes new stock to arrive and a small safety cushion for demand spikes.
These suggestions appear on the inventory dashboard without any configuration from the merchant. The system calculates them fresh in the background every day, invisibly.
Built for Scale from the Start
One early performance mistake was calculating velocity for each product one at a time: a separate database query per SKU. With 10 products in development, this was fine. In production with a merchant managing 2,000 SKUs, it became a serious bottleneck.
The fix was restructuring the calculation to aggregate data for all products in a single database query, then distribute the results. The math is identical; the number of queries dropped from 2,000 to 1. This now runs entirely in the background, finishing long after the merchant's page has loaded, with zero impact on their experience.
Chapter 5: Courier Intelligence: Which Courier Actually Performs Best for You?
Every merchant has a preferred courier. Most of those preferences are based on gut feel, past complaints, or a colleague's recommendation, not data.
Vendzoo builds the data view instead. For every courier a merchant has ever used, it calculates the actual delivery success rate broken down by destination area, using the merchant's own real order history, not industry averages or courier marketing materials.
If a merchant has shipped 200 orders to Chittagong with RedX and 180 were delivered, that's a 90% success rate for that courier in that area. If Pathao handled 150 orders to the same area with 105 deliveries, that's 70%. The recommendation is clear, and it's built entirely from the merchant's own data, no external API required.
Chapter 6: WooCommerce & Shopify: One Dashboard, All Channels
Many Bangladesh merchants have both an online store and a physical shop. The inventory nightmare: the website shows 10 units in stock, but 8 were already sold at the counter this morning.
Vendzoo solves this by treating all channels as part of the same inventory pool. When an order is placed on WooCommerce, stock is deducted from the same pool that POS orders use. When a Shopify order syncs, the same thing. There's one source of truth, and every channel reads from and writes to it.
When a WooCommerce Order Arrives
A customer places an order on the website. Within seconds, the webhook reaches Vendzoo: we check for duplicates, find or create the customer by phone number, resolve the delivery charge, create the order in the Vendzoo dashboard, deduct stock, and notify the merchant. From that point on, the merchant handles everything in Vendzoo: booking the courier, updating status, managing returns. The WooCommerce dashboard becomes unnecessary for day-to-day operations.
Shopify at Scale
Syncing inventory to Shopify for a merchant with thousands of products can't be done in one shot: it'll time out. Vendzoo breaks the sync into small batches and processes each batch as a separate background job. If one batch fails due to a network issue or API rate limit, only that batch retries, not the entire catalog.
Chapter 7: Marketing Automation: Targeted, Not Broadcast
Most merchant marketing is the same blast to everyone: "20% off this weekend!" Vendzoo makes it possible to do something much more effective: send the right message to the right customer at the right moment.
Because every customer already has an RFM badge, merchants can build campaigns that target specific segments. A win-back campaign can go exclusively to customers who haven't ordered in over 45 days. A loyalty reward can target Champions and Loyal Customers only. High Return Risk customers can be excluded from all outgoing campaigns automatically.
The audience builds itself. The merchant writes the message and picks the segment.
Behind the scenes, campaigns use a dedicated queue channel, enforce rate limits per messaging provider, and retry failed sends with increasing delays: 30 seconds, then 2 minutes, then 5 minutes. Campaign sending also pauses automatically after 10 pm to respect customer boundaries, and resumes the next morning.
If a merchant manually triggers a campaign at the exact same moment a scheduled send fires, the system ensures only one dispatch happens, through an atomic lock at the database level that prevents any double-sending.
Chapter 8: Real-Time Notifications
Merchants need to know about new orders and delivery updates the instant they happen, not on their next login.
Vendzoo supports push notifications through Firebase and message delivery through Telegram. Connecting Telegram is a one-tap flow: the merchant gets a unique time-limited link, taps it, and their Telegram account is permanently linked. Every important event (new order, parcel delivered, high-risk alert) arrives as a Telegram message in addition to a push notification.
The Firebase integration is built without any heavyweight SDK dependency: a lightweight custom implementation that handles token caching and minimizes unnecessary API calls.
Chapter 9: Order Lifecycle: A State Machine That Prevents Mistakes
Orders in Vendzoo follow a defined lifecycle, and transitions between states are enforced by the system itself. You can't mark an order as returned without it having been delivered first. You can't skip from pending to completed in a delivery order. The only transitions the UI shows are the ones that are actually valid from the current state.
For takeaway (POS) orders, the flow is simple: Pending to Completed, with Cancelled and On Hold as side paths.
For delivery orders, the full path runs from Pending through Confirmed, Ready to Ship, In Courier, Delivered, and finally Completed, with Returned, On Hold, and Cancelled available at the right stages.
The result is data that's always logically consistent. Reporting is clean. Status histories make sense. There's no way to accidentally create an order that's "delivered but was never with a courier."
Chapter 10: Subscriptions: Feature Limits Done Right
Locking In What You Signed Up For
When a merchant subscribes to a plan, Vendzoo takes a snapshot of that plan's limits and locks them to the subscription. If an admin later changes the plan's limits for new subscribers, existing merchants are unaffected, they keep what they signed up for, for the duration of their subscription.
This matters for trust. Merchants shouldn't wake up to find they've exceeded limits on a plan they've been paying for, because someone changed the rules without them.
Upgrading Without Losing Your History
When a merchant upgrades to a higher-tier plan, their existing usage counts carry over correctly. A merchant who had 90 products on their previous plan doesn't get a "free" reset to zero products used when they upgrade: the 90 transfers to the new plan's higher limit. Small detail, but it closes a loophole that would otherwise let merchants game usage tracking.
What Vendzoo Has Become
What started as an attempt to replace a few Excel sheets has grown into something much larger: 76 data models, 35 service classes, 31 background jobs, four courier integrations, three e-commerce platform connections, and five notification channels, all working together in a system that feels simple to use because the complexity is fully hidden.
The stack is Laravel 13 with PHP 8.3, Tailwind CSS v4, Vite 8, Pest PHP 4 for testing, and Sentry for production monitoring. The development environment starts with a single command that concurrently runs the server, frontend hot-reload, queue worker, and log viewer in one terminal window.
The product is live. Real merchants use it daily. And there's still a long roadmap ahead: a mobile app, bKash and Nagad payment gateway integration, automated COD remittance reconciliation, and multi-currency support for cross-border selling.
