How do you forecast a new store's revenue when the brief changes twice before the model ships?
A large retail chain closed 21% of its new stores in 2025 as unprofitable, with another 16% running at a loss, while store-opening decisions were still made by expert judgment alone. Azati built a two-circuit ML calculator, a revenue regression model plus a weak-store classifier, that gives development managers a data-backed number before they sign a lease.
WAPE on the holdout fold for the new-store revenue prediction model
weak-store recall achieved while protecting strong stores from false flags
from kickoff to a working two-circuit calculator, covering two scope changes
The client is a large grocery retail chain built around a health-focused private label, growing by opening stores where people already want what it sells. That growth runs on real estate decisions made months in advance, and until this project, those decisions were judgment calls, not numbers.
The stakes are real: the client is opening 50 to 100 new stores across its core metro region this year, and in 2025, 21% of new locations closed as unprofitable, with another 16% running at a loss. Timing made it worse. Nearby residential developments used to fill up in a year; now it takes 1.5 to 2 years, dragging out how long a new store takes to ramp to full revenue.
Revenue and average check are continuous quantities, not categories, which decided the data science approach from day one: a family of regressors, not a lookup table or hardcoded thresholds. The brief was a 10-week proof of concept, a model predicting average monthly revenue for a new full-format store, giving development managers a number before they sign a lease instead of a gut call.
The client had never tracked the accuracy of its own expert-judgment process. That's not a data-quality problem, it's the absence of a scoreboard: there was no "better than X%" to beat, only a first attempt at putting a number on something that had always been a judgment call.
Ten weeks to prepare, analyze, and model roughly 3.8GB of geolocation predictor data, then wrap it in a usable tool, not just a notebook with a final metric in it.
The task the client described at kickoff and the task Azati delivered at the end were, honestly, two different projects. Midway through, the client's priority shifted from a pure revenue estimate toward a more direct question, is this specific location going to be a problem, which meant designing and training a second model on a fundamentally different objective without restarting the engagement from zero.
All of the client's platforms sit behind a closed internal perimeter. Every credential, every data access point, had to come through the client, which adds coordination overhead that a purely external, self-service environment wouldn't have.
Revenue isn't a category, it's a number on a continuum, and average check behaves the same way. That framing, obvious in hindsight, is what kept the machine learning approach grounded in XGBoost and LightGBM regressors rather than a classification shortcut that would have thrown away information the client actually needed.
The client specifically required the project be built with Claude Code. Given the timeline, the data volume, and a scope that changed twice mid-flight, that requirement turned out to be load-bearing: one engineer covered ground that would normally need a small team, because the agent handled iteration speed that a solo developer typing every line by hand couldn't match.
Building a second, independent circuit, the weak-store classifier, on top of the first rather than discarding the revenue model and starting over is what kept the 10-week timeline intact after the client's second pivot. Both circuits now ship together in the same calculator.
We've shipped ML systems where the brief changed mid-project more than once. Tell us where your requirements are still settling, and we'll tell you honestly whether that's a problem or just Tuesday.
Ask us how we handle shifting requirementsA two-circuit web calculator, backed by PostgreSQL for storing predictions and forecast points, built to answer two different questions that both matter before the client signs a lease.
Given only three inputs, map coordinates, store area, and which internal store cluster the location belongs to, the model returns a predicted average monthly revenue along with a quartile interval (q20 to q80), so the output is a range a manager can reason about, not a single number presented as certainty it doesn't have.
A two-head classifier trained on the client's later priority: flag locations at real risk of underperforming, with a probability score and a staircase decision rule behind the flag rather than a flat yes/no.
Every forecast comes with its own top-15 predictors and their contribution to that specific prediction, so a development manager isn't just handed a number, they can see what's actually driving it for that location.
A Flask and Gunicorn-served calculator in a cloud environment, with every prediction and its inputs saved to a managed PostgreSQL database, so results accumulate into a usable history rather than disappearing after each query.
| Area | Delivery | Outcome |
|---|---|---|
| Revenue prediction | XGBoost/LightGBM regression ensemble taking only coordinates, area, and store cluster as input | 30.1% WAPE on the holdout fold, the first accuracy number this client has ever had for store-opening decisions |
| Weak-store detection | Two-head classifier with a staircase decision rule flagging at-risk locations | 69.7% of weak stores caught while 82.8% of strong stores are correctly left unflagged |
| Forecast transparency | SHAP-based breakdown of the top 15 predictors behind every individual forecast | Development managers see why a location scored the way it did, not just the score |
| Delivery speed | One ML engineer, Claude Code as a development agent, two full scope changes absorbed mid-project | 10 weeks from kickoff to a working two-circuit calculator, no timeline slip |
| Deployment | Flask/Gunicorn calculator in a cloud environment with PostgreSQL-backed result storage | A persistent, queryable history of every forecast run, not a one-off notebook output |
| Business validation | 3-month test period comparing calculator-assisted decisions against prior practice | First real business-impact numbers expected once the test period closes |
All of the client's platforms operate behind a closed internal perimeter. Every credential and data access point used during the engagement was provisioned directly by the client, and the deployed calculator runs entirely on cloud infrastructure within that same environment.
One ML engineer owned this project end to end, from data preparation through both modeling circuits to the deployed calculator. That's not a footnote, it's the point: a 10-week timeline with two scope changes usually means a bigger team, and here it didn't.
The team worked in short, Agile cycles against a moving brief, delivering both modeling circuits and the calculator within the original 10-week window despite the client's requirements shifting twice.
The client is currently collecting statistics comparing store-opening decisions made with the calculator against the prior expert-judgment process. This is where the first real business-impact numbers will come from, since no accuracy baseline existed before this project.
The revenue model's holdout accuracy is a real number, but The client never measured the accuracy of its own manual forecasting process before this project. This is a first baseline, not an improvement over a known figure, and we're not going to pretend otherwise.
The weak-store classifier catches most underperforming locations while still protecting the large majority of strong ones from being incorrectly flagged. That trade-off is a design decision, not an accident, and it's tunable if the client's risk tolerance shifts.
The client's own words: the qualitative business result will be clear after the 3-month test period. We'd rather say that plainly than dress up a PoC's technical metrics as a business outcome that hasn't happened yet.
What this project actually taught the team:
The task at the start of this project and the task at the end were two different projects. The lesson that stuck wasn't a modeling technique, it was operational: when the brief moves, the architecture has to be built so a second circuit can be added, not so the first one has to be torn down.
This wasn't the first project where Azati used an AI development agent, but it's a clean example of what that actually buys you: not just faster typing, but the ability for one person to hold two live model architectures in their head and ship both inside a deadline that assumed one.
When a client has never measured their own manual process, the first model you ship isn't "better than before," it's the first time "before" gets a number at all. That's worth saying plainly instead of implying an improvement that can't yet be proven.
We'll tell you what's realistic in your timeline, what a first model can honestly claim, and where the scope is likely to move once you start. No baseline, no problem, that's usually where we start too.
Get a straight answer on your PoC| Forecasting priority | Why it matters | When it becomes priority |
|---|---|---|
| Revenue estimate at candidate sites | A single number a manager can hold against a lease decision, with a range attached instead of false precision. | When expansion volume outpaces how many locations a team can evaluate by expert judgment alone. |
| Weak-store risk flagging | Catches locations likely to underperform before capital is committed, not after the store has been open a year. | When the cost of closing an unprofitable store starts showing up in the numbers development managers actually see. |
| Forecast transparency | Managers need to see which factors drove a number, not just the number, or they won't trust it enough to act on it. | When the calculator starts influencing real lease decisions, not just running in parallel with the old process. |
| Deployment inside a closed environment | The model has to run where the client's data already lives, not in a separate tool nobody logs into. | When IT and security review is part of the rollout, not an afterthought. |
If you're the one who has to explain to your team why a forecasting PoC took the shape it did, this FAQ is written for that conversation.
It predicts a new store's average monthly revenue and a quartile interval around that estimate, from three inputs alone: map coordinates, store area, and which internal cluster the location falls into. A second model then flags whether the store is likely to underperform, with a probability score and a staircase decision rule behind it.
Because manual, expert-judgment assessment had no accuracy baseline to check itself against. The client closed 21% of new stores in 2025 as unprofitable and had another 16% running at a loss, while planning to open 50 to 100 more stores the following year. A data-backed number before signing a lease replaces a purely subjective call with something a manager can compare across locations.
The model reaches a WAPE of 31.7% under cross-validation and 30.1% on the holdout fold. There was no existing manual-forecasting baseline to compare it against, since the client had never measured its own expert-judgment accuracy before this project.
The weak-store classifier is a two-head model that flags a location as likely underperforming, catching 69.7% of weak stores while protecting 82.8% of strong ones from being incorrectly flagged. It was built because the client's priority shifted mid-project from a pure revenue number toward a direct answer to a harder question: is this specific location going to be a problem?
Because the timeline was tight, the predictor dataset ran to roughly 3.8GB, and the client changed the project's scope twice during development, effectively turning it into two different projects back to back. Claude Code was the client's explicit requirement for this engagement, and it's what let one engineer absorb both pivots without the timeline slipping.
The client is running a 3-month test period, comparing store-opening decisions made with the calculator against the prior expert-judgment process. That test period is what will produce the first real business-impact numbers; the project team has been honest that no such baseline existed before.
Influencer marketing platform modernization: 5+ applications, ~200K creators & 12K+ advertisers across 18 markets — React Native upgrades, AI-powered campaign analytics, contract workflows, and internationalization delivered alongside feature development without a roadmap freeze.
Azati helped a European online auction marketplace resume active development of its supplier platform while modernizing the underlying architecture.
DIY retail logistics QA: pickup point exclusion testing, delivery reason tracking across 3 backend services, and third-party carrier integration testing.
B2B automotive parts portal engineering: database architecture unblocked via ADR, multi-region order management, and vendor API integrations delivered on a live platform.
Adobe AEM support and full DAM migration for a global beverage enterprise: 10,000+ assets transferred with 100% metadata integrity in under 2 months.
Modernized retail corporate system with optimized warehouse processes and enhanced efficiency.
Last updated
