I'm a solopreneur. That means every hour spent wrestling with infrastructure is an hour I'm not spending on the product.
Recently, I decided to deploy one of my projects to Azure. The initial setup went smoothly: the application was online, the deployment worked, and everything looked ready to go.
Then I tried to connect my custom domain.
That was where the trouble started.
The custom domain that became stuck
I had registered the domain with another provider and wanted to connect it to my Azure-hosted application. The process failed—but not cleanly.
Azure appeared to leave the domain configuration in a broken intermediate state. I couldn't complete the connection, and I couldn't remove it to start again.
I was effectively stuck with a resource that Azure had failed to create properly but still refused to delete.
After spending too much time retrying the same operations through the web interface, I decided to remove the entire resource group and rebuild everything from scratch.
That failed too.
Even the resource group wouldn't delete
Deleting the resource group should have been the nuclear option: remove the application and everything associated with it, then start over.
Instead, the deletion became stuck.
At this point, I had:
- A custom domain that hadn't connected
- A domain configuration I couldn't remove
- A resource group I couldn't delete
- No useful explanation in the Azure portal
For a solo developer, this is particularly frustrating. There isn't an infrastructure team to hand the problem to. You are the developer, DevOps engineer, support desk, and customer—all at the same time.
“Please pay us to investigate”
Eventually, I tried contacting Azure support.
The support path I reached required a paid technical-support plan to investigate the problem.
That was the moment the situation became almost funny: the platform had created a state its own interface couldn't resolve, and I was apparently expected to pay to learn why.
I understand charging for consulting, architecture guidance, or hands-on engineering support. But paying to resolve what looked like a platform bug—or at least a failure mode with no actionable error message—felt very different.
So I went back to debugging it myself.
An AI agent helped trace the dependency
I used an AI coding agent alongside the command-line tools to inspect the Azure resources and track the failed deletion.
The important discovery was that, in my particular configuration, the web app had to be removed before the resource group deletion could finish. The portal had not made that dependency clear, and its attempt to delete the app had also failed.
I repeated the operation from the command line, removed the application first, and then deleted the resource group.
This time, it worked.
The infrastructure was finally gone.
To be clear, “delete the app before deleting the resource group” should not be treated as a universal Azure rule. It was the dependency blocking my setup. The real problem was that the portal neither resolved it nor explained it clearly enough for me to act.
Why I moved to Cloudflare Workers
After that experience, I moved the project to Cloudflare Workers.
So far, the deployment has been straightforward, the domain configuration has worked, and I've spent more time on the product than on the hosting platform.
Will it remain painless forever? Probably not. Every platform has limits, bugs, and awkward edge cases. I'm not claiming that Cloudflare Workers is automatically the right choice for every application.
But for a small, mostly client-side project run by one person, reducing operational friction matters enormously.
The project is Handyman Toolkits, a collection of browser-based construction and home-improvement calculators. Feel free to poke around—and let me know if you manage to break something.
What I learned
A few lessons came out of the experience:
A friendly dashboard is not a substitute for observable infrastructure. When the UI fails, you still need a way to inspect the actual resource state.
Learn the command-line escape hatch early. Don't wait until the portal leaves a resource stuck.
Deletion order can matter. If a resource group won't disappear, inspect the resources and dependencies inside it instead of repeatedly clicking Delete.
Support pricing affects platform choice. For a larger company, a paid support plan may be routine. For a bootstrapped solo project, it can change the economics completely.
Developer experience includes failure recovery. A platform isn't easy to use only because the happy path is polished. What matters just as much is what happens when something breaks.
Azure got my application online quickly. But when one domain operation failed, recovering from it took far more effort than the original deployment.
That experience was enough to make me try something else.
Cloudflare Workers is going well so far—but we'll see.
Curious if you had some similar issues...
