If you told me back in 2014 that an idea for helping CD collectors would eventually become AI infrastructure, I probably wouldn't have believed you.
But looking back, the path actually makes sense.
Also, fair warning: this is a pretty personal story. It’s less about features and more about how an idea slowly evolved over time.
It started with a duplicate CD
Back in 2014 I was visiting a friend.
His father is a serious CD collector. Thousands of CDs.
One evening he came back home, and a minute later we heard lots of shouting and a few colorful words coming from the living room.
He had just bought a CD he already owned.
Again.
Later during dinner he said something that stuck with me.
"What if there was an app for a phone? Something more handy than keeping everything in Excel on those smartphones. Just something to quickly track my stuff and know what I already have."
At that point I wasn't a software engineer.
I worked in IT support and occasionally built WordPress websites.
So naturally I thought:
"That shouldn't be too difficult."
(I guess most burnouts started with the exact same thought)
It turned out to be one of the hardest problems I've ever worked on.
The problem wasn't storing data
Initially I thought I was building software for collectors.
Then I started talking to collectors.
That's when I realized the actual problem wasn't collecting things.
It was that everyone thinks about their collections differently.
One vinyl collector organizes records by pressing year. Another by matrix numbers. Someone groups everything by country. Someone else keeps collections inside collections. Others care more about stories and memories than metadata.
Every time you introduce a predefined schema, somebody immediately becomes constrained by it.
I didn't want software that tells people how they should organize their collections.
I wanted software that adapts to how people already think.
Around that time, I also realized this wasn't just an abstract problem for other people. In my own family, collecting has always been a generational thing: poststamps, minerals, coins, vinyl records. My dad is a true metalhead with his own carefully curated collection. That made it clear to me that this idea shouldn't be limited to CD collectors. The goal naturally evolved into something broader: a system that could serve all kinds of collectors at once, regardless of what they collect or how they think about it.
The goal became surprisingly simple to describe:
Let people organize, group and nest information however they want.
Then somehow make that information searchable, traversable and filterable as if somebody had spent months designing a perfect relational schema.
Marketplace-style facets.
Dynamic filters.
Relationships.
Exploration.
Without manually defining any of them.
This was before the tools we have today
Today we have Notion.
Airtable.
Flexible databases.
AI.
And, of course, vibe coding.
Back then, none of that existed.
I started building a WordPress plugin called Collect.
Very quickly I realized I had absolutely no idea how to build the system I had in my head.
So I abandoned it.
A year later I came back.
Then abandoned it again.
Then rewrote it.
Then forgot about it for another year.
Eventually I accepted that solving this problem required becoming a much better engineer than I was at the time.
Looking back, this project is probably one of the main reasons I became a software engineer.
The problem kept following me
Years passed.
I worked on different products, backend systems, distributed infrastructure and AI.
But every time I returned to Collect, I noticed the same pattern.
Collectors weren't unique.
Everyone produces messy data.
Companies do exactly the same thing.
REST APIs return arbitrary JSON.
Mongo collections drift over time.
Relational schemas evolve.
Documentation becomes outdated.
Every organization ends up accumulating semi-structured information.
Everybody wants flexibility.
Everybody still expects fast search, filtering, analytics and navigation.
The collecting problem wasn't a collecting problem anymore.
It was a data problem.
At this point, attentive readers might reasonably ask:
"Wasn't MongoDB designed exactly for this kind of uncertainty?"
And that's a fair question I asked it myself many times during this journey.
MongoDB does embrace flexible schemas and allows you to store arbitrary structures without enforcing rigid definitions upfront. That part aligns well with the original goal.
But the challenge I kept running into wasn't just storing uncertain data.
It was understanding it efficiently.
Things like cardinality, facets, and dynamic filtering across arbitrary properties become surprisingly expensive. In practice, they often require full scans at query time or some form of precomputed, tenant-specific caching that quickly becomes complex and brittle.
In other words, the schema effectively exists only at read time.
For Collect, I needed something different.
I needed the system to continuously understand the structure of the data as it was being written, so that exploration, filtering, and discovery would feel instant and natural, not reconstructed on demand.
This wasn't about rejecting existing tools.
It was about realizing that the problem I was trying to solve lived slightly beyond what they were optimized for.
Somewhere along the road Collect became RushDB
As the project evolved, I stopped thinking about collections.
I started thinking about data itself.
One observation kept bothering me.
Most databases are very good at storing records.
They're much less helpful when you ask questions about the data itself.
What properties exist?
What schemas are associated with those properties?
How are things connected?
Which attributes are sparse?
What can actually be queried?
Developers answer these questions by reading documentation.
AI agents answer them by... mostly guessing.
That didn't feel right.
If you're curious how this idea eventually turned into something concrete, you can take a look at the project itself on GitHub:
And data write mechanism behind the scenes:
SOCIAL SHARE CARD GENERATOR