My bird identification game, Birdie, went dark last month. Not because of a bug or a user complaint—but because AWS decided my free tier was over. I’d originally deployed it on an EC2 instance using Docker Compose, Nginx, and Let’s Encrypt. It worked beautifully. But when the bill started looming, I faced a choice: pay $10-15/month to keep it running on AWS, or find another way. I chose another way. I migrated Birdie to Railway, redeployed both the frontend and backend as services, and had it live again in 30 minutes. But here’s where the real story begins—because once it was live, I actually tested it on mobile for the first time. And that’s when everything changed.

The AWS Free Tier Ends (And So Does Your Grace Period)

Here’s what nobody tells you about AWS free tier: it’s a trap. Not maliciously—AWS is clear about the limits. But when you’re building side projects, you don’t think about costs. You think about building. So I deployed Birdie and moved on.

My original setup was solid. EC2 t2.micro instance running Docker Compose, with Nginx as a reverse proxy and Let’s Encrypt handling SSL. The architecture was clean. The monthly costs, once the free tier ended, looked like this:

• EC2 t2.micro: $8.47/month
• EBS storage: $2-3/month
• Data transfer: variable

Not catastrophic, but not nothing either. And more importantly—it’s friction. Every month, that bill reminds you that this thing costs money. For a side project with no revenue, that friction adds up.

Why I Picked Railway

I’d heard about Railway from other builders. The pitch was simple: deploy from GitHub, automatic Docker support, simpler pricing, zero infrastructure management. I was skeptical. I’d been managing my own infrastructure long enough to appreciate the control. But I was also tired.

Railway’s pricing model is straightforward. You pay for what you use—compute, storage, bandwidth—with a $5 minimum and no surprise bills. For Birdie’s traffic, I estimated $5-10/month. It wasn’t about saving money (though that helped). It was about removing the mental overhead.

I’d actually already been using Railway for another project—my TaskCocoon backend—so my GitHub account was already connected. This time, I just needed to create two new services: one for the backend, one for the frontend.

The migration itself should’ve been simple. Connect my GitHub repo, Railway auto-detects the Dockerfile, build and deploy. But it wasn’t.

The Migration Hiccup (And How I Fixed It)

My repo structure had /frontend, /backend, and other directories at the root level. When Railway tried to auto-detect which Dockerfile to use, it got confused. It couldn’t figure out which one mattered.

The fix was embarrassingly simple. My original Dockerfiles were written assuming everything lived at the root. I updated them to reference the subdirectories explicitly, pushed to GitHub, and Railway picked up the change. Thirty minutes later, Birdie was live on Railway.

I felt accomplished. I’d saved money, simplified my infrastructure, and shipped in under an hour. I celebrated a bit. Then I made the mistake of testing on my phone.

Testing on Mobile (The Moment Everything Broke)

Here’s the thing about desktop development: you can build something that works perfectly on a 27-inch monitor and be completely blind to how it functions on a 5-inch screen.

On desktop, Birdie displays three bird options horizontally. Clean layout. Plenty of space. Users can see all three options at once, pick the one they think is correct, and submit. It’s intuitive. It works.

On mobile? Three birds stacked vertically. Users had to scroll down to see all three options. And when they got to the bottom, they had to scroll back up to hit the submit button. But worse—there was no indication of how to navigate between birds. The dots below the submit button weren’t intuitive at all. Most users would’ve been confused.

The Mobile Redesign: One Bird at a Time

I redesigned the mobile experience from scratch. The new approach was simple: show one bird at a time on mobile devices.

Before (broken):

• 3 birds stacked vertically
• Confusing navigation dots below submit
• No progress indicator
• Users had to scroll to see all options

After (fixed):

• One bird displayed at a time on mobile (screens under 768px)
• Clear ← PREV and NEXT → arrow buttons
• “Bird 1 of 3” progress counter
• Buttons auto-disable at boundaries (greyed out, can’t click past bird 3)
• Navigation dots appear below submit for review after submission
• Desktop experience remains unchanged (all 3 birds still display horizontally)

The implementation took about 2 hours:

1. Added mobileCurrentBird state to track which bird is visible
2. Used CSS media queries to show/hide birds based on screen size
3. Styled arrow buttons with hover effects and disabled states

Desktop users never noticed a change. Mobile users suddenly had a product that made sense.

What This Cost Me (And What It Taught Me)

The numbers:

• Migration time: 30 minutes
• Mobile redesign: 2 hours
• New monthly cost: For now, free, but later~$5-10 (vs $10-15 on EC2)
• User experience improvement: Massive

But the real cost wasn’t in time or money. It was in confidence. I’d shipped something I hadn’t tested. And while I caught the problem, it could’ve been worse.

Three Lessons I’m Taking Forward

1. Test on actual devices before shipping. Responsive design isn’t just about making things fit the screen—it’s about the user experience. I could’ve discovered this problem months earlier if I’d tested on mobile before pushing to production.

2. Intuitive navigation beats novelty. Those dots looked nice. They were a design element I was proud of. But arrows are immediately clear. Users understand “NEXT →” without thinking. Sometimes the boring choice is the right one.

3. Remove infrastructure friction to focus on product. By moving to Railway and eliminating the mental overhead of managing EC2, I freed up mental space to actually use the product like a user would. The platform shouldn’t be where your attention goes—the product should.

What’s Next for Birdie

The mobile experience is solid now, but there’s more to build:

• Background music during gameplay
• Expanded bird collection (beyond the current 9)
• Better landing page visuals
• Optional persistent data storage for user progress tracking

But first, I’m going to test those features on mobile. Lesson learned.

Building in Public Means Shipping Fast and Iterating Hard

This migration wasn’t just about saving money or moving to a new host. It was a reminder that building in public and iterating based on real usage is non-negotiable. The best infrastructure means nothing if users can’t navigate your app on their phones.

Railway handled the infrastructure beautifully. Now I can focus on what actually matters—the experience.

Birdie is live at birdie.augustwheel.com. Try it on desktop and mobile, and let me know what you think.