Before we launched the high-velocity engine that powers QuickBridge today, we spent years iterating, failing, and learning. As we move fully into our “v3” era, we wanted to take a moment to look back at the versions that got us here.
Engineering is rarely about building the “perfect” system on day one; it’s about building the system that solves today’s problem while learning how to solve tomorrow’s.
v1: The “Humble Monolith” (2022–2023)
In the beginning, QuickBridge wasn’t a “platform.” It was a specialized tool built to solve a single, painful problem: getting data from one specific hotel system into QuickBooks Desktop in Uganda.
The Setup
- The Tech: A single Windows Service built on .NET.
- The Storage: A simple database with one main table that stored “objects”—essentially anything from a guest stay to a laundry bill.
- The Philosophy: “Just make it sync.”
Why it worked then
It was fast. Because the code and the data were in the same place, there was zero lag. We could tweak a line of code and see it affect a sync instantly. It was the ultimate “MVP” (Minimum Viable Product).
The Breaking Point
As soon as a second hotel asked for the same service, v1 started to crack. It wasn’t built for “tenants”—it assumed it was only ever talking to one company. If we wanted to update the code for Hotel A, we risked breaking it for Hotel B. It was a monolith that had outgrown its home.
v2: The “Enterprise Platform” (2024-2025)
By early 2024, we knew we needed to grow. We moved from a single service to a multi-layered platform designed to handle hundreds of companies at once.
The Setup
- The Tech: A split system. A Django (Python) “Bridge” managed the users and settings, while a Node.js (TypeScript) “Tunnel” handled the heavy lifting of moving data.
- The Philosophy: “Scale through structure.”
- The Innovation: We introduced Organisations and Connections, allowing us to manage different clients under one roof securely.
Why it worked then
v2 was a massive leap forward in reliability. For the first time, we had a beautiful dashboard (the Portal) and a clear way to see every sync as it happened. It allowed us to expand into laboratory systems, hospitals, and e-invoicing (EFRIS).
The “Complexity Tax”
However, v2 introduced what we now call the “Complexity Tax.” Because the system was split in two, the “Tunnel” had to constantly call the “Bridge” to ask for permission.
- Context Switching: Our team had to jump between Python and TypeScript codebases daily.
- Data Bloat: We were storing every single record in our database before sending it to its destination, which made our database heavy and expensive to run.
The Lessons That Built v3
If v1 was about speed and v2 was about structure, we realized that for the next phase of African enterprise integration, we needed both.
We took the multi-tenancy lessons from v2 and the “lean and mean” spirit of v1 to build QuickBridge v3. We dropped the dual-language setup, removed the database middleman, and focused on a single, high-speed execution path.
Every sync we run today stands on the shoulders of those early v1 and v2 systems. They weren’t just versions of software; they were our most valuable periods of learning.
To see what came next, read QuickBridge v3: A Faster, More Reliable Platform — a breakdown of the architecture we shipped and what it means for your operations.