Dynamic Pricing Optimization Engine
The client was an online retailer operating roughly twelve thousand SKUs across home goods and apparel on Shopify. Pricing was set weekly by a small merchandising team using a spreadsheet that combined gross-margin floors, competitor benchmarks, and gut feel. The result was meaningfully under-optimized — stockouts on top-performing SKUs at full price, deep markdowns on slow movers that already had thin margin, and no responsiveness to competitor moves between Monday refreshes.
Trading, FinTech & Analytics
Retail/E-commerce
12 weeks from kickoff to full SKU base under management
4 specialists
The full story
The practical problem was that the merchandising team did not have time to act on the data they had. Competitor pricing was scraped daily but reviewed weekly. Stock levels were visible per SKU but not connected to pricing decisions. Demand signals from on-site behavior — view-to-cart ratios, cart abandonment by SKU — existed in the analytics tool but never flowed into pricing. The team was three people and could not run a daily pricing pass at the SKU count required.
We built a dynamic pricing engine that combined demand signals, competitive position, and stock level into a price proposal per SKU on a two-hour refresh cycle. The engine respected margin floors and brand-pricing rules set by the merchandising team, exposed the rationale per price change for review and override, and applied a velocity constraint so prices did not jump in ways that would surprise repeat customers. Markdown logic was unified with regular-price logic in the same engine, so slow movers were handled in a single framework.
What shipped was a pricing workstation where the merchandising team set rules and floors once, reviewed proposed changes hourly during the day, and accepted them in bulk or per SKU. Margin moved up while revenue grew, the team stopped running weekly pricing meetings, and the platform’s price refresh cycle dropped from weekly to two hours without expanding headcount.
Weekly pricing meetings could not handle twelve thousand SKUs, and the data the team needed was scattered across three tools.
Competitive scrape data was collected daily and reviewed weekly, so competitor price moves caught the retailer off-guard for days.
Stockouts on top SKUs at full price represented direct lost margin that demand-aware pricing would have captured.
Markdown decisions on slow movers were rule-based and aggressive, often discounting margin that smaller markdowns would have preserved.
On-site demand signals existed in analytics but were not used in pricing, so view-to-cart and cart-abandon data went unrealized.
A three-person merchandising team could not run daily pricing on twelve thousand SKUs even with perfect data access.
How we structured the engagement
Built one engine that handled regular pricing and markdowns together, respecting human-set floors and brand rules.
- 01Phase 01Weeks 1-2
Discovery
Reviewed six months of pricing changes and outcomes by SKU category. Worked with merchandising on the floors, rules, and constraints that had to be preserved. Output: a per-SKU feature set, a constraint schema for floors and brand rules, and a refresh cadence of two hours plus a velocity-limit rule on per-day price moves.
- 02Phase 02Weeks 3-4
Architecture
Designed a pricing engine combining demand signals, competitive scrape data, and inventory levels under merchandising-set constraints. Built a price proposal generator with rationale per SKU and a bulk-review interface. Used Shopify API for price commits and a per-SKU change log for audit and rollback.
- 03Phase 03Weeks 5-9
Build
Shipped the feature pipeline first because the engine depended on clean inputs. Built the pricing engine and the proposal generator. Implemented the bulk-review interface with rationale visible per proposal and a one-click override. Wired the Shopify commit path with a per-SKU history log for audit and quick rollback if needed.
- 04Phase 04Weeks 10-12
Launch
Rolled out to a five-hundred-SKU pilot for three weeks with daily margin review, expanded to two thousand SKUs in week eleven once the proposal acceptance rate held above eighty percent, and reached full twelve-thousand-SKU coverage in week thirteen. Tuned velocity limits per category based on early surprise complaints from repeat customers.
What we built, component by component
- 01
Feature pipeline
Combines demand signals, competitive scrape data, and inventory levels into per-SKU feature vectors refreshed continuously.
- 02
Constraint layer
Enforces margin floors, brand-pricing rules, and velocity limits set by merchandising before any price proposal is generated.
- 03
Pricing engine
Combines demand, competition, and inventory into a price proposal per SKU on a two-hour refresh, with rationale per change.
- 04
Markdown logic
Unified into the pricing engine so slow movers and regular SKUs follow the same constraint and rationale framework.
- 05
Review interface
Bulk-review workstation for merchandising with rationale visible per proposal, one-click override, and history per SKU.
- 06
Shopify connector
Commits accepted prices to Shopify with a per-SKU history log for audit and one-click rollback if a change underperforms.
The feature pipeline refreshes per-SKU vectors continuously from demand, competitive, and inventory inputs. The pricing engine generates proposals on a two-hour cadence within constraint-layer floors and velocity rules. The review interface surfaces proposals with rationale, merchandising approves in bulk or per SKU, and the Shopify connector commits with audit history maintained for rollback.
The trade-offs we made and why
Unified markdown and regular pricing in one engine
Treating markdowns as a separate system would have produced inconsistent decisions on borderline SKUs and forced merchandising to keep two mental models. One engine with one constraint framework gave clean decisions across the SKU base and made the team’s mental model simpler.
Added velocity limits per category
Repeat customers noticed sudden price jumps and complained, even when the new price was justified. Velocity limits per category capped per-day moves and let prices reach their target over a couple of cycles instead of in one jump, which preserved customer experience without giving up the optimization.
Two-hour refresh, not real-time
Real-time repricing would have produced erratic customer experience and contributed nothing to margin given the demand-signal latency. Two-hour cycles matched the rate at which demand signals actually moved and gave merchandising a reviewable cadence without overwhelming the team.
Exposed rationale per proposed change
Bulk-approve without rationale would have made merchandising into rubber-stampers and erased their oversight. Showing rationale per change kept their judgment in the loop and gave them a way to spot bad model decisions before commit, which built trust faster than accuracy claims would have.
What changed for the client
margin uplift
Gross margin lift on the pilot SKU cohort across the first eight weeks after rollout completed, versus the prior pricing baseline.
monthly revenue
Month-over-month revenue growth sustained through the first full quarter of full-coverage operation across all SKUs.
refresh cycle
Replacement for the prior weekly cadence, with proposals generated every two hours and reviewed by merchandising in batches.
SKUs under management
Full SKU base under continuous pricing optimization at full rollout, up from the prior weekly manual coverage of a few hundred SKUs.
The tools behind the system
Built with a deliberate stack chosen for production reliability and operational velocity.
Lessons learned from the build
Unifying markdowns and regular pricing into one engine was the design choice that kept the system coherent. We sketched a two-engine approach in the first week and dropped it within a few days because the borderline cases would have been a constant source of friction. One framework, one constraint set, every SKU.
Velocity limits looked like a small feature and turned out to drive customer-experience outcomes meaningfully. Without them, the system would have produced margin gains and customer complaints in equal measure. We would build velocity limits into any consumer-facing pricing system from day one.
Rationale exposure was the trust feature merchandising needed. Once they could see why the engine proposed a change, they accepted proposals faster and overrode fewer of them. Hiding rationale would have produced the opposite cycle of skepticism and override fatigue.
Similar delivery work usually starts in these service areas
If you are exploring a similar product, workflow, or implementation challenge, these are the service tracks that usually fit best.
Where this project sits in the bigger market picture
AI use cases for retail, commerce, personalization, pricing, and customer support.
Build a result-driven AI product with a team that has shipped before
If you are exploring a similar product, workflow, or AI use case, we can help scope the right architecture, delivery model, and first milestone.
Related case studies worth reviewing next
Have an AI idea, messy workflow, or product vision? Let's make it buildable.
Bring the problem. We'll help shape the product, define the architecture, and show the fastest path to a serious first version.
A practical first roadmap in the discovery call
Architecture, timeline, and delivery options in plain English
Security, scalability, and reliability discussed upfront
Model registry
softus-rag-v4.2
187ms
Latency
128k
Context
$0.004
Cost / req
Evaluation suite
Deploy pipeline
prod / canary 25% — healthy