One Sunday, a little after midnight, one of our applications went down. No alert, no notification, nothing. No tool was monitoring the service around the clock. We found out the next morning, from a message a user sent us, not from our own systems.
Moments like that never repeat themselves the same way twice. The first time, you fix the bug. The second time, you ask a deeper question: is the real problem this specific bug, or the way you build products in general?
At Kolixia, that was the turning point. And it changed how we launch every product we build.
The problem with infrastructure built project by project
Before, every new product started from zero: new hosting to configure, a new database to set up, a new security certificate to install, and, most of the time, no continuous monitoring until someone found the time to add one, one project at a time.
On paper, that works: each application is independent, isolated, nobody depends on anyone else. In practice, it means redoing the same work at every launch, taking the same security risks every time someone has to think it through again from scratch, and, worst of all, discovering problems after the fact, often from the people using the product, just like that night.
This is not a question of skill. It is a question of structure: treating every project as an isolated island works fine for a single product. It becomes unsustainable the moment you run several at once, while still adding new ones.
A shared foundation, not infrastructure per product
The decision we made at Kolixia was simple to state, harder to commit to: stop building infrastructure product by product, and build one shared technical foundation that every product plugs into.
In practice, everything runs on a single server organized around three pillars that communicate with each other, plus an application layer where our products live.
The routing pillar is the front door: every request coming from outside passes through it before being routed to the right product, with security (SSL encryption) handled in one place instead of reconfigured at every launch.
The data pillar centralizes storage: the databases and cache for every product live here, with one consistent way to back them up, secure them, and evolve them, instead of a different setup for each application.
The monitoring pillar watches everything continuously: this is exactly what was missing that Sunday night. Today, an outage, a slowdown, or an anomaly triggers an automatic alert, so we find out before our users do, not after.
On top of these three pillars, our products (Woryu, Watcher, Space, Tickety) each run independently, but all rely on the same proven foundation.
For the curious: behind those three words (routing, data, monitoring) sit real tools, each chosen for what it does best. Traefik routes traffic to the right product and manages our security certificates. Postgres, Redis, and Neo4j store and cache the data for each application. And about a dozen monitoring tools (Prometheus, Grafana, Loki, and others) work together to give us a complete view of what is happening across our servers at any moment, not just when something breaks.
What this changes in practice
The most visible benefit is speed: launching a new product no longer means rebuilding an entire infrastructure. It simply plugs into a foundation that already exists, is already secured, and is already monitored. The next product we launch will take a fraction of the time the very first one took.
But the most important benefit is for the people who use our products every day. Shared, continuously monitored infrastructure means:
- incidents detected in minutes instead of hours, or instead of waiting for a user to report the problem;
- security handled consistently across every product, rather than reinforced product by product whenever time allows;
- reliability that improves with every new product, since each one benefits from the adjustments made on the previous ones, instead of starting over with the same blind spots.
In other words, this is not a technical choice that stays behind the scenes. It translates directly into fewer service interruptions, faster problem detection, and a stronger foundation for every new product we build.
Proof, not a promise
Today, more than three products already run on this shared foundation (Woryu, Watcher, Space, and Tickety), each with its own needs, all monitored and secured the same way. This is not a theoretical architecture: it is what runs our products right now, at every moment you use them.
And this foundation is not set in stone. Every new product that plugs into it tests it a little further, and every improvement we make benefits every product already in place immediately, not just the newest one. That is what lets us say our next product will be more reliable from day one than the very first one was.
And we do not intend to stop there. In the coming weeks, we will publicly walk through every piece of this infrastructure in detail: the decisions we made, the compromises we accepted, and the improvements still in progress to make it even stronger. Because we believe a reliable product is also one whose foundations you can explain without hiding anything.
Curious about the technical stack behind one of the products you use? Let us know, that is exactly how we choose which topics to cover next.