Choosing the Vendor Who Could Actually Move at Retail Speed
Tractor Supply was selecting a vendor to build its consumer-facing mobile app. I advised the leadership team through the selection process, drawing on my technology background to evaluate what each vendor was actually proposing, not just what they were presenting.
Several of the vendors came in with a traditional, non-iterative delivery model: define the full scope up front, build to that spec, deliver at the end. On paper that looks orderly. In practice, for a retail app, it is a liability. Retail moves on promotions, seasonal changes, and shifting customer expectations that do not wait for a long build cycle to finish. A non-iterative vendor treats every one of those changes as a deviation from the original spec, which means change orders, added cost, and delay, exactly when the business needs to move fastest.
There was a related tension inside the company itself. IT’s instinct was to plan around a quarterly release schedule, which fit a more traditional, controlled way of shipping software. But consumer expectations for a retail app do not run on a quarterly clock. In my experience, a monthly release cadence is what keeps users engaged and the app feeling current, rather than stale between updates.
I flagged both issues to leadership during vendor evaluation: that the non-iterative vendors carried real financial and timeline risk disguised as structure, and that an internal release cadence built for quarterly delivery would not serve a consumer app well regardless of which vendor was chosen.
Leadership selected the vendor with an agile, iterative delivery model instead. Had they gone the other direction, the likely outcome was a slower rollout, mounting change-order costs every time the business needed the app to adapt, or, in the worst case, the project losing momentum and getting shelved before it delivered anything.