Dynamic repricing against competitors

Dynamic repricing against competitors is a recurring operational process run by a two-person ops team and the founder several times a week. The team manually checks competitor prices across relevant products, compares those prices against their own current Shopify listings and a set of margin guardrails, and decides whether to adjust prices upward or downward within the allowed boundaries. Once a decision is made, prices are updated directly in Shopify. Any cases that fall outside the standard rules, roughly a quarter of all runs, are handled separately through a mix of judgement calls, email and spreadsheets.

The process runs approximately 260 times a year and takes around 90 minutes per run, adding up to roughly 390 hours of manual effort annually. The core logic is largely deterministic: if a competitor price moves and the corresponding adjustment keeps the product within defined margin floors and ceilings, the update should happen. The complication is that a meaningful share of cases involve ambiguity, data quality issues or conflicts between margin rules and competitive positioning, all of which currently land back on the ops team to resolve by hand.

The founder has already built custom scripts and integrations on top of Shopify, and the Shopify Admin API is fully available. The internal pricing rules exist but are only partially documented, which means some of the logic currently lives in people's heads rather than in any system. That gap is the main thing that needs closing before any automation can be built reliably.

The recommended path is Traditional Code, specifically a lightweight Python service that polls competitor price data on a schedule, applies the documented margin rules as a decision function, and calls the Shopify Admin API to update prices for routine cases automatically. This is the right call because the repricing logic is fundamentally deterministic. There is no ambiguity that requires inference, no unstructured language to interpret, and no need for a model to make judgement calls. The rules either permit an adjustment or they do not, and that is exactly the kind of logic that belongs in clean, testable code rather than an AI system.

The recommendation fits the client's preferred stack directly. The founder already writes custom scripts, has built Shopify integrations before, and is comfortable working at this level of technical depth. There is no new platform to procure, no vendor dependency to manage, and no licensing cost beyond whatever data feed is needed for competitor prices. The entire solution can be built, tested and owned in-house, which matters for a two-person ops team that needs to maintain and adjust the rules as business strategy evolves. That alignment between the recommended approach and the existing tooling is not a coincidence: it is one of the reasons Traditional Code scores so strongly here.

Hybrid was also assessed and scores reasonably well, but it is not a meaningfully distinct path in this case. The exception routing that defines a hybrid approach is already built into the Traditional Code solution by design: standard cases are automated, non-standard cases are written to a review queue for the ops team. Calling it a separate path would be misleading. The hybrid label is more useful when the automation layer and the human review layer come from different systems or vendors; here they are part of the same build.

RPA was considered and is technically capable of scraping competitor prices and updating Shopify, but it is the wrong tool when an API is available and the team can code. RPA adds fragility because it depends on screen layouts staying consistent, it introduces licensing cost, and it offers no advantage over a direct API integration in this context. An AI Workflow or AI Agent scores even lower for the same fundamental reason: the rules are explicit, so adding an inference layer creates unpredictability and cost without solving any problem that the rules engine does not already handle cleanly. In a pricing context where margin violations have direct financial consequences, unpredictability is a liability, not a feature.

The honest tradeoff to acknowledge is that the 25% exception tail will not disappear. The automation handles the routine majority and makes the exception cases faster to process by surfacing them with context, but it does not eliminate the need for human judgement on edge cases. That is appropriate. The goal is not to automate everything; it is to remove the repetitive majority from the ops team's plate and make the genuinely difficult decisions easier to act on. A payback period measured in weeks, not months, makes the case for building this straightforwardly.

Traditional Code is the clear winner here, and the reason is simple: the repricing logic is already deterministic. Margin floors exist, guardrails are defined, and the Shopify API is open. When a process has explicit rules and a clean API endpoint to write to, introducing an AI layer is not sophistication, it is unnecessary complexity. The routine 75% of cases follow a compare-and-update pattern that a Python service can execute reliably, cheaply, and auditably without any inference or language understanding involved.

The Hybrid path scored second and is worth addressing directly, because on the surface it sounds like a different recommendation. It is not. The traditional code solution already routes exceptions to a human review queue by design, which means the hybrid approach is effectively built into the recommended path rather than sitting alongside it as an alternative. Calling it out separately would overstate the architectural decision involved.

RPA is the only other path that could plausibly work, but it would be the wrong tool given what the team already has. RPA earns its place when there is no API and a human has to navigate a UI to interact with a system. Here, Shopify exposes a well-documented Admin API and the founder already writes scripts against it. Choosing RPA over a direct API integration would mean accepting browser-based fragility, licensing costs, and a maintenance burden that a clean Python service simply does not carry. The founder's existing capability makes Traditional Code not just the best path in theory but the most practical one to actually deliver and own.

The foundation of everything is rule documentation, and it needs to happen before a single line of code is written. The founder and ops team should sit down and write out every margin floor, ceiling price, and escalation condition as explicit if-then logic. This exercise almost always surfaces edge cases that have been living in someone's head rather than in any document, and those gaps are exactly what cause automated systems to make bad decisions on live prices. The output should be a signed-off rules document that the code will faithfully implement, not interpret.

With the rules documented, the next build is competitor price feed ingestion. Depending on where competitor prices currently come from, this is either a scraper targeting retailer product pages, a call to a third-party price intelligence service such as Prisync or Skuuudle, or a lightweight crawler that normalises raw HTML into structured records. The result is a scheduled Python service, likely running on a small cloud instance or a tool like GitHub Actions on a cron schedule, that fetches competitor prices, cleans the data, and writes normalised records to a simple database or flat file that the repricing engine can read from. The founder's existing scripting capability makes this the most straightforward part of the build.

The repricing engine itself is a decision function that takes a competitor price, looks up the current Shopify price and the applicable margin bounds from the rules document, and either calls the Shopify Admin API to update the price or writes a record to an exception queue. Every action the engine takes should be logged to a persistent store, whether that is a Postgres table, a SQLite file, or even a structured CSV, so that every automated price change is fully auditable. The Shopify Admin API's product variant endpoint handles price updates cleanly, and the founder will already be familiar with its authentication model from previous integrations.

The exception queue needs a review surface that the ops team will actually use. This does not need to be a custom web application. A formatted Slack message that presents the relevant context, the competitor price, the current price, the margin position, and why the case was escalated, gives the ops team everything they need to make a quick decision. If the team prefers email, a digest can be sent at a fixed time each day. The goal is to compress the time spent on the 25% of non-standard cases rather than to eliminate them, and a well-formatted notification does that without requiring a separate tool to be built and maintained. Once the queue surface is in place, the final step is a shadow-mode period of one to two weeks where the engine runs alongside the manual process and its decisions are compared against what the team would have done. That comparison catches rule gaps, data quality issues, and threshold mismatches before any automated change touches a live price.