I Experimented With “URL-as-a-Data” Instead of Using a Database
I Experimented With “URL as Data” Instead of Using a Database
I wanted to build a very simple ordering page for small food businesses.
Most tools I saw required:
- Sign-up
- Login
- A database
- Ongoing setup
That felt like too much for home-based sellers and small food businesses.
So I asked myself:
Can an ordering page work without logins and without a database?
Check this out: https://linkory.xyz — it’s the result of that experiment.
Where the Idea Came From
While browsing templates, I came across Vercel’s OneLink template.
The idea was simple:
- Put data in the URL
- Render the page based on that data
It was meant for simple sites, but it got me thinking:
If a link can carry data, why not use the URL itself as the data source?
That’s when I decided to experiment.
What I Built
I built a prototype where:
- Menu data is encoded in the URL
- The app reads the URL when the page loads
- The ordering page is rendered instantly
No login
No database
Just a link
Sharing the link is the product.
The Catch
There is one big catch.
Because all the data lives in the URL, the URL can get very long—especially as the menu grows.
To make this practical for real sharing (Messenger, WhatsApp, Instagram bio),
a URL shortener becomes necessary.
Once shortened, the experience feels normal again:
short link in → full data out.
Limitations
- Long URLs (without shortening)
- No built-in order history or analytics
- Not for large or complex menus
This works best for small food sellers with simple needs.
What I Learned
- Simplicity can be a real feature
- URLs are more powerful than we usually treat them
- Constraints force better decisions
What’s Next for Me
Next, I’ll try using the same idea for link-in-bio pages and see how far the “URL as data” approach can go.
Wow, nice idea. also unique one. just a simple note regarding this, the URL length has limitations. So if you can solve this issue, You can reach the sky.
There's something underrated about building for people who actively don't want "proper" infrastructure. Home-based food sellers and small vendors aren't thinking about databases or user management - they just want to send a link and take orders.
The shortener dependency is interesting though. You're essentially trading one infrastructure piece (database) for another (shortener). If the shortener goes down or changes terms, your users' links break. Have you thought about running a simple redirect yourself, or does that defeat the whole point?
The link-in-bio direction seems like a natural fit. Same audience, same "I just want something that works" mindset.
Agreed. This audience prioritizes simplicity over infrastructure if it’s more than a link, it’s already friction.
The shortener trade-off is real, but most sellers already depend on third parties anyway. A minimal redirect layer is an option, as long as it doesn’t turn into a backend.
And yes, link-in-bio is a natural fit. Same mindset: one link, zero setup, just works.
This is a clever approach to zero-infrastructure products. The "URL as database" pattern reminds me of how excalidraw.com handles collaboration — they encode drawing state in the URL hash, so users can share complex diagrams without accounts.
Your insight about constraints forcing better decisions really stands out. Have you considered versioning? For example, if a seller updates their menu, anyone with the old link would see outdated prices. A simple version prefix in the URL structure (like v1-, v2-) might help, though it adds complexity.
Curious about the encoding — are you using base64, or something more URL-friendly like a custom compression scheme? The URL length limits vary by platform (Instagram bio truncates at ~150 chars visible), so the shortener dependency feels like both a feature and a potential single point of failure.
Great experiment — looking forward to seeing how it evolves for link-in-bio use cases!
Versioning is a known trade-off. Right now, the model favors immutability: a link reflects a snapshot. Adding versions is possible, but only if it doesn’t introduce management overhead.
Encoding is URL-safe compression, but in practice the shortener is essential due to platform limits. It’s both an enabler and a risk, which is why a minimal redirect layer is being considered.
Appreciate the feedback. link-in-bio is definitely the next logical evolution.
Makes sense — immutability as the default keeps it simple. The minimal redirect layer sounds like a good middle ground if you need to derisk the shortener dependency without going full backend.
Good luck with the link-in-bio experiment!