A life in software: my journey from overbuilding to Kaamfu

From my earliest experiments in programming at age ten, I was never satisfied with what I built. Each project felt like a fragment of something larger that I could not yet complete. As a financial auditor, I created early dashboards, then spent years documenting imagined systems in notebooks, convinced they were connected. Through Prospus I overbuilt, experimented, and learned, eventually realizing most software rests on shared foundations. By 2015 I called this vision the digital body, awaiting its digital brain. With Kaamfu, decades of fragments finally converged into one end to end system that brings that vision to life.


For as long as I can remember, I’ve been building. It started with Legos, using every piece in my box to build until I ran out of pieces. My first experiments in programming started at age 10, and from that moment forward, I was never satisfied with what I made. Every piece of code felt like a fragment of something bigger, some grander system that was always just out of reach.

I was never satisfied with anything I built because the thing in my mind was always so much greater than anything I could achieve.

That restless pursuit of “something greater” shaped the entire course of my life. What began as small personal projects at home soon spilled into school assignments, where every simple requirement became a launching pad for something vast. A basic menu program became the menu of all menus. A small game ballooned into the most ambitious and complex I could imagine. I created countless imagined worlds where these systems existed fully in my mind, though only fragments ever materialized in code. It wasn’t for lack of interest or energy; it was that the visions always outpaced the time, tools, and resources I had at that age.

Early Experiments: Project Now

My first serious attempt at bridging business processes with software came in the late 1990s while I was working as a financial auditor for a large restaurateur. I had access to a treasure trove of operational data spread across dozens of locations, but it was locked inside fragile systems and siloed networks. The internet was still in its infancy, networks were unreliable, and pulling data together across sites was a complicated and time-consuming process.

Out of that challenge came a tool I called Happy President. It was essentially a dashboard designed to unify information across all of those restaurants and deliver a single view of the business in real-time. The execution was clumsy, stitched together from Jet databases, Excel spreadsheets, and a series of manual transformations. But even with those limitations, I saw the potential of taking fragmented data and turning it into live, actionable insights. For me, the critical word was always real time.

That experiment evolved into a body of work I called Project Now. Over time, it became less about functioning software and more about documenting ideas for imagined systems. I carried notebooks everywhere and often spent entire days in Starbucks writing, diagramming, and trying to capture pieces of a future architecture. Many of the ideas seemed unrelated, sometimes even contradictory, but I was convinced they were connected. I did not yet know how they fit together, only that they did.

For several years, this practice consumed me. Writing was not coding, and it did not produce working systems, but it allowed me to record the extraordinary scope of a globalized, interconnected system of work I was imagining. It was exciting and frustrating at the same time. I knew I was circling around something larger, something that connected data, business processes, and software into a coherent whole. I simply had not yet built the tools to bring it fully to life.

Writing is not coding. Writing is not building a system. Writing is just writing. And that was endlessly exciting and endlessly frustrating.

When I discovered UML (Unified Modeling Language), it shook me deeply. For years I had been scribbling diagrams, sketching flows, and trying to capture a universal language of systems that could connect ideas across business and software. Then, almost overnight, I found out that a polished, corporate-backed version of what I was imagining already existed. To me, it felt like someone else had built the very thing I had been striving toward in obscurity.

The realization was devastating. It seemed as if the ground had been pulled out from under me. All the nights spent filling notebooks with ideas, all the conviction that I was onto something unique suddenly felt redundant. I began to wonder whether there was any point in continuing.

So I walked away in 2021, dejected. I set aside the identity I had carried for nearly a decade that I would one day create this great system. I left the United States and spent time wandering around in Mexico and then India, searching for something else to hold onto. For a while, I thought I had abandoned that dream forever. It was painful, almost like grieving the loss of a part of myself.

But even in that distance, the ideas never truly left me. They lingered, waiting for the right time to return.

Building Through Prospus

A few years later I began to feel the itch again, and in 2010 I returned to building software with a new company: Prospus. This was my chance to take the fragments of unfinished ideas that had accumulated over the years and put them into practice in a real business setting. From the very beginning I found myself overbuilding, not only in the code I wrote but in the way I structured processes, systems, and even the rules that governed how we operated.

Every project became a kind of testbed. If a client needed a specific tool, I would design subsystems and embed small experiments inside it. If the company needed a process, I documented it in exhaustive detail and refined it until it became a framework of its own. Hiring workflows, project management methods, and reporting systems all became mini laboratories where I could explore how software could not only serve a purpose but also reveal new possibilities.

By the time the SaaS boom began to accelerate around 2010 to 2012, Prospus was already running on a custom-built internal project management platform. It handled everything from project tracking to time logging to day-to-day operations. It saved us significant costs by removing the need for third party tools, and more importantly, it gave us access to rich streams of operational data. I always believed the real value was in the insights that could be drawn from that data, though at the time I could never quite mine them the way I envisioned.

Of course, this habit of overbuilding did not go unnoticed. Some people questioned why I kept creating tools when off the shelf solutions already existed. But the truth is that I was not only focused on delivering software. I was studying the scope of each problem, testing its boundaries, and learning its true shape by building around it. In hindsight, that period was less about producing finished products and more about continuing the apprenticeship I had been in since my earliest experiments: learning how to see problems clearly by attempting to solve them in code.

I was learning. I was studying the problem, the scope. I was defining the scope of the problem, and I was building solutions for it.

What I Learned at Prospus

Those years of building and experimenting at Prospus taught me lessons that shaped everything that came after. By working across hundreds of projects, embedding experiments into client work, and running our own internal platforms, patterns began to emerge.

  1. Most software is built on the same foundations. Across industries and functions, I noticed that the vast majority of SaaS solutions shared the same core components. Whether it was project management, time tracking, collaboration, or reporting, I was rebuilding the same pieces again and again, just wrapped in slightly different use cases.
  2. Workers live in scattered systems. The average knowledge worker spends nearly all of their time inside 10 to 15 solutions. Switching between them hundreds of times a day is exhausting, inefficient, and expensive. I saw firsthand how much mental fatigue this constant context switching created, and how much productivity was lost.
  3. SaaS success comes from simplification. When I studied the breakout SaaS companies that became unicorns, most of them succeeded not by inventing entirely new categories, but by simplifying existing ones. They offered cleaner interfaces, more intuitive workflows, and better user experiences around the same shared components.
  4. Knowledge work suffers from fragmentation. Even inside our own company, we could see how much time was lost to “work about work”: searching for information, managing communication, and trying to stitch together scattered tools. The data was clear: efficiency losses of 40 percent or more were common, simply due to fragmented systems.

My takeaway was simple. If most tools share 90 percent of the same components, then the real opportunity is not to keep rebuilding them in isolation, but to create the foundation they all rest on. A single environment with shared components could concentrate 90 percent of a manager’s activity in one place, eliminating the fatigue of constant switching and the waste of redundant effort.

That realization became the conviction that shaped everything that followed: the future of work does not belong to fragmented apps, but to unified environments that reduce friction, reuse components intelligently, and place real-time data and insights at the center of business.

The Inventor’s Lab

Looking back, I see that entire decade as an inventor’s laboratory. I was not just coding; I was experimenting with business processes, philosophies, product marketing, and real time data systems. Every subsystem I built felt like a fragment of a larger whole that I could not yet fully see.

By 2015, I finally had language for what I was doing. I called it the “digital body”: a structure of software, processes, and components that could replicate the tight integration of a biological body, but for an organization. But just like a body without a mind, it was incomplete. What it needed was the digital brain: the artificial intelligence that technologists everywhere had been anticipating but which had not yet arrived in a usable form. I knew then that much of what I was building was waiting for that missing piece.

In 2016, I launched Prospus Universe, my most ambitious attempt to connect all of these components into a single system. It was an early version of what I had imagined the digital body could become, but by 2017 the project had collapsed under its own weight. The failure was instructive, showing me not only how difficult it was to unify everything too soon, but also how valuable the attempt was. Like many of my earlier failures, it left behind patterns, lessons, and unfinished fragments that would later resurface with greater clarity.

Between 2011 and 2019, across Prospus client work and internal projects, I built hundreds of components across dozens of enterprise systems. Each one was like an experiment in the lab, testing the limits of workflow automation, system integration, and process design. Looking back, I see that period less as a string of disconnected efforts and more as the construction of a laboratory, an environment where I learned piece by piece how the digital body could one day come to life.

From Fragments to Kaamfu

In 2021, after years of building and rebuilding, I started again cautiously. What began as another round of experimentation slowly gathered momentum, and by 2022 the product that would become Kaamfu began to take real shape.

I realized that Kaamfu was not just another software project. It was the culmination of everything I had been experimenting with for decades: the fragments scribbled in notebooks, the prototypes left unfinished, the subsystems embedded in client work, and the endless documentation of imagined architectures. For years those efforts felt disconnected, like scattered pieces of a puzzle that never seemed to fit. But over time the patterns became clearer. The fragments were not random. They were rehearsals. They were the early sketches of something that needed time, experience, and maturity to come together.

What once seemed impossible to complete has now aligned into a sharp and coherent structure, like the four corners of a pyramid that finally come together at the apex. Each tier of the pyramid represents a stage of that journey: experimentation, learning, overbuilding, failing, and beginning again. At the top sits Kaamfu, the point where it all converges.

All at once, everything came together because I had already rehearsed every single part of it: the software, the business and revenue models, the user experience, the distribution model, and the product itself.

All at once, everything came together because I had already rehearsed every single part of it. The software. The business model. The revenue strategy. The user experience. The distribution channels. The product vision. Every element had been practiced, tested, broken, and rebuilt in one form or another. When the time came, I was not starting from scratch. I was assembling something I had been preparing for my entire life.

The End-to-End Story

Looking back now, I can see the throughline that was invisible to me for so many years. Programming, software development, data insights, business processes, SaaS, project management, and automation. All the fragments that once felt scattered were never random. They were rehearsals for what I am building today.

Kaamfu represents not just a piece of software, but the entire lifecycle of work itself. It carries within it the philosophy that drove me to keep pushing, the architectures I imagined in countless notebooks, the experiments I built in code, the business models I tested, the automation frameworks I created, and the distribution systems I refined. It is the sum of decades of writing, experimenting, failing, rebuilding, and trying again.

To others, those years may have looked like a series of disconnected projects, side paths, or false starts. But I see them now as a long apprenticeship in learning how to build systems end to end. Each fragment had a purpose. Each fragment taught me a lesson. And when the time came, those fragments converged into something whole.

Kaamfu is that convergence. It is the embodiment of the digital body I envisioned years ago, now animated by the digital brain that has finally arrived. It is the moment when all of the fragments, all of the drafts, all of the rehearsals came together into one pointed structure.

That is the journey. From the menu of all menus to Kaamfu, the place where every fragment, every experiment, and every imagined world finally found its home. And this time, the vision does not outpace the tools. The tools have caught up, and the work of a lifetime can finally be built.

Every organization is in the race to autonomy

Autonomization is not a distant future. The race is on, and the organizations preparing today will be the ones that win tomorrow.

Join my newsletter

Industry news is everywhere. Join my newsletter for practical insights on what to prioritize inside your organization to be ready for what’s happening.