Building a URL shortener with Cursor, ChatGPT, AWS Lambda, API Gateway, and Cloudflare taught me more about shipping software than writing code.
Since last year, Cursor has been my go-to development assistant for daily tasks. But at the beginning of this year, just using it to generate snippets didn't feel like enough anymore.
Having studied programming since 2011, I knew what modern AI tools could do, but I wanted to test their limits. I decided to build a full project—a URL shortener—without writing a single line of frontend or backend code myself.
For the stack, I chose Node.js with TypeScript, React with Vite, and AWS Lambda to handle redirects. While I used ChatGPT to debate architectural trade-offs, Cursor generated the entire codebase.
Watching a functional application take shape so quickly was the exact moment a line was crossed for me. It made me realize how fundamentally software development is shifting: our role is evolving from code writers to architectural decision-makers and problem-solvers.
But truth be told, this project and this post represent a massive personal milestone.
Like many developers, I have a graveyard of half-finished projects on my machine. This is one of the first times I've pushed a personal project all the way to production. Writing this and exposing my work to the community is a huge first step for me. This isn't just a story about code or AI—it's about the challenge of finally shipping something.
The Stack
Before asking Cursor to write a single line of code, I wanted to map out the architecture.
I didn't need a massive enterprise system for a URL shortener, but I did want something flexible enough to support future features and experiments.
To validate my ideas, I used ChatGPT to debate the pros and cons of different architectural approaches. We eventually settled on this stack:
- Backend: Node.js + TypeScript
- Frontend: React + Vite
- Database: MongoDB Atlas
- Redirects: AWS Lambda
- Entry Point: AWS API Gateway
- DNS / CDN: Cloudflare
- Security: JWT + Rate Limiting
- Local Development: Docker
The core concept was simple: the main application would manage URL creation and administration, while a serverless AWS Lambda function would handle redirect requests.
On paper, everything looked straightforward.
Then came the deployment.
The Infrastructure Challenges (Where Things Got Real)
Cursor generated the Lambda code without much trouble. The real challenge wasn't the code—it was the infrastructure around it.
Most of my time ended up being spent configuring AWS and Cloudflare, debugging API Gateway permissions, and figuring out why something that worked perfectly in one environment would fail in another.
A large part of the learning came from connecting all the pieces together: custom domains, SSL certificates, DNS routing, API Gateway configuration, and the Lambda itself.
One lesson stood out in particular. Calling the Lambda directly worked almost immediately. Calling it through the final domain was a completely different story. Once API Gateway, Cloudflare, DNS propagation, certificates, and permissions entered the picture, entirely new problems started appearing.
Looking back, the URL shortener itself was relatively simple. The most valuable part of the project was understanding how all these services interact in a real production environment.
### Future Evolutions (Moving Beyond the MVP)
Getting the first version online was the main goal, but the project didn't stop there.
Once the foundation was working, I started using AI again to iterate on the product. This time, I also experimented with Codex for some of the follow-up work.
One of the first additions was a click counter. A URL shortener without any visibility into usage felt incomplete, so tracking redirects became an obvious next step.
I also added automated tests. While AI generated most of the code, I still wanted confidence that future changes wouldn't break existing functionality. Having tests in place made it much easier to continue evolving the project.
Beyond that, I implemented background jobs and email alerts for operational tasks and system notifications.
None of these features were strictly necessary for an MVP, but they helped transform the project from a simple experiment into something that felt closer to a real application.
More importantly, each iteration gave me another opportunity to explore how AI could contribute beyond the initial code generation phase.
Conclusion & Lessons Learned
Looking back, the biggest takeaway wasn't that I built a URL shortener.
It was learning how to work with AI throughout an entire project lifecycle: discussing architecture, generating code, troubleshooting infrastructure, adding new features, and refining the final result.
The code worked. But that was never the most interesting part.
But the most valuable part was everything around it: understanding AWS services more deeply, dealing with production issues, connecting multiple platforms, and realizing how much our role as developers is changing.
On a personal level, this project represents something else as well.
For years, I've started side projects that never made it beyond my local machine. This is one of the first times I've taken an idea all the way to production and then shared it publicly.
Writing this article was honestly just as challenging as building the project itself.
If you'd like to try it out, you can find it here:
https://urlshortener.it-rod.com
I'd love to hear your feedback, suggestions, questions, or even criticism. If you've been experimenting with AI-assisted development yourself, I'd also be curious to know what you've learned along the way.
I'm genuinely happy to finally be sharing this.
Top comments (0)