Building · 75%
Retail Promo Simulation Lab
A working promo simulation lab for exploring ecommerce discount rules, cart eligibility, checkout revalidation, inventory changes, and edge cases.
Overview
- Status
- Building
- Progress
- 75%
- Difficulty
- Challenging
- Started
- Jul 1, 2026
Stack & tools
Links
01 / MOTIVATION
Why I built this
I started this as a way to understand a complicated promo requirement more clearly. The original ask was related to enhancing ecommerce promo schemes, but the business requirements were still scattered and full of edge cases. Instead of only making a mockup, I wanted something I could actually use to test behavior. If a promo is configured this way, what happens in the cart? What happens at checkout? What if stock changes, the price changes, or the promo expires in the middle of the journey? The goal was not to build a final commerce system. It was to build a small lab where I could reason better and explain the behavior more clearly to business users, product designers, developers, and QA.
02 / QUESTION TO EXPLORE
What I wanted to understand or solve
Promo requirements often look simple when written as campaign names, but the actual behavior can get complicated quickly. A campaign like “buy 2 get 20%, buy 3 get 30%” needs clear decisions around eligible products, tiers, markdown items, checkout method, platform, stock, and what happens when the cart changes. The tricky part is that promo behavior is not isolated. It touches catalog setup, cart selection, checkout method, inventory, payment flow, and order history. A rule that feels correct in admin setup can produce confusing behavior for customers if the progress state, discount breakdown, or error message is unclear. I needed a way to make those rules visible and testable before turning them into implementation tasks.
03 / APPROACH
How I turned the idea into something testable
I built the project as a Next.js prototype with fictional retail data. The app has an admin side for catalog, promo, and store stock setup, and a customer side for PLP, cart, checkout, orders, and calculation logs. The promo engine supports stackable quantity tiers, value-based tiers, and buy-X special price rules. I also added campaign names and terms and conditions so the promo type can stay technical while the customer-facing name remains flexible. The cart became the main testing surface. It can show eligible promo options, progress toward promo tiers, best-promo auto selection, price breakdowns, and validation messages when something changes. I also added temporary simulation flags for edge cases. Instead of permanently mutating the dashboard data, the simulator can pretend that a promo expired, a SKU price changed, stock changed, checkout failed, or a promo could no longer be applied during cart-to-checkout or checkout-to-order validation. Later, I added Supabase persistence so admin edits, promos, stores, stock, and orders can survive refreshes, while keeping the project lightweight enough for a lab.
04 / FIELD NOTES
From Mockup To Behavior
This project came from a moment where I needed more than a visual mockup. The promo requirements had too many conditional branches: quantity tiers, value thresholds, platform eligibility, checkout methods, stock availability, campaign names, and promo validity windows.
A mockup could show what the cart might look like, but it could not answer what happens when the user adds one more item, changes checkout method, or continues after a promo expires. I wanted the rules to be something I could run, not just describe.
Separating Promo Type From Campaign Name
One useful distinction was separating promo type from promo name. The promo type controls the calculation behavior, while the promo name is the campaign label shown to customers.
That made the admin setup clearer. A campaign can be called something natural like “Year End Shopping Promo,” while the rule underneath can still be stackable by quantity, stackable by value, or buy-X special price.
Cart As The Thinking Surface
The cart became the most important screen in the prototype. It shows what promo is available, why a promo is not active yet, what tier the customer has reached, and how much more they need to add to unlock the next benefit.
I also added best-promo auto selection because promo choice can quickly become confusing. Sorting promo cards by customer benefit made the simulator easier to read.
Checkout Revalidation
One of the more important behaviors is revalidation. A promo can be valid when an item enters the cart but invalid by the time the customer reaches checkout. The same thing can happen with price and stock.
The simulator handles this by showing local validation messages in the cart or checkout area. The goal is to make the failure feel like a real customer journey, not a developer-only error.
Inventory And Order Effects
I added basic stock behavior so successful orders reduce current stock. If an order history entry is deleted, the stock is released back. For Click and Collect, store stock is affected; for regular checkout, product variant stock is affected.
This is still a simplified model, but it helps reveal how promo logic and inventory logic can collide.
05 / LEARNING
This project helped me turn scattered requirements into something observable. Instead of debating promo behavior only through words, I could run scenarios and see where the logic became unclear.
I learned that promo systems need careful language as much as careful calculation. A customer-facing message like “promo expired” is not enough if the user does not know what changed, what item is affected, or what they can do next.
I also learned that admin configuration needs guardrails. If every promo rule is shown at once, the dashboard becomes hard to scan. Collapsible sections, focused fields, and tooltips made the setup easier to reason about.
Most importantly, the simulator became a bridge between different roles. Business users can see campaign behavior, designers can see journey states, developers can inspect rule logic, and QA can think through edge cases.
LET'S TALK
Something worth talking about?
Product, systems, something you're building, or just an idea worth comparing notes on—feel free to reach out.