Collapsing two databases into one: a distributor's storefront, ERP, and Tally on a single source of truth.

A technology partnership running since 2022. Four years of shipping, refining, and rebuilding the operating system of a distributor who has grown alongside the work. This case study is about the largest single upgrade in that partnership: retiring WooCommerce, rebuilding the storefront as a custom Next.js application on the same PostgreSQL the ERP already runs on, and making Tally the single source of truth for products, pricing, and invoices across the whole stack.

The earlier version of this system, a WooCommerce storefront integrated with a custom ERP, served the firm well for three years. The decision to rebuild was not a reaction to a failure. It was a decision to remove a structural cost that had been quietly compounding the entire time: two databases holding the same data, kept in step by a sync that the firm did not own and could not fully control.

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 category demands the marriage of a public-facing storefront, which buyers expect to be fast and convenient, with a back-of-house operation that tracks enquiries, generates invoices, coordinates dispatch, and answers the founder's question every morning: what came in, what is going out, what is unresolved.

For three years the firm ran a WooCommerce storefront in front of a custom ERP. WooCommerce held its data in MySQL. The ERP held its data in PostgreSQL. Both databases contained customer records. Both contained product records. The two were kept in agreement by an integration that read order and product data out of WooCommerce and wrote it into the ERP.

That architecture works, and we have written about why it is often the right starting point for a distributor. But it carries a cost that grows with the business. The same customer existed in two places. The same product existed in two places. A price was correct only if both copies agreed. And the bridge between them depended on WooCommerce's plugin and API surface, which is not stable. Keys changed between versions. A plugin update would shift a field. The sync would stop, quietly, and the first sign of it was a mismatch someone noticed downstream. The firm was paying, in attention and in risk, for the privilege of keeping two truths aligned.

By 2026 the firm had also outgrown the enquiry-only model. The storefront could capture an enquiry, but it could not take a payment. Buyers who were ready to pay had to wait for a proforma and a manual step. The firm wanted a real checkout for the orders that did not need negotiation, without losing the enquiry path for the orders that did.

What we built

We rebuilt the storefront from scratch as a custom Next.js application that reads from and writes to the ERP's own PostgreSQL database. There is now one database. WooCommerce, and the MySQL instance behind it, is retired. We also added a live payment path and wired Tally in as the authoritative source for the data that used to drift.

One database, no sync

The new storefront does not have its own database. It uses the PostgreSQL database the ERP already runs on. When a customer registers, their record is written once, to the place the ERP reads from. When a customer sends an enquiry or places an order, it lands directly in the operational backend with no translation step in between. There is no nightly job reconciling two systems, because there are no longer two systems to reconcile. The storefront and the back office are two interfaces onto one set of records.

The integration code that used to read WooCommerce and write the ERP is gone. So is the class of failure that came with it. A plugin update can no longer break the sync, because there is no sync.

A live checkout alongside the enquiry flow

The store moved from enquiry-only to a full ecommerce surface powered by the PayU payment gateway. A customer builds a cart, then chooses how to proceed. They can send the whole cart as an enquiry, which is the right path for trade orders that need a negotiated price or a proforma. Or they can pay for the cart immediately through PayU, which is the right path for orders that are ready to close. Both paths produce the same kind of operational record on the same backend. The firm did not have to choose between trade reality and consumer convenience. It runs both.

Order processing, tracking, and notifications

Behind the checkout sits a full order-processing backend. Orders move through their lifecycle with status visible to the team and to the customer. The team works orders and enquiries from one queue. Customers track their own orders.

Every meaningful event reaches the right people. Customers receive email and WhatsApp notifications as their order is confirmed, processed, and dispatched. Admins receive their own notifications so nothing waits on someone happening to refresh a screen. None of this routes through a third-party notification SaaS. The firm runs its own mail server and integrates WhatsApp Cloud API directly, without a BSP layer taking margin on every message.

SimplyTally: Tally as the single source of truth

The most consequential piece is the Tally integration we built, which we call SimplyTally. It closes the loop between the firm's books and its storefront.

Products sync from Tally to the ERP by their Tally GUID. The GUID is the identity. There is no matching on names, no uploading spreadsheets, no manual re-keying. When the firm updates a product detail or changes bulk pricing in Tally, the change flows to the ERP automatically, and because the storefront reads the ERP's database directly, the new price is live on the store. Tally, the ERP, and the storefront share one price because they share one source. The firm changes a price in exactly one place.

SimplyTally also syncs customers and tax invoices from Tally into the ERP. When an invoice is raised in Tally, the ERP has it, and the invoice PDF can be sent to the customer on WhatsApp directly. The customer gets their GST invoice in the channel they already use, generated from the firm's actual books, with no separate document step.

How it works in practice

A trade customer browses the storefront, builds a cart, and sends it as an enquiry. The enquiry lands in the ERP immediately, against the customer's record, on the same database the team works from. The team prices it, the customer confirms, and the order moves through fulfilment with WhatsApp and email updates at each step.

A different customer builds a cart for items that are catalogue-priced and pays through PayU at checkout. The payment is captured, the order is created on the backend, and the same notification and fulfilment flow runs. From the firm's side, both customers produced the same kind of record. From each customer's side, the experience matched what they needed.

Meanwhile the firm's accountant works in Tally, as they always have. They add a product, adjust bulk pricing, raise an invoice. None of that requires touching the ERP or the store. The GUID-keyed sync carries products and pricing forward; the invoice sync carries the tax document forward to WhatsApp. The books and the storefront cannot drift, because the books are the source.

What changed

The firm runs on one database instead of two. The entire category of work that came with keeping MySQL and PostgreSQL in agreement is gone, along with the silent-failure risk that came with depending on WooCommerce's shifting API. Customer and product data have one home. A price is correct by construction, not by reconciliation.

The store earns money directly now. The PayU checkout converts the orders that were previously stalled behind a manual proforma step, while the enquiry path still serves the trade orders that need a human. The firm did not trade away its trade customers to gain a checkout.

The accountant's work in Tally now propagates everywhere without anyone re-entering it. Bulk price changes that used to mean editing the store and the ERP separately, and hoping Tally agreed, are a single edit in Tally. Tax invoices reach customers on WhatsApp as a byproduct of being raised, not as a separate task.

The marginal cost of an additional order remains essentially zero. The firm pays for hosting and the ongoing partnership. There is no per-order SaaS fee, no per-message WhatsApp charge to a middleware, no WooCommerce plugin stack to license and babysit.

Stack and choices

The storefront is a custom Next.js application. It reads and writes the ERP's PostgreSQL database directly, which is the architectural decision the whole upgrade turns on. PayU handles payments. WhatsApp Cloud API is integrated directly, with no BSP. A mail server runs on the firm's own infrastructure for transactional email. SimplyTally, the Tally integration we built, syncs products and bulk pricing by GUID and brings customers and tax invoices across so invoice PDFs can go out on WhatsApp.

The choice to retire WooCommerce was a deliberate trade. WooCommerce gave the firm a fast start and three good years. The cost it carried, two databases and a sync the firm did not control, was acceptable until the business was large enough that the cost outweighed the convenience. At that point a custom storefront on the ERP's own database stops being the expensive option and becomes the cheaper one, because it removes an entire maintenance surface rather than adding to it.

What's next

The partnership continues. With products, pricing, customers, and invoices all flowing from Tally through one database, the data is now clean enough to build decision support on top of it: category margins, customer lifetime value, inventory turnover by SKU, all from records that no longer need to be reconciled before they can be trusted. That is the next layer of work, and it is only possible because the foundation underneath it is now a single source of truth.