SMART LOTTO Dev Log #8 — Rebuilding with Flutter and Claude Code

The Plan Was Simple

The app runs. The screens are visible. I know what every feature does.

I can rebuild this.

The question was how — and whether to make it different this time.

Why Flutter

The original app was Swift UIKit, iOS only. I could rebuild it in Swift again.

But if I was starting from scratch anyway, I wanted Android support too. That meant a cross-platform approach.

Flutter or React Native. Both had advantages. For this app — charts, animations, custom UI, performance-sensitive statistics — Flutter made more sense. Flutter renders its own UI rather than delegating to platform components, which means consistent behavior across iOS and Android and more flexibility on custom visual elements.

And critically: I wanted to change how I worked, not just what I built.

Using Claude Code as a Development Partner

The original app took two weeks because I was building in familiar territory with established patterns. This rebuild involved Flutter (which I knew but hadn't used heavily), a completely redesigned architecture, and algorithms that had to match the behavior of the original app exactly.

I used Claude Code throughout this project — not just for code generation, but as a thinking partner for design decisions.

For example, the condition-based number generation algorithm:

"I need to generate 6 lottery numbers satisfying these simultaneous constraints: fixed numbers, excluded numbers, odd/even ratio, sum range, tail digit distribution. What's the best approach?"

Claude Code laid out multiple approaches — brute force with filtering, constraint propagation, hybrid methods — with tradeoffs for each. I evaluated and chose. This kind of rapid architectural discussion would have taken much longer with documentation alone.

Fixing the Root Bug

The broken API was addressed in the rebuild. The new app uses the updated data source from the redesigned Donghaeng Lottery site, with proper error handling and fallback logic.

June 11, 2026, 1:51 AM

Version 1.2.0. New UI, new architecture, both platforms.

A few months after losing the source code, the app was back — better than before.

Losing the Code Was the Catalyst

If the original code had survived, I would have patched the API issue and moved on. The architecture would have stayed the same. The iOS-only limitation would have stayed.

Instead, losing everything forced a complete rebuild. And a complete rebuild meant every bad decision from 2020 could be made correctly in 2026.

Not every disaster turns into an opportunity. This one did.

Next: the unexpected wall that stood between the finished Android app and the Play Store.