How I Built a Spelling Bee App for My Daughter (and Why This Win Feels a Little Bit Mine Too)

Mon, 06 Apr 2026 00:00:00 +0000

Earlier this year, my daughter won her school Spelling Bee. Every single word.

And honestly, this win feels a little bit mine too. Let me tell you why.

I am a Mainframe developer. COBOL, JCL, batch processing — that has been my world for years. Web apps, mobile apps? Completely foreign territory.

Back in January, my daughter came home excited about her school Spelling Bee. She needed to practice. A lot. We started by looking for apps in the App Store, but nothing quite fit what we needed. Some were too basic, others were cluttered with features that got in the way. And somewhere between being a frustrated parent and a curious developer, I thought… what if I just build something for her?

So I did.

The App

With Claude as my AI pair programmer, I built the Spell Bee Practice App from scratch.

The app reads out words at multiple speeds so she could hear every syllable, pulls real-time definitions from the Merriam-Webster Dictionary API, lets you upload your own word list or type words in manually, and tracks progress as you go. It works as a Progressive Web App with separate versions optimized for mobile and iPad. And the whole thing lives in a single HTML file. No backend. No build process. Deployed free on GitHub Pages.

The Honest Part

I could not have built this alone. Tailwind CSS, async API calls, the Web Speech API, PWA manifests — all new to me. But Claude did not just write code. It explained the reasoning behind every decision and flagged things I would never have considered. It felt less like using a tool and more like working with someone who knew what they were doing and had the patience to bring me along.

We built the whole thing conversationally, one feature at a time, inside a single Claude Project.

What This Changes (and What It Doesn’t)

I have written before about how AI is not a magic wand — especially when it comes to complex legacy modernization, where the real challenges are organizational, not technical. I still believe that.

But this experience showed me the other side. When the scope is clear, the motivation is real, and you are willing to think through every decision yourself, AI can genuinely help you build something meaningful in a space you have never worked in before.

You do not need to know everything before you start building. Sometimes a single HTML file is all you need. And the best motivation for any side project? Someone you love depending on it.

The app is live and the code is open below. Go build something for someone you love. 🐝

Live App & Repo: github.com/ndranandraj/spellbee-mobile-enhanced

Mainframe Modernization in the AI World

Sat, 28 Mar 2026 00:00:00 +0000

I’ve been thinking about this a lot lately. Everyone’s excited about AI tools like Claude being used to modernize legacy COBOL systems. And they genuinely help, don’t get me wrong. But my hot take? AI won’t modernize your mainframe immediately. At least not by itself.

I say this from experience.

My first project in the mid 2000s was a mainframe-to-SAP migration. 18 months. Clear scope. Migration tools were ready. Two years later? We hadn’t even crossed 25%.

That wasn’t a failure of effort or talent. It was a failure of understanding just how deep the rabbit hole goes.

And this isn’t new. We’ve been trying to get off mainframes for 30+ years. Y2K was supposed to force everyone to modernize. It didn’t. Then came COBOL-to-Java converters. Then model-driven tools. Then cloud platforms. Then low-code rewrites. Every decade had its “this is finally the thing” moment.

And yet the mainframe is still there. Still processing an estimated $3 trillion in commerce every single day.

The problem was never the tooling. It was everything around it.

These systems are 40-60 years old. The people who understood them are gone. The code is the documentation. Half of it looks wrong until you realize it was intentional, for a reason nobody wrote down. You only find out why when something breaks.

And it’s never just the code. You have to move the data, rebuild the batch workflows, the middleware, the security models. All at the same time. Without breaking the thing quietly keeping the lights on.

Then comes the hardest part. Proving it works exactly the same.

For a bank, “close enough” can mean a rounding error of half a cent across 10 million transactions. SOX, Basel III, and other regulatory frameworks don’t care how smart your tool is. They want a clear paper trail down to the last decimal place.

AI is genuinely better than anything before it. It understands context and can reason about code in ways older tools never could. But it still hits the same walls. Missing knowledge, untestable edge cases, organizational resistance, regulatory burden. The walls haven’t changed. Just the tool hitting them.

The companies getting this right treat modernization as a long-term commitment, not a shortcut. They bring the right people, the right process, and realistic expectations. The tool is just one part of that equation.

I learned that lesson in 2007. Still holds true today.

What did your experience look like?

Welcome to Anandraj's Personal blog on Anand's Blog

How I Built a Spelling Bee App for My Daughter (and Why This Win Feels a Little Bit Mine Too)

The App

The Honest Part

What This Changes (and What It Doesn’t)

Mainframe Modernization in the AI World