The web doesn't have a shortage of content.
It has a discovery problem.
Every day, publishers publish thousands of articles. Developers ship projects. Creators upload videos. Stores add products. Startups launch new ideas.
But discovering the right thing at the right time is still surprisingly difficult.
Most people repeatedly see content from the platforms, websites, and creators they already know.
We started asking:
What if discovery worked differently?
Meet QEVRA
QEVRA is an open-web discovery platform we're building to help people discover:
- News
- Articles
- Creators
- Videos
- Products
- Stores
- Startups
- Ideas
- And more from across the web
The goal isn't to create another website where everything is dumped into one giant feed.
The interesting engineering problem is deciding what deserves to be shown to whom.
The scaling problem
Imagine QEVRA has 1 million publishers.
Now imagine those publishers collectively publish millions of pieces of content every day.
A user cannot possibly consume everything.
Showing users everything isn't personalization.
It's noise.
So our discovery system needs to answer a much harder question:
«Which piece of content is relevant to this particular person right now?»
That means thinking about signals such as:
- Topic
- Region
- Language
- Content type
- Freshness
- Publisher
- Creator
- User interests
- Previous interactions
- Trending signals
- Context
- Content quality
- And the relationship between a user's interests and a piece of content
We're interested in building this as a continuously evolving relevance system rather than a simple chronological feed.
Publishers have a different problem
There's another side to this.
A publisher might create excellent content but have an audience concentrated in one country or community.
Another publisher might cover a completely different subject for a completely different audience.
Treating both publishers identically doesn't make much sense.
Our objective is therefore not:
"Give every publisher the same amount of traffic."
It's:
"Give content the opportunity to reach people for whom it is actually relevant."
That distinction becomes increasingly important as the number of publishers grows.
The architecture matters too
QEVRA is designed around a separation between public discovery traffic and database-heavy authenticated operations.
Public discovery is delivered through backend APIs, caching and precomputed data rather than making every visitor directly query Firestore.
That matters because scaling from 100 users to potentially millions of users shouldn't mean creating millions of unnecessary database operations.
We're also treating RSS ingestion as a backend process.
A visitor opening a discovery page shouldn't suddenly trigger an RSS provider request.
The ingestion layer fetches and processes feeds independently, while the public application consumes the resulting discovery data.
Images are another interesting problem
A surprisingly difficult part of an aggregation/discovery platform is image delivery.
An article can be available immediately while its image is still loading slowly because the image belongs to another server.
So we're working toward a pipeline where:
Publisher → ingestion → image extraction → validation → cache → optimized delivery → user
rather than making every visitor repeatedly retrieve the same external image.
This also lets us separate content discovery from upstream publisher latency.
We're still building
QEVRA is early.
There are plenty of things we're still figuring out:
- How should relevance be calculated?
- How should new publishers earn initial discovery opportunities?
- How should regional relevance work?
- How do we prevent a few enormous publishers from dominating discovery?
- How should freshness affect ranking?
- How do we distinguish genuine interest from accidental clicks?
- How do we handle millions of new items without overwhelming users?
- How should users control their own discovery experience?
We don't pretend to have all the answers yet.
That's actually one of the reasons we're sharing the project publicly.
We'd love developer opinions
If you were designing an open-web discovery algorithm from scratch, what signals would you prioritize?
Would you rank primarily by:
A. Personal relevance
B. Freshness
C. Engagement
D. Publisher quality
E. Geographic relevance
F. A combination of all of them
And perhaps the more interesting question:
What signal would you absolutely NOT trust?
We're building QEVRA, and we'd genuinely like to hear how developers think this problem should be solved.
Top comments (0)