Portfolio / Custom operations platform
From disconnected inventories to a synchronized operation.
Kreatup manufactures packaging in units and sells it online in packs. We designed and built a multi-company platform that turns production into commercial availability, keeps WooCommerce in sync both ways and brings direct sales, customers and receivables into a single source of truth.
01The challenge
The factory counts units. The store sells packs.
Production tracks stock box by box; the WooCommerce store sells packs of 25. That gap, small on the surface, ran through the whole operation: inventory lived in the store, which knew how many packs to offer but not how many units sat in the warehouse, how many were committed to the web, or what happened to the ones that didn't complete a pack.
On top of that there were questions with no written rule: when to deduct a sale, what to do if WooCommerce repeats a notice, how to handle web orders alongside those coming in from the plant, by phone or on WhatsApp, and how to separate another group company's operation without duplicating the platform.
Questions without a rule
- 01How many units are physically in the warehouse?
- 02How many are committed to the store?
- 03What about units that don't complete a pack?
- 04Deduct when the order is created, or when paid?
- 05How to never deduct the same order twice?
- 06How to align stock, prices, offers and tiers?
- 07How to add plant, phone and WhatsApp sales?
- 08How to separate Colombia and the United States?
Our role
Business-rule discovery, product architecture and data model, experience design, full-stack development, WooCommerce and WordPress integration, automation, security, multi-company strategy, testing, documentation and go-live support.
02The rule
One formula that ordered the whole platform.
The store never offers an incomplete pack.
Published packs = (units assigned to the web − reserved) ÷ pack size, rounded down. If production holds 1,000 units and assigns 540 to a store that sells packs of 25, the store publishes 21. The 15 leftover units stay visible as residue.
Around that rule, an explicit split of responsibilities: the panel owns inventory and prices, WooCommerce owns web orders, the database keeps the truth and its history, and the queue absorbs temporary failures.
Panel owns stock and priceWoo owns ordersEverything goes in the ledger
03Operational inventory
Every unit knows where it is.
Total in production, free, assigned to the web, published packs, residue, what WooCommerce reports and sync status, in a single row. The balance isn't a number that gets overwritten: it comes from a movement ledger that can be rebuilt.
Production entry, assign or unassign web, adjustment or waste. The preview recalculates with the server's own rules on every keystroke: assigning 150 more units takes the K01 from 181 to 187 packs and leaves residue at 15. The impossible —assigning more than is free— is rejected before saving.
On empaqueskreatup.com the product page sells packs of 25 and shows the unit price by volume tier. Stock, price, offers and tiers come from the panel; nobody edits them in wp-admin.
04Two-way sync
What happens when an order is paid.
WooCommerce isn't an external automation: the integration lives at the core of the product, with signed webhooks, per-order idempotency, echo protection and periodic reconciliation.
WooCommerce
Web ordersSigned webhook
HMAC + idempotencyPostgreSQL
Source of truthQStash
Queue and retriesReconciliation
Panel ↔ storen8n
Alerts and extensions
- 01
The store notifies
WooCommerce sends the signed order. If the signature doesn't match, it doesn't get in.
- 02
Only paid counts
Inventory is deducted when an order reaches Processing or Completed. An order waiting on a bank transfer doesn't touch stock.
- 03
One transaction per SKU
The movement is written inside a transaction with the SKU's row locked, so a sale, an adjustment and a webhook can't overwrite each other.
- 04
Repeating doesn't duplicate
If WooCommerce resends the same notice, the order is already applied and it's ignored. A cancellation returns units only if they had been deducted.
- 05
The store updates through a queue
The database commits first; the new stock travels to WooCommerce through the queue. If the store doesn't answer, it retries at 1, 5, 15, 60 minutes and, after the fifth failure, raises an alert.
- 06
Reconcile
Reconciliation compares panel and store; it can report only or correct. A manual stock edit in wp-admin is logged as an alert and reverted.
At launch, on 19 September 2026, reconciliation recorded 0 differences between the panel and the store.
05Catalog, pricing and sales
One commercial ledger, wherever the sale happens.
Price per pack and its per-unit equivalent, scheduled offers and volume tiers. A single effective-price function calculates the same way for the store and for plant sales, and bulk adjustments by category show a preview before they apply.
Plant, phone or WhatsApp, at the same price as the store. The sale gets its own numbering per company, deducts inventory on delivery —paid now or on credit— and can be copied to WooCommerce as a mirror order without deducting twice.
Web orders and direct sales in one list, with channel, fulfilment status and payment status. What was collected and what is owed read on the same row.
06Customers and receivables
One record per customer, however they buy.
A web purchase and a WhatsApp sale from the same customer end up in the same record. The platform resolves identity, protects validated data and keeps receivables without spreadsheets.
Woo → ID → email → phone.
Every purchase links to its customer in that order. Phone, email, ID number and the NIT check digit are normalized so duplicates aren't born.
Validated data isn't overwritten.
If a checkout brings data that differs from the record, the record keeps its own and raises an alert. Duplicate records merge by moving orders, payments, notes and addresses, and the most restrictive consent wins.
Status comes from payments.
A payment with no order settles the oldest debt first; any surplus stays as credit. A credit sale can't exceed the limit without admin approval, and collections never get mixed up with marketing.
07Operational CRM
Follow-ups, collections and segments.
Pending follow-ups on top, segments for dormant, repeat, new and overdue customers ready to automate, and the list with channel, orders, units and total spent. All data in the screenshot is fictitious.
What's outstanding, what's overdue and whose, from the oldest due date to the newest. Payments are recorded from the customer record and recalculate the status of the order and its store mirror.
08Multi-company operation
Colombia and the United States, without mixing.
Users are shared, but access to each company is granted explicitly. The active company lives in the address —/co/inventario— so a link is always unambiguous and both operations can be open in separate tabs.
Catalog, inventory, prices and currency, customers, receivables, WooCommerce credentials, pack size, time zone and numbering per company. Transfers happen in units —each company packs its own way— and the outgoing and incoming movements are saved together or not at all.
09Architecture
Decisions you notice when something fails.
Per-SKU locking.
Critical changes use transactions and SELECT … FOR UPDATE, so sales, movements and webhooks never race for the same balance.
The database commits first.
The store updates through a queue, with retries and reconciliation. A WooCommerce outage delays publishing; it doesn't lose inventory.
The company is mandatory.
Services require the company as a parameter, unique indexes include it and access is checked at a single point. Tests seed two companies and check that they stay separate.
Events don't get lost.
Whatever goes out to n8n is stored in the database first and delivered later, signed, deduplicated and with up to ten retries. n8n extends the operation without sitting on its critical path.
10Traceability
What happened, who did it and what the balance was.
Movements, sync queue, received webhooks, reconciliations and audit log, in tabs. Every movement keeps its author, date, origin, external reference and result.
Low stock, overselling, sync failures, reconciliation differences, manual edits in the store and data conflicts, in one place, with the next step one click away.
11At launch
A snapshot of the go-live.
Figures documented on 19 September 2026, when the initial operation was loaded. They are a snapshot of the start, not the catalog's current size.
- 32
- products in the catalog
- 36
- SKUs managed
- 95,150
- units loaded
- 3,806
- packs published
- 0
- differences between panel and store
12Technical scope
What was built, counted on the code.
Counted on the repository on 7 October 2026. Tests cover the riskiest areas: packs, inventory rules, pricing, signatures, encryption, permissions, migrations, per-company routes and the integration with a simulated store.
- 24
- domain and support tables
- 11
- versioned migrations
- 15
- routes in the versioned /api/v1
- 197
- tests, all passing
- 4
- roles with server-side permissions
13Security and data governance
Security as part of the operation.
Admin, production, sales and read-only have different permissions, and the matrix is always checked on the server. WooCommerce and n8n keys are stored encrypted per company and never go back to the browser; they're shown once, when created or replaced.
The platform's own API issues tokens that are shown once, stored as a hash, belong to one company, carry specific scopes and can be revoked. Reading personal data takes a separate scope and is audited, and events sent to automations carry no ID number or address.
The model
- 01No public sign-up
- 02Lockout after five failed attempts
- 03Four roles, checked on the server
- 04Credentials encrypted at rest
- 05HMAC signatures in and out
- 06Hashed, scoped, revocable tokens
- 07Exports reserved for admins
- 08Audit log with before and after values
14The outcome
From an inventory need to infrastructure.
Production turned into availability.
The result is operational infrastructure that turns production into commercial availability, keeps the store in sync and gives the team control and traceability from one place.
What used to depend on people and manual steps in WordPress is now a set of verifiable, repeatable rules, on a base ready for more companies, currencies and channels.
SynchronizedTraceableReady to grow
beleafdesign
Do your store and your operation tell different stories?
If you produce in one unit and sell in another, or your inventory lives in a plugin nobody dares touch, we can model your business rules and turn them into software that applies them the same way every time.
Let's talk about your project