When I joined the E1OD project in 2023, there was no backend. No database schema, no API, no infrastructure — just an idea and a product vision. My job was to build it all from scratch using Laravel, and over the next couple of years, that's exactly what I did.
This is a case study of how I approached building the backend of E1OD — a managed branded merchandise and company swag store platform that automates the entire fulfillment lifecycle, from order placement to final shipment.
What Is E1OD?
E1OD is a B2B SaaS platform that allows businesses to launch fully automated, custom-branded merchandise stores — without carrying any inventory. When a customer places an order, the platform automatically routes it to the right supplier, retrieves the correct artwork, transmits order details to the decorator, and tracks fulfillment — all without any manual intervention.
The platform serves enterprises, marketing agencies, and HR departments who need a reliable, scalable solution for corporate gifting, promotional products, and employee swag.
Building the backend for a platform like this meant handling a lot of moving parts: multi-supplier integrations, real-time inventory, artwork management, order routing logic, and more — all running reliably under a single system.
The Tech Stack
The entire backend was built with Laravel (PHP). Here's why that was the right choice for this project:
- Eloquent ORM made it straightforward to model complex relationships between stores, products, suppliers, orders, and decorators.
- Laravel Queues were essential for handling asynchronous tasks like order routing, API calls to external suppliers, and file transmission — without blocking the main request lifecycle.
- Laravel Events & Listeners gave us a clean way to trigger downstream actions (like notifying a decorator) when an order changed state.
- Laravel Sanctum handled API authentication for the store-facing and admin-facing interfaces.
Systems I Built
1. Order Routing Engine
The core of E1OD is its ability to automatically route incoming orders to the correct supplier or decorator. I built a rules-based routing engine that evaluates each order against a set of conditions — product type, decoration technique, supplier availability, and geographic constraints — and dispatches it to the right destination.
This system had to be both accurate and fast. A misrouted order means the wrong supplier receives it, which breaks the entire fulfillment chain. I designed it with a priority queue model, where routing rules are evaluated in a defined order and the first match wins.
2. Supplier & Decorator API Integrations
E1OD connects directly to multiple third-party supplier and decorator systems. I built a modular integration layer where each supplier has its own adapter class, implementing a common interface. This made it easy to onboard new suppliers without touching the core routing logic.
Each integration handled:
- Authentication (OAuth, API keys, or session-based)
- Order submission in the supplier's required format
- Status polling and webhook reception for order updates
3. Real-Time Inventory Sync
One of the hardest technical challenges on this project was real-time inventory management. E1OD's promise to customers is zero inventory risk — meaning the store should never show a product as available if the supplier is out of stock.
The problem: suppliers don't all push inventory updates to us. Some expose an inventory API; others only update stock in batch files. Some have webhooks; most don't.
My solution was a hybrid sync system:
- For suppliers with webhooks or real-time APIs, we consumed updates immediately via event listeners and updated our local inventory cache.
- For suppliers without real-time capabilities, I built a scheduled polling system using Laravel's task scheduler that fetched inventory at configurable intervals per supplier.
- A Redis-backed cache layer sat in front of all inventory reads, so the storefront always responded fast — while background jobs kept the cache warm and accurate.
This meant customers always saw accurate stock levels without hammering supplier APIs on every page load.
4. Artwork Retrieval & File Transmission
Every order on E1OD needs the right artwork file sent to the right decorator — in the right format for the right decoration technique (embroidery, screen print, digital, laser, etc.).
I built an artwork management system where artwork assets are stored and indexed by product, logo placement, color, and decoration method. When an order is routed to a decorator, the system automatically:
- Identifies the correct artwork variant based on the order's specifications
- Retrieves the file from storage
- Packages it alongside the order details
- Transmits it to the decorator's system (via API or the E1 Decorator Portal)
Getting this right required close collaboration with the product team to define the artwork tagging schema — a small design decision that had a huge impact on how reliably files were matched at scale.
5. Store Replication & Settings Exporter
E1OD allows users to clone an entire store configuration — products, logo placements, pricing rules, decoration options — into a new store in minutes. I built a deep-copy system that serializes a store's full configuration tree and re-instantiates it under a new store entity, handling relationship remapping carefully to avoid data bleed between stores.
A related feature — the Settings Exporter — lets users export their store configuration as a portable snapshot, which can be imported into another environment or used as a template for demo stores.
6. Admin Dashboard Backend
The admin dashboard gives the E1OD team visibility into every store, order, supplier, and decorator on the platform. I built the backend APIs that power it — including reporting endpoints, filtering and pagination for large datasets, and audit logs for key actions.
Performance mattered here. Some queries span across hundreds of stores and thousands of orders. I optimized the most expensive queries using eager loading, indexed columns, and in some cases pre-aggregated reporting tables updated by background jobs.
The Hardest Part: Real-Time Data Across a Distributed System
If I had to name the single hardest technical challenge of this project, it was keeping data consistent and up-to-date across a distributed system — supplier APIs, the storefront, the admin panel, the decorator portal — all needing to reflect the same reality at the same time.
Early on, we had race conditions where an order would be routed before inventory confirmed availability, leading to over-selling. We also had cases where artwork transmission would fail silently if the decorator's system was temporarily unavailable.
Over time, I addressed these with:
- Idempotent job design — every background job was written to be safely retried without side effects
- Database-level locking on inventory deductions to prevent oversell race conditions
- Dead letter queues for failed transmissions, with automatic retry and alerting
- Event sourcing for order state — rather than updating a single status field, we logged every state transition as an immutable event, making it easy to audit and replay
These weren't glamorous features, but they're what made the platform reliable at scale.
What I Learned
Building E1OD from scratch taught me a lot about what "production-ready" actually means. It's not just about writing code that works in isolation — it's about building systems that hold up when a supplier's API goes down at 2am, when a customer places 500 orders simultaneously, or when a new decorator needs to be onboarded in a hurry.
A few things I'd take with me into any future project:
- Design for failure early. Assume every external API will fail at some point. Build retry logic, fallbacks, and alerting from day one — not as an afterthought.
- Your data model is your most important decision. The schema choices I made in early 2023 shaped everything that came after. Getting those relationships right upfront saved us from expensive migrations later.
- Queues are not optional for SaaS. Any operation that touches an external system belongs in a queue. Keeping the main request cycle fast and delegating heavy lifting to background workers is the difference between a responsive platform and a frustrating one.
Conclusion
E1OD is one of the most technically interesting projects I've worked on — not because of any single flashy feature, but because of the complexity of getting all the pieces to work together reliably. From order routing to real-time inventory to artwork transmission, every part of the backend had to be designed with automation, accuracy, and resilience in mind.
If you're building a SaaS platform with complex integrations and want to talk through the architecture, feel free to get in touch.