Every growing ecommerce business hits the same wall. Prices that were checked and adjusted by hand once a week now need adjusting daily, across hundreds or thousands of products, against competitors who already move automatically.
At that point most teams agree they need automated repricing. The argument starts on the next question: write our own, or pay for a tool?
Both answers can be right. Which one is right for you depends on what repricing actually involves under the surface, and on being honest about what your team will still be maintaining two years from now.
What an automated repricer actually does
The rules engine everyone imagines building is the small part. A working repricer is a chain of four jobs, and the chain is only as good as its weakest link:
- Collect. Gather competitor prices, stock status and shipping costs from websites and marketplaces, on a schedule, reliably.
- Match. Decide which competitor listing corresponds to which of your products, including where titles differ, identifiers are missing, or sellers list bundles.
- Decide. Apply your strategy: match the cheapest relevant rival, hold a distance from a specific competitor, or raise the price when rivals go out of stock.
- Apply safely. Push the new price to your store inside hard limits, with a record of what changed, when and why.
Teams that only picture the third job routinely underestimate the other three. That misjudgement is where most in-house repricers die.
The case for building
Building your own makes sense when repricing logic is genuinely part of how you compete, and generic rules cannot express it.
A business with unusual constraints qualifies: pricing driven by perishable stock, complex bundle economics, contractual pricing per customer group, or a category where your own data science already outperforms off-the-shelf strategies.
It also assumes some things that are easy to claim and hard to sustain: engineers with time to own the system permanently, a reliable source of competitor data, and someone accountable for price quality rather than just uptime.
If you go this route, two pieces of advice from teams that have done it.
First, treat it as a product, not a script. Scope a first version that does one strategy well, with hard price floors from day one.
An experienced MVP development company can get that first version working and structured so your own team can take it over cleanly.
Second, budget for the part everyone forgets. Websites change their markup, marketplaces rotate their layouts, and sellers relist products under new titles. The collection and matching layers are never finished, and their maintenance lands on your roadmap every quarter.
Where in-house repricers break
Three failures account for most abandoned builds.
Collection gets harder over time, not easier. Sites change their markup, add protection, or show different prices by region and visitor. A pipeline that worked at launch quietly degrades, and stale data flows into live rules.
Matching is the deceptive one. Comparing your product with the wrong listing, a different pack size, an older model, a used unit, produces prices that are confidently wrong. Catching that takes verification work most teams never planned for.
And ownership fades. The engineer who built it moves on, the scripts become the system nobody wants to touch, and pricing, the most commercially sensitive automation in the company, ends up running on unmaintained code.
The case for buying
Dedicated automated repricing platforms exist because the first two jobs, collecting and matching, are the same brutal problem for every seller, and solving it once for many customers is cheaper than every business solving it alone.
A mature tool arrives with the data pipeline already running: competitor sites and marketplaces monitored, products matched and verified, and repricing rules applied inside floors and ceilings you set, either fully automatically or with each change waiting for approval.
The trade-off is flexibility at the edges. Most platforms, Altosight included, cover the strategies the large majority of retailers actually run: match or beat chosen competitors, protect margin with floors built from cost, and lift prices when rivals run dry.
If your strategy fits that space, buying means having it live in days rather than quarters.
The honest limitation: if your pricing depends on logic no vendor supports, configuration will not save you, and you are back to building at least a layer of your own.
What each path really costs
Comparing a subscription price with an engineering estimate flatters the build. The real comparison is between totals over a couple of years.
- Build. The first working version is the cheap part. Add the permanent share of an engineer for collection and matching upkeep, infrastructure and proxies, and the opportunity cost of what that engineer would otherwise ship.
- Buy. The subscription, the onboarding effort, and the discipline to actually configure floors and review cycles rather than trusting defaults.
There is also a risk cost on each side. A homegrown system fails quietly: a broken scraper feeds stale prices to a live rules engine. A bought tool fails commercially: if the vendor matches products badly, you inherit their mistakes at full speed.
Either way, the failure you cannot afford is a price below cost reaching customers, which is why the guardrails matter more than the strategy.
Rules that apply whichever way you go
- Every product gets a floor built from its cost and the margin you need, and nothing may price below it.
- Ceilings catch the opposite mistake: a rule chasing a rival’s error upwards, or reacting to a stock-out too aggressively.
- New rules run in review mode first, suggesting changes for a person to approve, and go automatic only once trusted.
- Every change is recorded with its trigger, so pricing decisions can be audited and improved rather than guessed at.
- Ignore outlier prices far below the market; they are usually errors or grey-market sellers, not signals.
A short decision test
Answer these five questions honestly:
- Is our pricing logic genuinely unusual, or do we mostly match, beat and protect margin like everyone else?
- Do we have engineers who can own data collection and product matching permanently, not just build it once?
- How fast do we need this live: days, or quarters?
- Can we quantify what a week of wrong prices would cost us?
- If the person who built it leaves, does the system survive?
Most retailers who run the test end up buying, because their edge is in buying, merchandising and service rather than in price-data engineering. The build path is the right call for the minority whose pricing logic is the product.
Whichever side you land on, the deadline is the same. Your competitors’ prices are already moving automatically, and a catalogue repriced by hand is competing at a different speed than its market
