The Problem: One Business, Several Disconnected Systems
Dairy Farm Products was running a wholesale operation where the commercial workflow extended far beyond a conventional online store.
Customers needed to place self-service orders using negotiated pricing. Sales representatives needed to create orders while visiting customers and record physical cash collected against outstanding balances. Administrators needed to approve orders, prepare fulfilment, allocate incoming payments, maintain the product catalog, and keep the accounting ledger synchronized with Sage 50.
Those activities belonged to the same business process, but the underlying systems were fragmented.
Three problems were particularly expensive:
- Field activity stopped short of the ledger. Orders and physical collections recorded by sales representatives still had to be reconciled with customer orders, invoices, and accounting records.
- Sage 50 provided no native real-time webhook path. The web application could not simply subscribe to every financial change, so synchronization needed its own resilient background process.
- Wholesale pricing depended on customer context. A product could have a base price, a wholesale-tier price, and a negotiated customer-specific exception. The same pricing logic had to behave consistently whether the order originated from a customer or a sales representative.
The problem was therefore larger than storefront development. Pricing, ordering, fulfilment, payments, customer administration, and accounting all needed to operate against a shared system of record.
The Targeted Outcomes
The system was designed around three operational goals:
- Unified Omnichannel Sales: Bring self-service customer ordering and field-sales activity into one application and one operational data model.
- Automated Accounting Synchronization: Reduce manual invoice and payment entry by synchronizing approved operational state with Sage 50 through background processing.
- Consistent Contract Pricing: Resolve customer-specific pricing from the same rules across both digital and field-sales channels.
These were system objectives. Historical project outcomes are discussed separately in the full case study.
The System: A Shared Operations Platform
I engineered DFP as a modular monolith rather than a collection of disconnected storefront, field-sales, admin, and accounting tools.
The application shared a strongly typed domain model across customer ordering, sales-rep workflows, administration, pricing, payments, and background synchronization. That gave each operational role a different interface over the same underlying business state.
1. Customer, Field Sales, and Administration
The platform supported three primary operating contexts:
- Customer self-service: Customers could browse the wholesale catalog, see pricing resolved for their account, place orders, and pay outstanding balances by card through Stripe.
- Field sales: Sales representatives could create orders on behalf of customers and record physical cash collected against outstanding balances while working away from the office.
- Administration: Internal staff could review and approve orders, manage catalogue and inventory data, allocate incoming payments, inspect synchronization state, and control customer accounts.
The customer-facing catalog makes the commerce side concrete. Buyers can filter products by category, subcategory, and price, inspect VAT-labelled pricing, and add products from the same interface used by the underlying pricing engine.
Once an order enters the operational side of the platform, administrators can see its approval state, origin, sales-round context, placement and delivery dates, item detail, and fulfilment controls.
The important design decision was that these were not separate data silos. Customer orders, rep-created orders, admin approval, fulfilment state, and financial reconciliation all moved through the same operational model.
2. Dynamic Wholesale Pricing
Wholesale pricing could not be represented reliably as one price per product.
The platform therefore resolved prices through a simple precedence model:
- Customer Override: Use a negotiated customer-specific price when one exists.
- Tiered Group Price: Otherwise apply the customer's wholesale group or pricing tier.
- Base Price: Fall back to the master-product price when no more specific rule applies.
That structure keeps exceptions narrow. A negotiated contract does not require duplicating an entire catalogue, while a tier-level change can apply to many related accounts at once.
The same resolution path serves both self-service ordering and field-sales activity. That matters because contract pricing should not change simply because a different person entered the order.
The application used TypeScript, Zod, and tRPC around this shared domain model, helping pricing rules and validation remain consistent between server behavior and the interfaces consuming them.
3. Sage 50 Synchronization and Financial Reconciliation
Sage 50 remained part of the financial workflow, but it did not provide the kind of real-time webhook integration a modern web application could depend on.
I built a synchronization layer using Redis-backed BullMQ jobs and background workers.
Approved operational changes could be queued for Sage without making the customer or administrator wait for the accounting system to respond synchronously. The reverse path used polling and snapshot comparison to identify changes that needed to be reconciled back into the platform.
The same separation also helped with payments.
A sales representative could record cash received in the field. A customer could pay by card through Stripe. Administrators could then allocate incoming receipts against the appropriate invoices while seeing how much remained unallocated and whether synchronization had completed.
This is the important operational loop: order activity becomes approved financial state, payments are allocated against that state, and synchronization moves the resulting accounting information between the application and Sage 50 without turning Sage availability into a blocking dependency for every user action.
The Outcome: One Operational Model Across Commerce and Accounting
The value of the platform came from connecting workflows that had previously required people to bridge the gaps manually.
Customers gained a self-service ordering and payment route. Sales representatives could work from the same operational system while visiting customers. Administrators could move an order from review into fulfilment, allocate receipts against invoices, and inspect synchronization state without maintaining separate versions of the same transaction.
The pricing engine reduced duplication in customer-specific pricing data, while the queue-based Sage integration moved accounting synchronization away from the critical path of customer and admin interactions.
The project ultimately became an end-to-end B2B commerce and operations platform spanning catalogue discovery, contract pricing, field ordering, order approval, fulfilment, inventory, payment allocation, Stripe, Sage 50 synchronization, and self-hosted AWS infrastructure.
Read the full DFP engineering case study for the pricing model, Sage synchronization strategy, administrative workflows, and historical project outcomes.