The Feature I Almost Didn't Build (And Why I'm Glad I Did)

Every loyalty program in the world is quietly adjusting right now. United tweaked PQP (Premier Qualifying Points) thresholds in March. Air Canada's Aeroplan repriced 14 partner routes in a single weekend. I wrote about what that chaos looked like from the inside two posts ago. The pace isn't slowing down.

But here's the thing nobody talks about: devaluations aren't the only way travelers lose value. Sometimes you lose it at the gate. A delayed connection. A missed upgrade window. A rebooking that puts you on a worse aircraft. The miles were fine. The execution failed.

That realization put me at a fork in the road about six weeks ago, and I'm still not 100% sure I chose correctly.

---

The Fork

I had two features queued up. Both were real user requests. Both had clear value. I could only build one well.

Option A: Elite Status Tracker. Multi-program dashboard showing projected qualification dates, how many PQP or EQM (Elite Qualifying Miles) you need, and which flights close the gap fastest. Straightforward. High demand. Every frequent flyer I talked to wanted it.Option B: Delay Predictor. A weighted scoring model that combines historical on-time data, weather forecasts, airport congestion, and aircraft rotation patterns to estimate how likely your specific flight is to be delayed before you even get to the airport.

On paper, Option A was the obvious call. More users asked for it. It's easier to explain. It fits neatly into the "loyalty program intelligence" story I've been telling since day one.

I almost built it first.

Why I Chose the Harder Thing

I kept coming back to a Reddit thread in r/churning from April. Someone posted about missing a connection on a Star Alliance itinerary, getting rebooked onto a non-partner carrier, and losing the upgrade they'd waitlisted for six months. The comments were full of people saying "I knew that first leg was risky" but nobody had a tool that quantified how risky before booking.

That's a different kind of loss than a devaluation. It's not a program changing the rules. It's a traveler making a decision without the information they needed.

I also ran a quick survey to 47 MileIntel users (not a huge sample, I know). The question was simple: "In the last 12 months, did you lose more value from a loyalty program devaluation or from a disrupted itinerary?" 31 said disruption. 16 said devaluation.

That surprised me. I'd been building almost entirely around the devaluation problem.

What Building It Actually Looked Like

I estimated two weeks. It took five.

The historical on-time data was the first wall. The DOT (Department of Transportation) publishes carrier on-time statistics, but they're aggregated at the route level, not the flight number level. Getting to flight-specific history meant pulling from a third-party data provider, which added cost I hadn't budgeted and a rate limit I had to work around with a caching layer I built on week three.

The weather integration was cleaner than I expected, actually. I used the Open-Meteo API for forecast data and wrote a simple severity scoring function: precipitation type, wind speed at origin and destination, visibility. Each factor gets a weight. The weights are not scientific. They're my best guess based on reading through about 200 delay reports and seeing which conditions showed up most often. I'll tune them as I get more data.

The piece that genuinely scared me was the aircraft rotation logic. If your 7am flight is operated by a plane that's flying in from another city the night before, and that flight is delayed, your morning departure is already compromised before the day starts. Modeling that dependency graph without access to real-time fleet tracking data was the hardest engineering problem I've faced on this project.

I ended up with a proxy: I look at the same flight number's performance on the inbound leg for the prior 90 days and weight it at 0.3 in the final score. It's an approximation. It's probably wrong in specific cases. But in backtesting against 1,847 historical flights where I knew the outcome, the model flagged "high delay risk" correctly 71% of the time.

I'll take 71% over nothing.

The Part I'm Still Uncertain About

Here's what I don't know yet: does a delay risk score actually change user behavior?

Knowing your flight has a 68% on-time probability is useful. But what do you do with that? Book a different flight? Add a longer connection buffer? Pack your laptop in your carry-on instead of checked luggage?

I built the score. I haven't built the "so what" layer yet. That's the elite status tracker problem in reverse: the status tracker tells you exactly what action to take (fly these routes, earn these points). The delay predictor tells you something is risky without always giving you a clear next step.

I'm working on a recommendations layer now. If your risk score is above 0.65, MileIntel will surface the next two departure options on the same route, show you the connection buffer on your itinerary, and flag whether your fare class is eligible for same-day changes without fees. That's the version that actually helps.

It's not live yet.

What About the Status Tracker?

It's next. I didn't abandon it. I just needed to be honest with myself about which problem was more urgent given what users were actually telling me.

The status tracker is also, frankly, a more crowded space. AwardWallet does a version of it. So does App in the Air. The delay predictor with flight-specific scoring tied to your actual itinerary is something I haven't seen done well anywhere. That matters when you're a small team trying to find ground worth defending.

If you're tracking progress toward United 1K or Delta Platinum Medallion right now and want to see that dashboard sooner, tell me. Seriously. The more people who say it's urgent, the faster it moves up the queue. You can reach me at aditya@mileintel.com or just reply to any issue of The Mileage Run.

The Honest Version of This Decision

I chose the delay predictor because a Reddit thread and 47 survey responses told me disruption costs travelers more than devaluations do. That's a thin evidence base for a five-week build.

Maybe I got it right. Maybe the status tracker would have driven more signups. I won't know for another month or two when I have enough usage data to compare.

What I do know: the model works better than I expected, it took longer than I planned, and the most important part (the recommendations layer) isn't done yet. That's a pretty accurate summary of most things I've built.

If you've got a flight coming up and want to run it through the predictor, it's free at mileintel.com. I'd genuinely love to know if the risk score matches your gut feeling about the route, or if it surprises you.

And if you've faced a similar build-vs-build decision on your own product: how did you decide? I'm still figuring out a better framework than "survey 47 people and trust your instincts."