I remember having that one specific pair of Sunday clothes: a Kaunda suit with Safari Boots. In fact, if a sniper wanted to track me down, he would just do it on a Sunday; I was always in the exact same outfit and shoes. We also rotated between a Baptist church and an Anglican one back when Anglican was called CPK. In the Anglican sanctuary, the vestry felt like holy, out-of-bounds ground. The bishops and vicars in their ornate robes looked as if they had a direct phone line to God. In our diocese, Mt. Kenya South, I only saw the Bishop once in my entire lifetime there. When he was coming, those of us who were in the brigade had to prepare songs weeks in advance.

Later, in my late teens and early 20s, I joined a well-known Pentecostal church. The robes were gone, but they were replaced by pastors in sharply tailored suits, complete with silk lapels and pocket squares. There I was, standing in my second-hand jeans, feeling the weight of the “performance.”

The Systems of Sunday

What has been the output of these performative Sundays? As someone who has spent over 15 years in tech, I tend to look at the world through the lens of systems and architecture. If a system isn’t producing the desired output, you have to audit the design.

Recently, I’ve been auditing my own spiritual life, specifically the contrast between growing up with and attending high-production Sunday service, “Viva ” ( a mid-week community group with individuals from different churches) that met close to a decade and a midweek expositional Bible study I joined at the start of last year called Deeper.

Acts 2:42 “And they devoted themselves to the apostles’ teaching and the fellowship, to the breaking of bread and the prayers.”

Most Sundays across Kenya, we spend about a third of the time on “Praise and Worship.” There are lights, sharply dressed officials, and those lightly pressed piano tones during the prayers — a change in intonation and pronunciation of words with a somber feel — all designed to drive a heightened sense of the “Presence of God.” But I have to ask: Didn’t the curtain split in two? If the veil is gone, why are we still building formats that suggest God is only “reachable” through a specific emotional atmosphere to draw Him near, a sharply dressed mediator, or worse — that these actions are us calling for Him to come down? Isn’t He Emmanuel?

The Wednesday Contrast

The contrast with Viva and my Wednesday session is jarring in the best way possible. People show up in hoodies, T-shirts, and jeans. We don’t have a professional worship team; we have a single song to gather us together and start.

The format is simple: we follow a manual with scriptures to read that we’ve studied all week, we meet in small groups to discuss our weekly learnings, and then the teacher explains the context, meaning, and application almost line-by-line. This expositional style has had a more profound impact on my behavior and my relationship with God than decades of Sunday “checklists.”

Small Groups vs. Mega-Churches

This brings me to the heart of the matter: Community Groups. If a church doesn’t have a thriving network of small groups, it’s likely just grooming nominal Christians. Community groups are where we actually commune, read the Word, and discuss how it hits our real lives. If the heart of a church is small groups, sitting at the feet of a teacher and engaging in fellowship, do we actually need mega-churches? Do we need three services? Voddie Baucham famously said that if you have three services, you have three churches. I saw this firsthand last year when we switched from the 10:00 AM to the 8:00 AM service. After a decade at the same church, it felt like we were walking into a room of strangers.

The Nominalism Trap

The biggest question our churches need to answer is: Does our current format promote nominal Christianity? Does the current format seek to solve sustainability from a financial point or to serve the lost? Are mega-churches Biblical? Is aspiring to be a mega-church godly? Is Sunday being a 90-minute “morality reset” session promoting nominalism?

It is easy to get a “morality reset” on Sunday because you had an emotional response to a deep worship song. But if that Bible stays in the glove compartment until the following Sunday, did anything actually change? A format that centers on a “weekly cleansing” is a poor substitute for a daily walk with a God who is with you on Monday morning, convicting you and guiding you.

My brother and sister recently attended a session at a Christian organization where the teaching wasn’t even aligned with basic Christian doctrine; we’re talking foundational truths like the Trinity and Salvation. When we prioritize the “feel” of a service over the “truth” of the Word, we leave the door wide open for doctrinal drift.

Final Musings

I am just a tech guy whom Christ is working on daily. But my experience has been this: a format that centers on God’s fellowship and expositional teaching has a direct, profound impact on my daily thoughts.

We don’t need the “cladding” or the stage lights to find God. We don’t need the performance. We just need to sit at His feet, together, no performance, and let the Word do the work.

For a decade, the recipe for startup success was simple: find a manual process, build a clean interface, and charge a monthly subscription. But as Artificial Intelligence turns sophisticated coding into a commodity that can be replicated in a garage over a weekend, the industry is facing a mid-life crisis.

The new mantra for survival is as unsympathetic as it is clear:

Distribute or Die, Get Data or Die.

The Death of the “Feature” Moat

For years, “the product” was the moat. If your software had better features or a slicker UI, you won out. Today, that advantage is a mirage. When an LLM can generate a functional clone of a platform’s core logic in days, the “software” part of Software-as-a-Service has been devalued to near zero.

The barrier to entry hasn’t just been lowered; it’s been obliterated. If you built a platform that just consumes data from other sources, you aren’t a business; you’re a tenant on borrowed time.

The Sovereignty of Data

The industry is seeing a pivot toward “Data Residency.” The survivors of this era won’t be the ones with the prettiest dashboards, but those who control the “Source of Truth.”

By finding a niche, whether it’s prop tech, agri tech, or fin tech and ensuring that the critical data is generated on and resides within the platform, founders are building digital fortresses. This is why “Hardware + Platform” models are seeing a resurgence; they create a physical anchor that a solo developer with an AI prompt cannot replicate.

The Distribution Flywheel

Even with proprietary data, a product is a ghost if it isn’t everywhere. The shift from “SaaS as a tool” to “SaaS as an ecosystem” is the final piece of the puzzle.

The goal for modern founders is to become so deeply embedded in a user’s daily workflow that the “switching cost” isn’t just about moving data, it’s about changing how they think and work. Distribution in 2026 isn’t just marketing; it’s the ability to scale “like fire” by being the oxygen in a specific niche.

Why Build at All?

If the era of pure SaaS is dying, why are startups still hitting post-revenue milestones within months? The answer is simple: The problem still exists.

Our platform, Impactio, is already live and post-revenue, built in a matter of weeks. But even with that traction, we find ourselves in a constant wrestling match with the two titans of the AI era: Distribution and Data.

People don’t buy software; they buy the resolution of pain. In an AI-driven world, the winners are those who use AI to solve that pain faster while aggressively guarding the two things AI cannot yet manufacture: deep, niche-specific data and a locked-in distribution network.

In this high-stakes environment, the message to founders is clear. If you aren’t controlling your data source and you aren’t dominating your distribution channel, you aren’t building a company, you’re building a ghost.

Engineers on the ground saw it happen. They were worried. They even requested satellite imagery from the Department of Defense to see the extent of the damage. But NASA’s leadership — high on past successes and pressured by a rigid launch schedule — shut the request down.

Why?

Because the culture had become one of “normalization of deviance.” Small errors had happened before without catastrophe, so leadership assumed they would be fine again.

More importantly, the culture was so hierarchical and “blame-heavy” that lower-level engineers felt they needed “perfect proof” before they could challenge a manager’s decision. They chose to stay silent rather than risk being “the person who delayed the mission.”

The result was catastrophic. On February 1, 2003, as Columbia re-entered the atmosphere, the superheated gases penetrated the damaged wing, leading to the total destruction of the vehicle and the death of all seven crew members.

The shuttle didn’t fail just because of the foam; it failed because the people inside the most advanced technical organization on Earth were afraid to talk to each other.

Walking Through the Door

I’ve been involved in a number of digital transformation projects over the last few years as a CIO and a Consultant. I’ve learned that I don’t need to look at the code or the project timeline to know if they will succeed. I just have to walk through the door and engage with the staff.

You can feel the “cultural temperature” instantly.

• In failing projects, people are defensive. They ask about “accountability” and “who is responsible if this breaks.” They attribute failure to a person or a department.
• In successful projects, the team is obsessed with the goal. They talk about “what we discovered” and “how we adjusted.”

If an organization views an error as a crime rather than a data point, they have already failed.

SpaceX : Fail Fast First

Contrast the Columbia with the modern era of SpaceX. When Elon Musk’s team was preparing their first engines for space, they didn’t aim for a “perfect” first run. They aimed for a “fast” first failure.

Recently, we witnessed the automated landing of a massive ship — a feat of engineering that once seemed impossible. This wasn’t achieved by a team that feared mistakes. It was achieved by a culture that embraced failure as the only way to learn. At SpaceX, an explosion isn’t a “fireable offense” — it’s a “Rapid Unscheduled Disassembly” that provides the data needed to win.

They were ready to fail while learning because they knew that the best technical team and the best project managers are useless if the culture at the heart of the company doesn’t embrace failure as a lesson.

Why Tech Progress in 2026 Won’t Save a Bad Culture

We are now in an era of Agentic AI and hyper-automation. The speed of change in 2026 is ten times what it was a decade ago. This speed acts as an accelerant:

1. If your culture is healthy, technology makes you invincible.
2. If your culture is weak, technology just helps you hit the iceberg faster.

Hard Truth

Blame Based Culture is the greatest threat to your digital roadmap. You can hire the best techies and buy the most expensive digital solutions, but if your staff is afraid to tell you that the “iceberg” is dead ahead, you will sink.

Digital transformation is less tech driven and more people driven.

If you want to succeed in 2026, stop looking at tech first, putting AI on every slide and start looking at how your team handles a mistake. Do they hide it, or do they learn from it?

The answer to that question is the only project metric that actually matters.

So, why did I walk away? I have been asked these questions multiple times since I started this new chapter. I see it in my LinkedIn profile views, curious followers curious to see what’s next.

This isn’t a story about elevating startups over corporates as a self-accomplishment badge; that’s far from the truth because the failure rate for startups is significantly high. It’s a story about a relentless bug that bit me many years back, which drove me to startups. It’s about recognizing that the skills I had spent years acquiring in a stable, predictable environment were meant to be used on something far more volatile: a startup.

I’m also writing this because I know of countless people who are trapped in the quiet comfort of their career, waiting for permission to chase that thing that keeps them up at night. This life is too short for you not to live and experience it. This is the full, unvarnished story of moving from running experimental code on the shared university computers to running a successful department, and finally, to making the jump to madness.

Escaping the C-Suite

My journey into building didn’t start in a boardroom; it started in my second year at Kenyatta University, driven by sheer frustration.

My friend Lenny and I, like most Computer Science students, were drowning in the low-level complexity of Java, C++, and C. We were exhausted by the overhead. We needed a higher level of abstraction — a way to develop apps faster and actually explore programming concepts. We experimented with everything, especially the scripting languages: Perl, Ruby, and then, Python. By our third year, we had fallen completely in love with Python and the Django framework. That speed and simplicity was a revelation.

That same year, I participated in my first Google competition using Google App Engine (GAE) (a Python-based framework), hoping to win an HTC phone. The real win, however, came soon after in the form of a plugin.

Early Failure and the Unlikely Hero: A Plugin

During my internship, my friends and I registered our first business. It was a dramatic failure. We learned harsh lessons about co-founder compatibility, market fit, and team execution, but the learning was invaluable.

I later continued solo, building BeiYaJioni.com in 2010, an app designed to help people sell thrifted goods affordably. My competitor was the established Kalahari. Unfortunately, despite the passion, BeiYaJioni.com failed as well.

I then developed a simple but robust conference registration and abstract submission plugin. Two medical societies adopted it and put me on a retainer. That small, recurring payment was the first taste of validation. The entrepreneurial bug had officially bitten me.

Here’s the thing, though: even as the big ideas crumbled, the small, quiet income from my plugins and retainer clients was still flowing. It proved a vital principle that never left me: always keep building on what works, even if it’s small.

Learning to Build at Scale

A few years later, I had taken up roles at various organizations, but two were key: a frontend developer at an American e-commerce company that had an offshoot office here in Nairobi, and later, a role as a systems developer which ended up with me being the CIO at one of the leading hospitals in Africa by 2018.

The work was intense, but I genuinely loved the challenge. Because of this new intensity, I couldn’t support my web plugin clients anymore and managed them out slowly. I was quite fortunate to grow rapidly, eventually ascending to a position where I had genuine influence on strategy, access to budget, and the ability to build and lead a team. Solving problems, building systems that worked, and getting support from fellow managers became the most satisfying part of my time there.

My work was to oversee the team that would build and deploy applications at a corporate scale, both application and infrastructure, serving over 800 staff across the entire country with thousands of customers daily.

The Predictability That Became a Problem

I loved my job, but after a time, it became predictable. The challenges were structured, the risks were contained, and the environment was familiar. It had been ten years and ten months, five years of which I had been the CIO.

We had migrated the production environment; successfully upgraded our core Financial ERP twice; centralized our channels to an Omnichannel; successfully rolled out a new HR Management System; migrated the entire network to SD-WAN and to Microsoft 365; met stringent international hospital compliance requirements; integrated Single Sign-Ons; and rolled out Telemedicine to remote sites across Kenya. We also won a few awards at the CIO100 Africa awards, all while having fun at work.

But that bug, that same bug — the one that bit me with Python code years ago — was always there, nagging.

My time in corporate gave me the skills I needed: I had grown, failed, and succeeded; I had grown passionate about building teams and solving problems in a sustainable way.

Now, I looked around our African space and saw a host of real problems that needed to be validated, explored, and solved. I had come to appreciate the value of building on the move — iterating and adapting quickly.

The predictable stability could no longer compete with the unpredictable, high-stakes satisfaction of starting something entirely new. I realized my next, most satisfying challenge lay not in a stable environment, but in the exhilarating chaos of the startup.

It was the end of our financial year, July 2023. The organization was highly functional and very successful, but unfortunately, everything had now become routine to me. During a meeting that very month, I knew I was going to resign. It was so surreal. I had my own personal goals; I knew that I would resign at one point to pursue my next chapter. But that moment, during that meeting when I realized I was going to resign, was surreal. Part of me didn’t want to leave. I enjoyed the work, the team, the team banter, management, and board support, and I had one huge pending project that I really wanted to see through. It was a difficult decision that took months to make. I read my Bible, prayed, met with peers who had taken the jump, listened to several podcasts (Rob Walling — Startups for the Rest of Us Podcast), and during a long road trip with my family, the decision was sealed. I drafted my resignation letter in December 2023 and submitted it in mid-January 2024. A really exciting and satisfying phase in my career had come to a blissful end. I left with good nostalgic memories and friendships for a lifetime.

I finally let go of corporate because I had grown into the person who needed to be a builder again.

I have been in the tech space for over 15 years, getting opportunities to work in startups, NGOs, Federations, and later having the privilege of serving as the Chief Information Officer at one of Africa’s largest children’s hospitals. I was involved in several digital transformation initiatives, product rollouts, and partnerships with incredible institutions like Safaricom Foundation, M-Pesa Foundation, IFC, and Cisco Foundation. All of these chapters, including the work of leading policy changes as Chair of the Digital Health Committee at the Kenya Healthcare Federation, were intensely focused on leveraging technology to transform patient clinical outcomes and experience.

But that was only one part of the journey. While my focus was on digital health for a long time, my passion has always been for one thing: driving impactful technology solutions to address Africa’s unique challenges.

The lessons from deploying digital health are surprisingly universal — they’re mission-critical lessons that I’ve taken into my current ventures.

Today, I’m the Co-Founder of TruSource.io, a platform that tackles the critical challenge of cold chain logistics and compliance for agricultural goods. It’s a move from one life-critical sector (health) to another (food security and supply chain), applying the same rigour I learned in the digital health space to agriculture.

TruSource is what keeps me up at night; it’s my 8 to 5 (more like 8 to midnight).

Separately, I’m also currently the Managing Partner at Pictus Labs, a Technology Lab, and a Founder in Residence at Antler Kenya.

Why the Technology Lab?

I get requests to consult from time to time regarding process engineering and digital transformation. Pictus Labs has given me a front seat to digital transformation and process engineering for a diverse mix of sectors, including healthcare, hospitality, and NGOs. This is my space for raw, real-world learning, where I specialize in:

• Problem and Solution Validation: Helping startups and organizations avoid costly mistakes by rigorously testing their assumptions before rolling out platforms to the market or picking up a solution from the market.
• Startup Advisory: Guiding founders through the tricky process of developing minimum viable products (MVPs) and successfully launching their platforms.

Sharing thoughts, successes and failures

My current and previous roles (Software Engineer, Chief Information Officer, Digital Health Leader, Co-Founder, and Managing Partner ) gave and give me a daily view of the African tech landscape, from large-scale enterprise implementation to early-stage startup chaos.

Now, I want to use this platform, Medium, to go beyond the job titles and share the unvarnished truth of the journey:

• The CIO’s Playbook: What are the real-world, non-obvious lessons from leading a massive digital transformation? I’ll share how we navigated policy, internal funding, tech upgrades and managing change.
• The Pivot to Founder: The transition from enterprise leader to startup co-founder is brutal and brilliant. I’ll share the successes, the failures, and the complete mindset shifts required to build a startup even as I daily navigate it, albeit with naivety at times 😂.
• Lessons from the Lab: Insights from my consulting work with Pictus Labs on what truly makes a digital transformation successful or a dismal failure.
• Vulnerable Lessons: My own thoughts on leadership, managing imposter syndrome, balancing strategy with execution, and the specific hurdles technology entrepreneurs face on the continent.

This is a space to share the lessons I’m learning now and the lessons from the past 15 years. Whether you’re a founder, tech executive, investor, a software engineer, a student or just someone passionate about technology’s role in Africa, I invite you to follow along.