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.
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.
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!