What was not working and how it was measured before the change.
Case studies & technical scenarios
A case study should show decisions, not just a pretty outcome.
We do not invent clients, numbers or results. The materials below are representative technical scenarios showing how we document a problem, architecture and acceptance. Real client stories are added only with permission.
01 / ERP
Representative scenario
WooCommerce ↔ ERP without duplicate orders or silent gaps
The store sends orders to ERP while ERP owns stock and pricing. The external API is occasionally slow and webhooks may be delivered more than once.
Risk
- duplicate order after a repeated request
- stock never recovers after a failed synchronization
- no trace explaining why a specific sync failed
Technical decisions
- ERP as source of truth for price and stock
- idempotent order creation keyed by external identifier
- queue, retry with backoff and manual replay
- periodic reconciliation
Acceptance criteriaThe same event can be processed again without creating a duplicate.An API outage does not lose the order.An operator can find and replay a failed synchronization.
02 / B2B
Representative scenario
WooCommerce B2B with negotiated pricing, roles and quick ordering
A business customer has a negotiated price list, multiple buyers, permission rules and needs to order by SKU without browsing the storefront.
Risk
- pricing logic spread across plugins and exceptions
- no clear model for companies and users
- ERP and WooCommerce calculate different prices
Technical decisions
- one source of pricing truth and explicit precedence rules
- company account separated from user accounts
- buyer / admin / approver roles
- quick ordering optimized for SKU and quantity
Acceptance criteriaThe same cart shows the correct price on listing, product, cart and checkout.Permissions work at company level.Every order price has an unambiguous source.
03 / RESCUE
Representative scenario
Taking over a store where every update is treated as business risk
The store still works, but it has old extensions, custom code in several places and no confidence about what will break after an update.
Risk
- no safe test environment
- unknown dependencies between plugins
- critical workflows have no acceptance checklist
Technical decisions
- inventory of extensions and custom code
- staging that mirrors production closely enough
- critical paths: cart, payment, shipping, integrations
- phased updates with rollback plan
Acceptance criteriaComponents blocking updates are known.There is a repeatable regression checklist.Changes can be released in phases instead of a big bang.
When we publish a real project
Every case study should meet the same standard of evidence.
Traffic, systems, dependencies, deadlines and the things we could not change.
Why this architecture was chosen and what alternatives we deliberately rejected.
Only data that can be compared and fairly attributed to the scope.
Have a similar scenario?