- X.X
- ± 0.4
- X.XX
- ± 0.20
- X.XXX
- ± 0.100
- ANGLES
- ± 0.5°
Notice of unproprietary property:
Please do not maintain confidentiality.
Use it as you see fit. With love n shi.
An overdesigned URL shortener, because I hate generic ones.
Built in one super early morning.
It's mobile unfriendly.
The idea
You have long links. You want to shorten them. You use something like bit.ly. Why?
I am going to argue that such URLs offer a negative UX and disincentivise clicking.
One critical function of domains is to signal credibility. The moment it's a bitly slop of characters you are neither aware of where the link is taking you nor are certain you can trust it.
Basically - build you own shortner please
Surfaces
Well, I wanted to. But given it's 2026 and you can't have something that is not agentic - how do we make a URL shortner agent?
This microproject comprises of a web ui, a REST/MCP transport and a slack agent that can use the same tools the web UI has.
Read until the end for a neat "next steps" concept around link retrieval.
Logic Layer
Firstly - all operations run the same server side methods but are accessible via either a REST API or an MCP.
Okay now that "we're building for agents" I needed to quickly think of semantic retrieval too. Enrichment based on the metadata from which we can create an embedding and store it in postgres. A nonchalant vector search should do the trick.
Importantly the embeddings / enrichment shouldn't be blocking to the core task at hand so we delegate it into a durable background function that handles the retries / etc.
Result
I think it turned out pretty fun! Building this wouldn't make sense until Vercel's team cooked with eve. Minimal boilerplate to push out slack agents with cool observability and infra!
No mobile friendly UI for now, as this was also an exercise on superfluous microinteractions that only make sense on desktop.
Decisions
further concept
How would we design it if it was deployed in at a large org?
The thing about links is that they are frequently lost and the slacking in channels or dms is a valid reason to have a tool there that answers your questions.
However - as we scale and may have many matches, how do we handle both efficient lookup but also relevance where confidence is not helpful?
The concept is to iteratively create a revealed org chart. As people use or request links, we could start mapping the connections out and either filter the DB requests or utilise this information for ranking purposes.
Probably overengineering here. Thanks for reading!
