The architecture problem nobody wanted to fix
When I joined the dating company, its infrastructure was… unusual.
One shared database — but as many separate code folders across different servers as there were domains.
Five domains rotated constantly. Directories appeared, disappeared, moved.
To me, as an architect, this felt impossible to scale.
So I suggested we rebuild everything on a unified codebase.
The idea was politely rejected.
But coding is my hobby — not just my job.
So I built it anyway.
A clean, abstracted, white-label solution
The question I asked myself was simple:
What would dating look like if you built it from abstraction — not from legacy?
The answer became Dating.Center, engineered from day one as a white-label engine.
Inside it lived:
-
🧩 my own template machine
-
📍 geolocation baked into the core
-
🔐 a brand-new auth + logic layer built from scratch
-
🌐 multi-domain support
-
🎨 skins and theme overrides
-
🎁 gifts and engagement mechanics
-
🔁 and most importantly — a token system
Tokens replaced micro-payments, discounted features, managed paid chats, and handled every in-app purchase gracefully.
The chat itself worked like early WhatsApp — but fully tokenized.
When the core was ready — I stopped on purpose
By mid-development, all core mechanics were done.
Only front-end refinements remained.
And then something happened:
I realized I was no longer building “a dating engine.”
I was building a system core — something larger than the project itself.
At that moment, Deridex split into two branches:
-
🟦 Tour Rotator — the first branch
-
🟧 Dating.Center — the second branch
And the patterns I saw emerging required far more time, thought, and architecture than dating alone.
Why the project froze
There were several reasons:
-
my fifth year at the company was coming to an end
-
our professional paths diverged
-
the system needed more vision than the project itself justified
-
and — more importantly — I felt something bigger behind it
Not a dating platform.
A foundation.
What truly mattered
Dating.Center never reached full production.
But it shaped the architecture that later became critical inside QRaway:
-
multi-domain logic
-
token economies
-
unified cores instead of scattered folders
-
integrated geolocation
-
templating systems
-
abstracted engines
-
modular expansion
It wasn’t the end of the project.
It was the beginning of an idea.
And everything that followed came from exactly here.
