Four years of evolving an ecommerce front and ERP back for a distributor.

A long-term technology partnership running since 2021. Four years of shipping, refining, and rebuilding the operating system of a distributor who has grown alongside the work. The current state of the system represents the accumulated decisions of that partnership, on a modern self-hosted stack with no SaaS dependencies in the application architecture.

This is the kind of engagement that defines what Simply Five Studio aims for. Build once. Stay involved. Evolve as the business evolves. Own the stack outright. Refuse the temptation to convert every operational question into a recurring SaaS fee.

The situation

AK Suppliers & Distributors operate in the distribution business. The catalogue is broad, the customer base is mixed (some retail, some trade), and the order flow is steady but lumpy. The challenge of the category is the marriage of a public-facing storefront, which buyers expect to be fast, browsable, and convenient, with a back-of-house operation that needs to track product enquiries, generate proforma invoices, coordinate shipping, and answer the founder's question every morning: what came in, what is going out, what is unresolved.

When the partnership began, the firm had a WooCommerce storefront and a manual operation behind it. Orders came in. The team handled them by phone, WhatsApp, and email. Reconciliation was painful. Visibility was poor. The founder's instinct, which proved correct over the years, was that the front-end and the back-end of the business needed to share a single operating brain.

The first version of the system addressed the most immediate friction: proforma invoice generation, branded PDFs, and a unified order management surface. Subsequent versions, each driven by an operational problem the firm encountered, deepened the integration and modernised the stack. The current state is the cumulative outcome of four years of that work.

What we built

The current system spans four operational concerns, integrated through a single self-hosted application.

Storefront and ecommerce

The WooCommerce store handles the customer-facing browsing, cart, and checkout. Where WooCommerce is good (product display, search, basic order capture), it is allowed to do its job. Where its standard behaviour stops short of the firm's needs, the custom ERP picks up.

Custom ERP for enquiries and orders

A web application that runs alongside WooCommerce and consumes its order events. Product enquiries that come in by form, WhatsApp, email, or store browse all land in the same unified queue. The team works the queue from a single surface rather than across four channels.

Proforma invoices generate with brand-correct PDFs. The customer receives the PI by email and by WhatsApp, both branded, both tracked back to the enquiry record. When the customer confirms, the PI converts to an order. The order moves through fulfilment with status visible to the customer and to the team.

Notifications and messaging

WhatsApp notifications for proforma sent, order confirmed, order dispatched, and order delivered. Web push notifications for users who have opted in. Email confirmations with branded templates. None of these flow through a third-party notification SaaS. The firm runs its own mail server on the VPS and integrates WhatsApp Cloud API directly, without a BSP layer collecting margin.

PDF generation, search, and progressive web app

PDFs are generated via Gotenberg, which runs as a service inside the stack. The catalogue is indexed for fast search. The customer-facing surface is installable as a Progressive Web Application, which means returning customers can keep it on their device home screen and experience near-native responsiveness.

How it works in practice

A trade customer browses the storefront, adds items to their cart, and checks out. WooCommerce captures the order. The ERP picks it up immediately, generates a branded proforma invoice, sends it to the customer by email and WhatsApp, and surfaces it inside the team's internal order queue.

A different customer phones in an enquiry. The team captures the enquiry against the customer's record, generates a proforma directly, sends it through the same channels. From the customer's perspective the experience is identical to checking out online. From the team's perspective, both flows produce the same operational record.

When orders ship, the system updates the customer through the same channels. The team moves cards through the queue. The founder reviews the day's activity from a single dashboard. The reporting layer answers the questions the founder cares about: which categories moved, which customers ordered, which enquiries are still open, where is anything stuck.

The operational tempo is steady. The system has absorbed every increase in volume the firm has thrown at it without requiring a fundamental rebuild, because the architecture was deliberately built to grow with the business rather than around an initial-scale assumption.

What changed

The firm operates today with a fraction of the per-order coordination cost it had four years ago. The catalogue is larger. The customer base is larger. The team is not proportionally larger. The system absorbs the work that used to require people.

The customer-facing experience is materially better than what the firm could have built with stitched-together SaaS subscriptions. The PDFs are branded. The notifications are timely. The PWA is fast. The buyer's sense of who they are buying from is positively shaped by every interaction, which compounds into trust and repeat business.

The financial structure has shifted. The firm pays for hosting (a single VPS) and the ongoing technology partnership. Nothing else. There is no monthly SaaS bill that scales with order volume, no per-message WhatsApp fee paid to a middleware, no per-PDF charge from a third-party document service. The marginal cost of an additional order is essentially zero. The financial structure of the firm benefits from that fact every month.

Stack and choices

The current stack is the one Simply Five Studio defaults to for projects of this profile, refined over the four years of this partnership and others.

FrankenPHP as the application server, which gives the firm the operational simplicity of PHP with modern performance characteristics. PostgreSQL as the data layer. Mercure for the real-time updates that keep the team's view of the queue synchronised. Caddy as the edge proxy with automatic HTTPS. Tailwind for the design system. Gotenberg for PDF generation. WhatsApp Cloud API integrated directly, no BSP. A mail server running on the same VPS. Web push for the PWA. All running on KVM VPS infrastructure that the firm owns.

This stack has one important property: every component is something the firm can run without paying a per-seat or per-transaction SaaS fee. The total operational cost is predictable and modest. The capability is high. The trade-off is that the firm chose a technology partner that takes the operational ownership seriously, which is the role Simply Five Studio fills here.

What's next

The partnership continues. New features ship in quarterly cycles, in response to operational questions the firm encounters. The stack is updated as the upstream components release new versions. The firm does not need to think about any of this, which is the value of the partnership model.

The next horizon focuses on deeper analytics from the operational data the system now produces. Category margins, customer lifetime value, inventory turnover by SKU. The data has been captured throughout the four years. Surfacing it as decision support is the next layer of work.