Looking back, I sometimes wonder how we made it through those early days at Kakbima. Building a platform to simplify insurance management and distribution single system for policyholders, agents, brokers, micro-insurers, and insurers was already a tall order. But what really tested us was the technology we bet on: GraphQL.
You see, when we decided to adopt GraphQL for our API layer, it had only been publicly released by Facebook three years prior. The ecosystem was young, the tooling immature, and there was barely any local community around it. The only Kenyan company we knew of using GraphQL at the time was Twiga Foods, and they were using it extensively to power their web and mobile apps. Their approach? Schema stitching, an early technique for combining multiple GraphQL APIs into a single API surface. It seemed promising, so we followed suit.
In hindsight, schema stitching was a nightmare.
Our early days with schema stitching
At that time, Kakbima had already evolved into four microservices, each handling different parts of the insurance domain product, policy, claims, and user management. We were using Ariadne for our GraphQL server, primarily because it followed a schema-first approach. That felt like a good fit for us: we could treat the schema as a single source of truth between our React frontend and Python backend.
But stitching these schemas together? That was where the trouble began.
Separation of concerns was poorly defined. The frontend team, desperate to ship features, often had to compensate for backend gaps, handling business logic, transforming data, and patching inconsistencies on the client side. It wasn’t elegant, and it certainly wasn’t scalable.
I remember asking my engineers to attend meetups and developer sessions, hoping they’d find peers wrestling with similar issues. But time and again, it felt like we were the only ones in the local scene pushing this hard on GraphQL. We were on an island, figuring things out as we went. I often look back at the amount of effort, the long nights, the broken builds, and I feel both a deep sense of pride and a bit of guilt, because the team carried so much weight on their shoulders.
Then comes Graphql federation
Just as we were getting buried under the complexity of schema stitching, GraphQL Federation arrived and it felt like the sun finally broke through the clouds. The introduction of Apollo Federation was a turning point, not just for Kakbima, but for the entire GraphQL ecosystem.
Federation meant we could compose a single GraphQL gateway from multiple subgraphs, each owned by different teams and written in different languages or frameworks. This was huge. Suddenly, our backend team weren’t shackled to a single tech stack whether they preferred Python, Node.js, or even PHP, they could build services in the language best suited for the job, and the frontend wouldn’t even notice. We could tear down microservices and spin up new ones without worrying about the API surface breaking downstream.
It felt like a breath of fresh air after months of fighting with brittle, tightly coupled schema stitching configurations.
The power of a schema-first approach
Through all of this, sticking to a schema-first philosophy paid off. Ariadne’s design forced us to treat the GraphQL schema as the heart of our system, a contract not just between the frontend and backend, but between us and our users. This mindset encouraged rigorous schema reviews where engineers, product managers, and designers all had a seat at the table. We weren’t just building endpoints; we were designing a shared understanding of how the platform worked.
Real-time data and subscriptions
Insurance is dynamic, policy statuses change, claims get updated, and new quotes roll in. Our users needed real-time updates, not stale data after a page refresh. That’s where GraphQL subscriptions helped us close the loop.
We integrated subscriptions into key areas: claim approvals, policy status changes, and broker notifications. It transformed the user experience. Agents could respond to clients faster, brokers could monitor their portfolios in real-time, and policyholders felt more in control of their insurance journeys.
Taming complexity
As Kakbima grew, so did the risk of runaway queries. We saw developers crafting complex, nested queries that could cripple the backend if left unchecked. To manage this, we introduced persisted queries and whitelisting, allowing only pre-approved queries to hit our servers. This not only improved performance but also brought predictability and safety to our API layer. CDN-level caching became far more effective, and we could sleep easier knowing we weren’t exposing the backend to unexpected query loads.
Grit, growth, and gratitude
What stays with me most from this journey isn’t the technical milestones, it’s the people.
The Kakbima engineering team showed extraordinary grit. They took on challenges that most in our ecosystem weren’t even talking about. They navigated an immature GraphQL ecosystem, fought through the frustrations of schema stitching, and learned on the fly. When I think of those early days, I feel a bittersweet mix of pride and a sense of responsibility. They carried the weight of an ambitious vision, and they did it with determination and heart.
GraphQL didn’t make things magically easy, but it gave us the tools to grow, to adapt to user needs, to scale, and to build a platform that truly empowers insurers, agents, brokers, and policyholders alike.
