From Siloed Tools to an Integrated ERP

In plain language

Jiahao runs a small bakery-ingredient wholesale business. Purchases go in one Excel sheet, stock is reported by the warehouse over chat, orders are written up in another tool, and who still owes money lives in yet another spreadsheet. As soon as business grew, the numbers stopped agreeing: the system says in stock but the shelf is empty, so he oversells; month-end reconciliation runs past midnight; one customer turns out to have owed money for half a year before anyone noticed. The problem isn't any single tool — it's that they each keep their own books and never talk to each other. What he needs is to pull purchasing, sales, stock and receivables into one system: a lightweight ERP.

ERP (enterprise resource planning) sounds huge, but for a small business the core is simple: let the whole company see one set of numbers, and when a transaction happens, have the related ledgers update together. It leans heavily on a database and a backend, but the point was never to have many features — it's data consistency. This journey breaks into four steps: first move scattered products, stock and customers into one shared database, then let purchases and orders automatically move stock and receivables, then add permissions, reports and auditing, and finally retire the old tools gradually into a governable operational hub.

Architecture

How it flows

The hardest part of an ERP isn't features — it's data consistency

An ERP's real barrier is rarely the code; it's that one number can have only one answer. How many boxes are left, how much a given customer owes — if three Excel files each say something different, no one can arbitrate. The first step of integration is always to make everyone read and write the same data.

Technically, an ERP adds three hard requirements over any single tool:

• Single source of truth. Stock and balances can have only one authoritative answer. When data is spread across files, each one "thinks it's right" and conflicts are unsolvable; a unified source is the starting point of integration.
• Transactional consistency. One shipment must do three things at once: decrement stock, create a receivable, update the customer balance. Those three either all succeed or none count — you must never decrement stock yet miss the ledger entry. This is exactly what a database "transaction" and its invariants exist to protect.
• Migrate gradually, never big-bang. An ERP touches the company's lifeblood (stock and money), so swapping everything at once gambles on company-wide downtime. The right way is to run old and new in parallel, move one module at a time, and retire each old tool only after the numbers reconcile.

For working with AI, an ERP slices cleanly into modules: build the single source of truth for products and stock first, then the purchase/ship linkage, then receivables and reports. Each step is an independently reviewable PR — but because it touches stock and money, these high-risk parts must be verified case by case with reconciliation tests, never skipped.

Key takeaways

• An ERP's value is in data consistency and a single source of truth, not in having many features — the whole company sees one set of numbers.
• One operational event (a shipment) cascades across several ledgers (stock, receivables, customer balance); treat it as one indivisible transaction, not separate books.
• Don't big-bang the migration: run old and new in parallel, move module by module, reconcile before retiring old tools — and where stock and money are involved, correctness is non-negotiable.