December 30th. I was ill. My wife had quarantined me to my study to keep the rest of the family healthy. We had a city break planned with the kids before they went back to school.
So there I was. Stuck at my desk. With a blog that had been living on my local machine for about 16 hours of development work.
I'd registered lewisrogal.co.uk a couple of days earlier - partly because I wanted the name, partly to force commitment. Spending money makes plans feel more real.
Time to ship it.
The blog was functional. Home page, blog listing, individual posts, sources page. 489 tests passing. Over 98% coverage.
I could have waited. Polished it more. Added more features.
But I wanted to understand deployment properly. Not theoretically - we use Azure at work, I know the concepts - but hands-on. Actually setting it up. Actually configuring DNS. Actually building a CI/CD pipeline.
The whole project had been about learning by doing. This was the next step.
I went straight for Azure Static Web Apps. We use App Services and other Azure resources at work, but for a Next.js static site, this made sense. Purpose-built for the use case.
Claude Code walked me through the Azure CLI setup. Install it, authenticate, create a resource group, create the static web app.
Resource groups are logical containers for related resources. Static web apps are optimized for hosting static sites with automatic CI/CD. The CLI lets you script everything rather than clicking through the portal.
First challenge: UK South doesn't support Static Web Apps. Had to use West Europe (Netherlands). Close enough.
The deployment worked first try. Create the resource, configure the GitHub Actions workflow, push the code. Azure pulled from the repo, built the site, deployed it.
The site was live on Azure's provided URL: thankful-glacier-0ee092d03.2.azurestaticapps.net
Then I tried to access it from my actual domain.
I'd completely missed DNS. Not forgotten - I'd never considered it at all.
I'd registered the domain. I had a working deployment on Azure. Everything worked on the Azure-provided URL.
The domain wasn't pointing at anything.
This is what "I've never done this before" actually looks like. I'd focused on the deployment itself and skipped the step where you connect a domain to it.
I switched modes. Exploratory chat with Claude: "I've deployed to Azure, I have a domain name, how do I connect them?"
This is the pattern from building the site. When I don't know something, I don't ask Claude to just do it. I ask questions. Work through the problem. Understand what needs to happen.
Then I execute.
Claude explained DNS records. CNAME records point domains at servers. TXT records validate domain ownership. A records map domain names to IP addresses.
Then it asked: "Where did you register the domain?"
I told it. Claude suggested Cloudflare's free tier for DNS management and analytics instead of using the registrar's DNS.
This wasn't about the DNS anymore. This was about tooling choices.
My instinct had been enterprise-grade everything. Google Analytics for traffic. The domain registrar's DNS because that's where I bought the domain. The patterns I knew from work.
But I was building a personal blog, not an enterprise system.
I didn't need conversion tracking or funnel analysis or A/B testing infrastructure. I needed basic traffic stats. What posts are people reading? How many visitors?
Cloudflare's free tier does that. Privacy-focused analytics. Simple dashboard. No cookie banners required. Plus better DNS performance and DDoS protection.
The conversation took maybe ten minutes. Claude asked questions about what I actually needed. I realized I was reaching for corporate tooling out of habit, not because it fit.
I moved my DNS to Cloudflare mid-deployment.
I switched nameservers. Configured DNS records in Cloudflare. Added the custom domain in Azure. Validated everything.
The site went live at lewisrogal.co.uk.
Then I clicked around to test it. The homepage worked. Individual blog posts returned 404s.
I was out of my depth. I understand routing conceptually - Next.js handles dynamic routes. But I didn't understand how that translates to CDN configuration.
The problem: Cloudflare's security settings affect how it handles requests. When proxying traffic (the orange cloud in their interface), Cloudflare needs specific configuration to handle dynamic routes properly.
The solution involved two settings:
Claude walked me through it. I made the changes. Waited for propagation. Tested again.
Everything worked.
Before pushing everything to main, I reviewed the GitHub Actions workflow manually.
There was a trigger condition left over from testing. The workflow was configured to run on pushes to deployment-test branch specifically. It wasn't going to break anything. Just redundant code.
Claude had been confident about that script. Presented it as complete and ready to use. But it still had test configuration that should have been removed.
I caught it because I read through the file before pushing. Not because I'm particularly good at GitHub Actions syntax, but because I've learned to check things manually rather than assuming they're correct.
I fixed it. Pushed to main. The workflow ran. The site deployed.
I'd created a deployment branch deliberately. Deploy to Azure from the branch, verify everything worked, then merge to main.
This came from experience. I've worked with systems where deployments meant manually copying files. Hoping nothing breaks. Praying you didn't miss a dependency or config file.
We're not doing that at the end of 2025. We're embracing DevOps at work. Docker for containerization. Automated CI/CD pipelines. The lessons from The Phoenix Project - A Novel about IT, DevOps, and Helping Your Business Win aren't just theory.
Even for a personal blog, I used the branch strategy. Deploy somewhere safe. Test it. Then promote it.
It's just good practice.
This project took about 16 hours total from initial build to production deployment.
The technical skills are mechanics. I learned Azure CLI commands. I learned DNS record configuration. I learned about Cloudflare's proxy settings.
The interesting part is what becomes feasible when you can move this quickly.
Before AI tooling, this would have taken weeks or months. The return on investment wouldn't have justified it. I wouldn't have attempted it.
With Claude Code, I built a fully-tested blog site and deployed it to production in 16 hours. Including learning Next.js and TypeScript properly. Including figuring out Azure deployment from scratch. Including writing the actual blog posts.
AI made the ambitious feasible. Not by writing all the code for me. By making the project worth attempting at all.
Right tool for the job matters. I was reaching for Google Analytics because that's what I knew from e-commerce. But a personal blog doesn't need enterprise analytics. Cloudflare's free tier does what I actually need. The Phoenix Project - A Novel about IT, DevOps, and Helping Your Business Win talks about this - don't over-engineer when simple works.
Good practices are good practices. Branch strategy. CI/CD pipelines. Automated deployments. Even for a personal blog. Even when it's just me. The discipline matters.
Next time will be easier. I've got Azure configured. DNS figured out. CI/CD working. GitHub Secrets set up. I've made the mistakes once. I have a pattern now.
The site is live at lewisrogal.co.uk.
It's not complete. There are features I want to add. Posts I want to write. Improvements to make.
But it's deployed. It's in production. It's real.
I have the infrastructure in place. I have the accounts configured. I understand how the pieces fit together.
This wasn't just about deploying a blog. It was about understanding the full stack - from local development to production infrastructure.
AI made it feasible to do in a day. While ill. While quarantined to my study.
That's the real story.
Technical Details:
Source: