I wanted to build a roulette website. I also set out to learn.

I have worked in IT for some time, started with Windows admin, moved to Linux, and then onto some basic DevOps work. I may have gotten to the 4th chapter of every Python book ever written, but never fully committed to programming. I have never really done every aspect of the build process, the “Full Stack.”

I wanted to understand the full picture — how a modern web application actually gets built, containerized, deployed, and maintained in production. Not just the code, but the infrastructure. Docker. Reverse proxies. SSL certificates. DNS. The things that tutorials skip over and production demands.

I also wanted to test a theory: could I use AI — specifically Claude — as a genuine development partner to build something real? Not to generate a throwaway script, but to architect, debug, and ship a production application across multiple servers, frameworks, and deployment environments?

So I built Big Spin Fun, a free online roulette game with European, American, and Triple Zero variants. It runs on Next.js, Django, PostgreSQL, and Nginx, all containerized with Docker Compose and deployed to AWS Lightsail. And I built virtually all of it through a conversation with Claude.

Here's how it actually happened — the messy, nonlinear, real version.

Why Roulette?

I’ve always been a casual gambler with a genuine interest in the mechanics of different betting systems. I’m a regular viewer of channels like CEG Dealer School, The Roulette Master, and Jack Ace, and I found myself wanting a sandbox where I could test out strategies without any financial risk. In the end, building my own simulator felt like a much more rewarding challenge than simply clicking around on someone else’s site.
Claude as a Development Partner
Let me be upfront about this: Claude wrote the vast majority of the code in this project. But that sentence undersells what actually happened.

I didn't paste in a prompt that said "build me a roulette game" and get back a finished product. The project evolved over a long, iterative conversation that spanned the full lifecycle of a real application — from a single React component to a multi-container Docker deployment with HTTPS, user authentication, and SEO optimization.

What made it work was that I brought the vision and the decisions, and Claude brought the implementation knowledge. I'd say "I want user accounts and a database," and Claude would lay out the options — Django vs Flask, Postgres vs SQLite — explain the tradeoffs, and then build it once I chose a direction. When something broke, I'd paste the error, and Claude would diagnose it.

This wasn't autopilot. I had to understand what was happening at every step. When Claude generated a Dockerfile, I needed to understand multi-stage builds to know why it was structured that way. When it wrote a Django model, I needed to understand what migrations were to debug why the database wasn't creating tables. The AI accelerated my learning — it didn't replace it.

The conversation itself became a kind of documentation. Every architectural decision, every debugging session, every "why did I get a 502 Bad Gateway" was captured in the chat history. I could scroll back and see exactly why we chose Next.js over plain React (SEO), why we added Nginx in front of everything (SSL termination and security), and why the database password couldn't contain a + character (URL parsing).
Starting on Windows with VS Code
The project started on my Windows machine (using Windows Subsystem for Linux) with VS Code open and a vague idea: build a roulette wheel that spins. That was it. No grand architecture plan, no deployment strategy, just curiosity.

I opened Claude and described what I wanted. Within minutes, I had a working React component — a spinning SVG wheel with authentic pocket ordering, a grid of clickable numbers, chip selection, and payout calculations. It ran in Vite on localhost. You could click a number, hit spin, and watch an animated wheel land on a random pocket.

That first component was maybe 400 lines of JSX. Claude generated the entire thing — the SVG math for the wheel segments, the CSS animations for the spin physics, the betting logic, the color mapping for red and black numbers. Things that would have taken me days of MDN documentation and Stack Overflow to figure out came together in a single response.

But here's the thing: I immediately started asking questions. "What language is React?" "How do I make changes to this?" These weren't embarrassing questions — they were the natural learning path of someone using AI to build beyond their current skill level. And Claude answered them without judgment, at exactly the level of detail I needed.

VS Code was my constant companion through every phase. The search and replace functionality alone probably saved me hours. When you're renaming things across a full-stack app — changing "Roulette Royale" to "Big Spin Fun" across frontend pages, meta tags, Docker configs, and Nginx files — Ctrl+Shift+H becomes your best friend.
The Docker Obsession
Docker is the cornerstone of the modern-day app in the cloud. I could have stopped at a single React app served by Nginx. But I wanted to understand Docker. Not just "run a container," but actually architect a multi-container application the way production systems work.

I told Claude I wanted everything in Docker containers, very portable, something I could eventually move to AWS. Claude scaffolded a multi-stage Dockerfile — Node builds the React app, then only the compiled static files get copied into an Nginx Alpine image. The result was about 25MB. That felt satisfying.

But then I started thinking bigger. I wanted user accounts. A database. Server-side game logic so players couldn't just edit their balance in the browser console. I asked Claude about Django, and that led to a conversation about architecture that fundamentally changed the project.

I am a perpetual beginner when it comes to Python. I have always had the intent to get more comfortable with it, so moving to Django seemed like a logical step

Claude didn't just say "use Django." It explained the tradeoffs. Django would give me auth, an admin panel, and an ORM, but the frontend would still need React for the interactive game. I'd end up with two containers plus a database. Was I ready for that complexity? I said yes.

That "yes" turned a weekend project into a real full-stack application:

Next.js for the frontend — Claude recommended it over plain React because I mentioned wanting SEO and advertising revenue eventually. That one recommendation shaped the entire frontend architecture.
Django REST Framework for the backend API — user auth, game engine, leaderboard
PostgreSQL for persistent data
Nginx as a reverse proxy in front of everything

Four services. One docker-compose.yml. Claude generated all of it — the Dockerfiles, the compose configuration, the Django models, the API views, the Next.js pages, the Nginx config. But each piece came through conversation, not a single prompt.
Docker Compose: Simple in Theory, Brutal in Practice
The docker-compose.yml looks clean when it's done. Four services, some environment variables, a few volume mounts, a health check. Maybe 50 lines of YAML.

Getting to those 50 lines was anything but clean. And this is where working with Claude on real infrastructure problems — not textbook examples — taught me the most.
The Rocky Linux Detour
After getting everything working locally on Windows, I deployed to a Rocky Linux server. This was my first time running Docker Compose on a remote machine, and the workflow was clunky.

I'd edit files locally in VS Code, push to GitLab, SSH into the Rocky server, pull the changes, rebuild, and check if it worked. When it didn't — and it often didn't — I'd SSH back in, read the logs, paste them into Claude, get a fix, go back to VS Code, make the change, push, pull, rebuild.

Claude was patient through all of this. The same kinds of errors would come up in slightly different forms, and it would adjust its advice based on what we'd already tried. It remembered context from earlier in the conversation — "we fixed the migration issue already, so this is a different problem" — which kept the debugging focused.

Rocky Linux worked fine as a Docker host, but when I decided to move to AWS, Ubuntu was the more natural choice for Lightsail.
Moving to AWS Lightsail
Lightsail is AWS's simplified VPS offering. You pick a size, pick an OS, and you get a server with a static IP. No VPC configuration, no security group mazes, no IAM policy debugging. Claude recommended it as the simplest path to AWS — it's AWS for people who just want a server.

Claude walked me through the entire setup: SSH key generation, installing Docker on Ubuntu, cloning from GitLab using SSH keys, configuring DNS. Each step was a short exchange — I'd ask "how do I do X," Claude would give me the exact commands, I'd run them, report back, and move on.

When the build hung on the small Lightsail instance, Claude suggested the GitLab Container Registry — build on my local machine, push images to GitLab's free registry, pull pre-built images on the server. The server only needs enough RAM to run the containers, not build them.

Before: build on the server (needs RAM)

frontend:

build: ./frontend

After: pull pre-built images (needs almost no RAM)

frontend:

image: registry.gitlab.com/booker357/roulette-page/frontend:latest

Eventually I added swap space and switched back to building on the server directly, which simplified the workflow. Edit files on Lightsail, build on Lightsail, push to GitLab for version control. One machine, one workflow.
The Migration Problem
Django uses migration files to create database tables. These files need to exist in the codebase before the application starts. Claude had generated the models and the views, but the migration files — the glue between the code and the database — were missing from the project.

The cycle went like this: start the app, Django crashes because the accounts_player table doesn't exist, paste the error into Claude, get told to run makemigrations, run it inside the container, migrations get created in the container's filesystem, stop the container, migrations disappear, start the container, crash again.

This went on for multiple rounds. Each time I'd paste the error into Claude, and each time we'd get a little closer to understanding the root cause. Claude eventually realized the issue: the migration files were being generated inside ephemeral containers and never persisted to the host filesystem. The fix was to create the migration files directly and commit them to the repo.
I was, admittedly, pretty dependent on Claude.

Claude then generated the complete migration files by hand — reading the Django models it had written earlier and producing the corresponding migration Python code. It was like watching someone debug their own work in real time.

This was a turning point in how I thought about AI-assisted development. Claude had made an oversight in the initial scaffolding (not including migration files), but it was also the one that diagnosed the problem, explained why it was happening, and generated the fix. The AI wasn't perfect, but it was resilient — each error message I fed back in got us closer to a working system.
The Build Problem
Building Docker images requires RAM. Building a Next.js app inside a Docker container on a small server requires more RAM than a small server has. I learned this the hard way when docker compose build would just hang indefinitely on a 512MB VPS, the cheapest host option in AWS Lightsail.

I told Claude it was hanging, and it immediately identified the issue: insufficient RAM for the Node.js build process. It gave me a few solutions — add swap space, use a container registry to build elsewhere, or upgrade to a larger VPS. I built the containers remotely using GitLab at first, but I eventually upgraded the VPS instance and added additional swap space so I could build on the VPS.

Environment Variables and Special Characters
I generated a random database password with openssl rand -base64 24. The password contained a + character. That + got embedded in the database URL (postgres://user:pass+word@db:5432/roulette) and broke Python's URL parser. The error message — ValueError: Port could not be cast to integer value as 'zu1mnDRpA6v+' — made no sense to me.

I pasted it into Claude. Within seconds, it identified that the + in the base64 password was being interpreted as a URL-encoded space, corrupting the port parsing. The fix: use openssl rand -hex 24 instead. Only alphanumeric characters. No special characters to break URL parsing.

This is the kind of bug that could take hours to figure out on your own. Claude diagnosed it from the error message in one turn. That's not replacing my learning — it's accelerating it. I now understand URL encoding, database connection strings, and why special characters in environment variables are dangerous. I learned it through a real bug, not a textbook.
HTTPS: The Certificate Dance
Getting SSL working was its own adventure. Claude generated the entire Nginx configuration, the Certbot Docker setup, and a setup script that handled the chicken-and-egg problem: Nginx needs SSL certificates to start, but Let's Encrypt needs Nginx running to verify your domain.

The solution is a multi-step dance:

Create a temporary self-signed certificate so Nginx can boot
Start Nginx
Run Certbot to get a real certificate via the ACME challenge
Reload Nginx with the real certificate

Except the real certificate ended up in bigspinfun.com-0001 instead of bigspinfun.com because the self-signed cert was already occupying the expected directory. So Nginx kept serving the self-signed cert, and browsers showed a security warning.

I told Claude the browser was showing "Not Secure." It had me check which certificate was actually being served using openssl s_client, which revealed the self-signed cert was still active. Claude figured out that Certbot had created the real cert in a -0001 suffixed directory to avoid overwriting the temp cert. The fix was renaming the directory:

sudo mv .../bigspinfun.com-0001 .../bigspinfun.com

docker compose restart nginx

This was a problem neither of us anticipated. Claude didn't generate a bug-free setup — it generated a setup that worked in theory but hit an edge case in practice. Then it debugged that edge case from the symptoms I reported. That's how real development works, with or without AI.
Claude for SEO and Marketing
Once the site was running, the conversation shifted from infrastructure to business. I told Claude I wanted advertising revenue and SEO optimization. It laid out a complete strategy:

SEO first — the site needs to be crawlable before ads make sense
Advertising second — apply for AdSense once content is solid
Expense tracking last — internal tooling can wait

Claude then generated everything for SEO: a robots.txt, a dynamic sitemap, JSON-LD structured data, Open Graph tags, Twitter Cards, and three full content pages targeting specific search queries — "how to play roulette," "roulette odds," and "roulette bet types." Each page had unique metadata, proper heading hierarchy, FAQ sections with schema markup, and internal linking.

It also generated a privacy policy (required for AdSense) and walked me through submitting the sitemap to Google Search Console and Bing Webmaster Tools, setting up Google Analytics, and fixing SEO issues that Bing's crawler flagged — a missing H1 tag and duplicate canonical URLs.

The SEO work was where Claude's breadth of knowledge really showed. It wasn't just writing code — it was making strategic decisions about which keywords to target, how to structure content for featured snippets, how to optimize for AI search engines (allowing GPTBot and ClaudeBot in robots.txt), and when to use server-rendered pages vs client-side components.
What AI-Assisted Development Actually Feels Like
People have strong opinions about AI coding tools. Some think it's cheating. Some think it produces garbage. Some think it replaces developers. After building an entire production application through conversation with Claude, here's my experience:

It's not cheating. I made every architectural decision. I chose the stack, the hosting, the domain, the feature set. Claude implemented those decisions, but the judgment calls were mine. When Claude suggested Next.js for SEO, I had to understand what SSR meant and why it mattered before saying yes.

It's not garbage. The code Claude generated was clean, well-structured, and production-ready. The Django models had proper indexes and ordering. The Nginx config had security headers and gzip compression. The React components used proper state management. Was it perfect? No — the missing migration files and the SSL certificate edge case prove that. But the quality was consistently high.

It doesn't replace understanding. I learned more about web infrastructure in this project than in any course I've taken. Every error message I pasted into Claude became a learning opportunity. I didn't just fix the problem — I understood why it happened. The AI compressed what would have been weeks of Stack Overflow and documentation into hours of focused, contextual learning.

It changes the ambition curve. Without Claude, I would have built a static HTML roulette game and called it done. With Claude, I built a full-stack application with user auth, server-side RNG, a PostgreSQL database, Docker containers, Nginx reverse proxy, SSL certificates, SEO optimization, and analytics — and deployed it to AWS. The AI didn't lower the bar. It raised how far I was willing to reach.

The conversation is the product. The most underrated aspect of AI-assisted development is the conversation itself. Every decision, every debugging session, every "why did we do it this way" is captured in the chat history. It's like pair programming with someone who has infinite patience and remembers everything you've discussed.
GitLab as the Backbone
Throughout all of this — Windows to Rocky to Lightsail — GitLab was the constant. Every change got committed and pushed. When I broke something (which happened regularly), I could look at the git log and figure out what changed. When I moved servers, I could clone the repo and have the entire project structure in seconds.

I set up SSH keys on each server so git operations were seamless. No tokens to manage, no passwords to type. Claude walked me through the SSH key setup for each environment.

The GitLab Container Registry was a bonus I didn't expect. Free private Docker image hosting, integrated with the repo. Push an image, pull it on any server. No separate Docker Hub account needed.
The Stack Today
The production setup at bigspinfun.com:

Next.js 14 — server-side rendered frontend with SEO content pages
Django REST Framework — user accounts, server-side RNG, game history API
PostgreSQL 16 — persistent storage for users, spins, leaderboard
Nginx — reverse proxy, SSL termination, gzip, security headers
Let's Encrypt — auto-renewing SSL certificates via Certbot
Docker Compose — all four services defined in one file
AWS Lightsail — Ubuntu instance with 2GB RAM, 12$ per month, at the time of this writing
GitLab — source control and container registry
Claude — development partner from first line of code to production deployment

The entire thing can be cloned and started with docker compose up. That was always the goal — portability. Move it to any server with Docker installed, and it just works.
What I'd Do Differently
If I started over, I’d start by using the cloud from day one. I would start with the cheapest solution and work my way up from there. I’d also set up the migration files and Docker Compose health checks. The number of hours spent debugging "why won't Django start" because of missing migrations was embarrassing — even with Claude helping.

I'd also start with HTTPS immediately. Setting it up after the fact means reconfiguring CORS origins, cookie settings, and CSRF trusted origins. Setting it up first means everything just works with the secure defaults.

And I'd build on a machine with at least 2GB of RAM from the start. The time spent debugging "why is Docker Compose hanging" on undersized servers was time I could have spent on features.
The Point
This project taught me more about real-world web development than any course or tutorial. Not because the roulette game is complex — it's a fairly simple application. But because deploying it to production, keeping it running, and making it accessible to the world involves a web of interconnected systems that you can only understand by building through the problems.

Claude didn't remove the problems. It made them solvable at a pace that kept me engaged instead of frustrated. Every error became a five-minute conversation instead of a two-hour rabbit hole. That's the difference between giving up and shipping.

If you're trying to learn infrastructure, pick a project you actually want to build and deploy it for real. Not to localhost. Not to a tutorial sandbox. To a real server with a real domain and real SSL certificates. And if you use an AI to help you get there, don't feel guilty about it — feel empowered. The understanding you gain from building something real, even with help, is worth more than the theoretical knowledge of doing it alone.

The game is live at bigspinfun.com. It's free, no real money, no signup required. Spin the wheel, place some bets, and if you're curious about how it's built, now you know.