Staying Motivated, Week 1: The Early Days — The Decision to Start

01The Spark

The idea for TCTF did not arrive fully formed. It started as frustration. Frustration with watching talented African developers struggle to find mentorship in open-source projects. Frustration with seeing the same names on every maintainer list while an entire continent of developers was invisible. Frustration with the gap between the potential and the reality.

Open source is supposed to be open. But when you look at who maintains the major projects, who sits on the governance boards, who gets invited to speak at the conferences — the picture is not as open as the name suggests. African developers contribute. They use the tools, report the bugs, sometimes even fix them. But the leadership roles, the architectural decisions, the direction-setting — that remains concentrated.

Frustration is a powerful motivator — but it is not enough to build something. What turned frustration into action was a question: what if someone actually built the thing that is missing? Not talked about it. Not wrote a blog post about it. Not tweeted about it. Actually built it. Built the platform that connects African developers to mentorship. Built the foundation that funds their open-source work. Built the institution that gives them governance experience.

That question would not leave. It followed me to work. It followed me home. It kept me up at night. And eventually, I stopped trying to ignore it and started trying to answer it.

💡

The idea did not arrive fully formed. It started as frustration with an open-source world that is not as open as it claims. What turned frustration into action was a question: what if someone actually built the thing that is missing?

02The First Lines of Code

The first lines of code were terrible. I mean genuinely, embarrassingly terrible. A single Lambda function that returned 'Hello World' from an API Gateway endpoint. That was it. That was the beginning of a platform that would eventually have 34 microservices, 4 frontend applications, and thousands of lines of shared infrastructure code.

But those first lines mattered. Not because they were good — they were not. They mattered because they were real. An idea in your head is just a thought. An idea in a code editor is a project. The gap between thinking about building something and actually building something is enormous. And the only way to cross it is to write the first line.

There is something psychological about that first commit. Before it, the project exists only in your imagination — perfect, unbounded, and completely hypothetical. After it, the project exists in reality — flawed, limited, and undeniably real. That transition from imagination to reality is uncomfortable. The real version is always worse than the imagined version. But the real version can be improved. The imagined version cannot.

The first week was messy. The first month was chaotic. The first architecture was wrong — a monolith that would need to be torn apart later. But it existed. And because it existed, it could be improved. You cannot iterate on something that does not exist. You cannot refactor an idea. You can only refactor code. So write the code. Write it badly. Write it wrong. Just write it. The revision comes later. The beginning just needs to begin.

✍️

An idea in your head is just a thought. An idea in a code editor is a project. The gap between them is enormous. You cannot iterate on something that does not exist. Write the code. Write it badly. The revision comes later — the beginning just needs to begin.

03The Moment It Became Real

There is a moment in every project where it stops being a side project and becomes something more. For TCTF, that moment came during a team meeting — not a dramatic external event, but a quiet internal one.

We had been building utility libraries independently for years. Error handlers, security sanitizers, logging wrappers, response formatters — the kind of infrastructure code that every backend project needs but nobody wants to write twice. Each of us had our own versions, refined across multiple production systems. And in that meeting, someone said: what if we packaged all of this together? What if these utilities became the foundation for something bigger?

The room went quiet for a moment. Then the ideas started flowing. What if we combined our security sanitizers into one module that handled 12 different contexts? What if we unified our error handling into a single hierarchy that every service could extend? What if we built the activity publisher we all wished existed — one function call for notifications across dozens of services?

That was the turning point. We looked at what we collectively had — dozens of reusable modules, each solving a real problem we had encountered across multiple projects — and we resolved to build. Not to plan endlessly. Not to research the market for another six months. To build. To take these scattered utility libraries and forge them into a coherent platform that could power larger projects. The kind of shared infrastructure that makes building 34 services feel like building 5.

From that meeting forward, TCTF was no longer an idea someone might get around to. It was a commitment the team had made to each other. That collective resolve — that shared decision to stop talking and start building — is what turned a collection of utility libraries into a foundation. And once you make a commitment to other people, not just to yourself, the stakes change. You show up differently when others are counting on you.

🌱

The moment it became real was not a dramatic event. It was a team meeting where we looked at our scattered utility libraries and resolved to build something bigger together. Once you make a commitment to other people, not just yourself, the stakes change.