Why Your State Isn't Live Yet (And Why That's Actually Good News)

By Doug Moeller | Professional Gambler & Founder of Savvy Scratch

I get some version of this question constantly:

“When are you adding my state?”

And I get it.

You’re tired of walking into a store blind. You see players in live Savvy Scratch states getting real data on which games still have life in them, and you want the same thing where you play.

That makes sense.

But here’s the part I’m not going to sugarcoat: if I rush your state live just so I can say it’s done, you don’t get a win. You get bad data. And bad data is worse than no data, because now you’re making bad decisions with confidence.

That is the exact opposite of what this product is supposed to do.

I’ve won over half a million dollars across poker, blackjack card counting, and casino advantage play, and one lesson follows you everywhere in gambling: fast bad information is a disaster. Good information, even if it takes longer, is where the real edge starts.

That’s what’s going on here.

If you’re already in a live Savvy Scratch state and want to see which games are actually worth your attention right now, sign up here.

Every State Is Its Own Mess

There is no clean national lottery feed I can just plug into and call it a day.

Every state does this differently.

Some states have decent tables. Some bury the data in weird JavaScript. Some scatter it across PDFs that look like they were designed to punish anyone trying to read them. Some are missing fields you would assume are basic. Some have totals that do not match. Some update on a schedule that feels more like a mood than a process.

That’s the reality.

So when people hear “add my state,” what they picture is flipping a switch.

What it actually means is building a custom data pipeline for that state’s particular brand of chaos.

That’s also why the “just launch it and fix it later” mindset makes no sense here. This is not a toy. This is not a gimmick. If the data is wrong, the conclusions are wrong. And when the conclusions are wrong, you’re not helping players play smarter. You’re helping them make worse picks faster.

If you want the bigger mindset behind that, Why a Winning Gambler’s Playbook Works for Scratch-Offs is the cleanest companion post.

Step One: Make Sure the Data Is Even Worth Building Around

This is where a lot of states fail before they even start.

The first question is simple: does the state publish enough usable information to support real analysis?

I need to know what prizes are left, not just what the game launched with. I need actual prize amounts, counts by tier, ticket price, odds, and some kind of confidence that the source is updated often enough to matter.

If the state does not give me that, the whole thing gets shaky fast.

And shaky data is useless.

Actually, it’s worse than useless. It tricks you into thinking you know something when you really don’t.

That’s why Why Top Prizes Are the Only Thing That Actually Matters in Scratch-Offs fits naturally here. If the source can’t reliably tell you what’s still alive at the top end, then the whole point of the tool starts falling apart.

Then Everything Has To Be Mapped Into One Real System

Even when the data exists, it usually doesn’t come in a clean format.

Every state has its own naming conventions, game identifiers, prize layouts, date formats, and weird inconsistencies. So before anything ever shows up inside Savvy Scratch, all of that has to be translated into one standardized structure that the app can actually trust.

That sounds boring, but it matters.

Because this is where a lot of invisible bugs are born.

If one state calls something “Top Prize,” another calls it “Prize Level 1,” and a third mixes labels halfway through the report, you need rules for all of it. If a game disappears and comes back, if a game changes names, if totals mismatch, if prize tables don’t line up, all of that has to be handled before the data can be trusted.

Users never see most of this work.

They only see the outcome.

Which is exactly how it should be.

Then I Have To Build the Collector Like It’s Going To Get Punched in the Face

Because it is.

Lottery sites change. Layouts move. Pages half-load. Fields disappear. Reports publish late. Categories split for no obvious reason. Sometimes the data source doesn’t fully break, which would be nice and obvious. Sometimes it “kind of works,” which is worse, because that’s how bad data quietly slips through.

So the collector has to do more than just pull the data when everything is going right.

It has to survive when things go wrong.

That means retries, backoff, timeouts, failure detection, missing-data checks, and enough guardrails to tell the difference between “the state had no update today” and “something is broken and the output can’t be trusted.”

That is the difference between a quick scraper and a real production system.

And honestly, this ties right into Lottery Data: How to Use Numbers to Spot Scratch-Offs Worth Buying, because that post is really about the front-end value of what this back-end work is trying to protect.

Raw Lottery Data Is Ugly

Always.

Dollar amounts show up in different formats. Fields come in blank. Prize tiers duplicate. Counts are off. Values get written in ways that make sense to a state website and no one else.

So then it has to be cleaned.

Normalization sounds like some boring backend word, but all it really means is taking messy source material and turning it into something consistent enough that you won’t see nonsense once it reaches the app.

If that step gets rushed, you get garbage.

And garbage data doesn’t just look ugly. It leads players to the wrong game.

That’s why I’d still rather someone buy blind than buy off broken numbers pretending to be smart numbers. At least blind buying is honest about what it is.

Then the Math Has To Be Verified, Not Just Assumed

This part matters a lot.

Even if the source looks good and the cleaned data looks good, that still doesn’t mean the final calculations are right.

I have to manually cross-check sample games against the official source, make sure totals reconcile, and make sure the same input keeps producing the same output every time.

Because if the app says one game is stronger than another and that conclusion is wrong, that is not a small bug.

That is the product failing at the exact thing it exists to do.

If you want to see the user-facing version of why this matters, Scratch-Off Tickets With the Best Odds: A Practical, Data-Driven Guide (and How Savvy Scratch Helps You Find Them) is a natural companion here.

Then It Has To Run for Weeks

This is the part most people never expect.

They think if the state worked yesterday, it’s good to go.

No.

I need to see it run under real conditions for a while.

Not one clean day. Not one good pull. Weeks.

Because the goal is not just “it worked once.” The goal is “it keeps working, it handles weirdness, it catches silent failures, and it doesn’t drift into quietly wrong output while nobody notices.”

That’s what durability looks like in a system like this.

And yes, it takes time.

But this is exactly why “a few weeks” is not delay for the sake of delay. It’s proof. It’s the difference between a fragile launch and one you can actually trust.

That’s also one reason The Hidden Mistakes Most Lottery Players Don’t Even Realize They’re Making fits here better than people might think. Bad data would just create another invisible mistake layer on top of the ones players already have.

Then It Still Has To Feel Good in the Product

Even once the data is solid, the work is not done.

Now it has to live inside the product properly.

That means routing, catalogs, sorting, filters, caching, weird edge cases, app behavior, mobile behavior, and all the little details that make the difference between “the data exists” and “this actually feels usable.”

Because nobody wants a mathematically correct product that feels clunky and half-broken.

Trust is not just about accuracy. It’s also about smoothness.

If the product feels unreliable, users will treat it as unreliable even if the data is technically fine.

That matters a lot in this niche.

This Is Why I’d Rather Be Late Than Wrong

That’s really the whole philosophy.

I would much rather have someone annoyed that their state is not live yet than have them use bad data and waste money because I rushed it.

At $5 a month, the whole point of Savvy Scratch is that it should help you avoid bad buys and make cleaner picks. But that only works if the underlying information is right.

One bad rushed launch does more damage than waiting.

That’s how trust works.

And when you’re talking about lottery players making decisions with actual money, trust is the whole game.

What It Means When a State Finally Goes Live

When you see a new state show up in Savvy Scratch, what you are really seeing is not a checkbox.

You’re seeing a custom-built, tested, cleaned, validated, monitored system that survived real update cycles and held up long enough that I’m willing to put my name on it.

That’s what you’re waiting for.

Not speed.

Reliability.

And if you’re in a live state already, that same reliability is the reason the tool is worth checking before you buy. Register here.

If Your State Isn’t Live Yet

I am working on it.

But I am not going to pretend that “working on it” means “I can slap it together and hope for the best.”

That is not how I approach gambling, and it is not how I approach this product.

Good data beats fast data. Every time.

If your state is already live, great. Use the tool and stop guessing.

If your state is not live yet, the good news is the same thing that makes the wait annoying: I’m not rushing something that could cost you money if it’s wrong.

And if you want to understand the player side of why this data matters so much, How to Win the Lottery: Play Smarter, Not Harder and Lottery Data: How to Use Numbers to Spot Scratch-Offs Worth Buying are probably the two cleanest next reads.

About the Author: Doug Moeller is a professional gambler with over 15 years of experience in poker, blackjack card counting, and casino advantage play, with over $500K in lifetime winnings. He built Savvy Scratch to bring a data-driven gambling mindset to scratch-off lottery tickets so everyday players can stop guessing and start making better decisions.