As a developer, I'm constantly generating project ideas to sharpen my skills, explore new tech, or just to have something to do at 1 AM. Most of them are fine. Some of them are a URL shortener.
Spoiler: it's not the most innovative or practical thing I've ever built. In fact it's a genuinely bad idea, and I'd like to walk you through exactly why — right after I admit I built it anyway.
1. Short domains cost actual money
The entire job of a URL shortener is to make URLs short. Shorter is better. To get short, you need a short domain — and short domains are priced like beachfront property. Something like short.ly or tiny.io costs a small fortune, and everything affordable is so forgettable it defeats the whole point. You end up with a "short" link that's longer than the thing you shortened.
2. It's a phishing toolkit with a friendly UI
Shorteners hide the destination of a link — that's the feature. It's also the problem. The same mechanism that makes a link tidy makes it a perfect mask for phishing, spam, and assorted internet crime. You're not building a utility so much as a "click here, trust me" machine.
3. The million-dollar question: why?
The biggest flaw isn't technical, it's existential. When did I last need to shorten a URL? Modern chat apps unfurl links into neat previews, nobody types URLs by hand anymore, and most people actively want to see where a link leads before clicking. The use case has been quietly evaporating for a decade. I built a solution to a problem the world already solved.
The rickrolling incident
That said — the project wasn't entirely without merit. After it worked, I did what any responsible engineer would do with newfound power: I generated some very official-looking internal links and sent them to my coworkers.
Watching people click a "Q3 planning doc" and get Rick Astley instead was worth more than I'm prepared to admit in writing. Peak software engineering. Ship it.
The takeaway
In hindsight, this was a great reminder that not every idea deserves a repo. As a product, the URL shortener is doomed by cost, abuse, and irrelevance. As an exercise, though, it taught me a surprising amount about redirects, link expiry, collision-resistant short IDs, and the value of pressure-testing an idea before you've named the database.
Every project teaches you something. This one taught me to ask "why?" before "how?" — and that rickrolling never stops being funny.
// The ideas that survived that question ended up as my mini-APIs.