Notes from a random Tech Buddies Space
I opened Tech Buddies randomly. There was no big plan behind it. A few people joined, more people kept coming, and somewhere along the way it became one of the most useful conversations I have hosted.
Thanks to Edem Kumodzi, Kevin, Yaw, Jojo Dontoh, Edem Quintin, Bubu, Ivy, and everyone else who came up or stayed to listen. I am writing this from memory, not as a transcript, so these are the parts that stayed with me.
What I liked most was that it never became a room where technical people were trying to prove how technical they were. We moved through software, hardware, regulation, paperwork, distribution, careers and even architecture, but most of the conversation was still understandable to somebody who does not write code.
That is probably the version of Tech Buddies I am most interested in.
Distribution does not finish
One of the biggest things I carried away was distribution The work of getting a product in front of the people who might use it, and giving them a reason to try it, return to it or tell someone else about it. Think of it like A great restaurant can have excellent food and still stay empty if nobody knows it exists or why they should visit. Example For a software product, distribution can be word of mouth, social posts, partnerships, search, communities, direct outreach or many other ways people discover and adopt it. .
I used to think about distribution mostly as the stage after building. You build the thing, then you figure out how to get people to use it.
The conversation made that feel incomplete. Distribution does not really end. Even Facebook still has to market itself, launch things, enter new places and keep reminding people why its products matter. Getting the first users is not the finish line. Distribution becomes part of operating the product.
That changed the way I think about Pumply too.
Do not formalize the experiment too early
Kevin said something that stayed with me.
His point was basically: if you are still experimenting with an MVP The smallest useful version of a product that lets you test whether the idea actually works for real people. Think of it like Before building a full restaurant, you might first sell a small menu from one location and learn what people actually buy. Example An MVP for an app might have one core feature working well instead of ten unfinished features. , do not rush to collect every certification and formal process just because it makes the company feel more serious.
If the activity legally requires approval before you test it, obviously that is different. But his broader point was about timing. You can spend money, time and energy formalising something that is still an experiment, only to discover later that the experiment itself did not work.
He had also seen founders get deep into the formal side of a business and later discover that closing things down was its own administrative problem.
I liked that because it reframed compliance for me. The goal is not to avoid it. The question is when does the experiment become a business that needs the next layer of structure?
Kevin also distinguished registering a business from registering and complying with the Ghana Revenue Authority. I checked that part afterwards because I did not want to remember it incorrectly. GRA treats tax registration as its own process, and says businesses are required to register for taxation. So the useful distinction is not “register a company and you do not pay tax.” It is that company registration and tax registration/compliance are different processes.
Yaw made the paperwork feel less mysterious
Yaw spoke about certifications and the actual process of getting through them.
One thing I took from him was how much easier parts of the process have become now that portals and information are online. Things that can sound intimidating when somebody says “you need certification” become less mysterious when someone actually breaks down where you apply, what the sequence looks like and what you need to prepare.
That sounds small, but I think it matters. A lot of regulatory fear comes from not knowing what the process actually looks like.
A sandbox is not a free pass
The fintech conversation was another interesting turn.
We compared Ghana with Nigeria and talked about whether one reason Nigeria has produced so many large fintech companies is that founders have had more room to experiment. I do not think I can reduce Nigeria’s fintech success to one regulatory reason, but the question itself was useful: how much does the environment around builders affect what gets built?
Edem Quintin pointed us toward the Bank of Ghana’s regulatory sandbox A controlled environment where a regulator lets eligible companies test a genuinely new financial product or business model with real users under supervision. Think of it like It is closer to a supervised test track than an open road: you can test the vehicle, but there are boundaries, monitoring and conditions. Example A fintech with a new kind of financial service that existing rules do not clearly cover may apply to test it in a limited environment before wider rollout. .
I checked the framework afterwards. It is not a blanket permission for every fintech startup to ignore licensing. Bank of Ghana says the sandbox is aimed at things like new digital business models not already covered by regulation, immature financial-service technology, and innovative products that could address financial-inclusion problems. It also explicitly says the sandbox is not a permanent licence or a free pass to operate without supervision.
That is much more interesting than simply saying Ghana is “strict” and Nigeria is “easy.” Both countries have sandboxes. The deeper question is how accessible those systems are, what kinds of ideas qualify, how quickly regulators respond, and whether founders feel they can experiment without accidentally destroying the company before it has even found a market.
Then somehow we ended up talking about window cleaners
Jojo brought hardware into the conversation.
Ivy was asking him questions around physical problems that still feel strangely unsolved even though software keeps moving quickly. Window cleaning came up. We started breaking down why something that sounds simple becomes a real engineering problem once you include height, safety, cost, reliability and maintenance.
Jojo works across hardware and software and is experimenting with robotics, so the conversation moved naturally from there into why hardware can feel slower and harder to change than software.
The architecture connection came to me afterwards. We did not have a conversation about old buildings versus new buildings in the Space.
But thinking about hardware made me notice something broader: even though we have better tools, more computing power and more advanced manufacturing, a lot of the physical things around us can still feel less interesting than what people made before. Buildings, lamps, furniture, household objects — sometimes progress gives us more efficiency without necessarily giving us more character.
I do not mean that ancient buildings were simply “better” in every technical sense. It was just a thought the hardware conversation triggered for me: having more advanced tools does not automatically mean we make more beautiful or more thoughtful things.
That is the kind of connection I like these conversations creating in my head.
Bubu gave the reality check
Bubu’s contribution stayed with me for a different reason.
He talked about having run a software company and eventually reaching a point where he was carrying too much of it himself: managing people, managing the company and still trying to figure out where the company should go. The way I understood him, the decision to step away was not simply “the company failed.” It was more personal than that. He had to ask whether continuing to run it was helping him become the person he wanted to become.
I liked that distinction.
Founders are usually taught to think about the company as if persistence is automatically good. Keep going. Do not quit. Survive long enough and maybe it works.
Bubu made me think about the founder separately from the startup.
If a company can be called a startup for ten or twenty years, when does the founder get to stop? When does persistence become identity? When does staying with the company stop being the same thing as growing?
He also made a point I already agree with strongly: do not read a Silicon Valley book and assume you can copy and paste the playbook into Ghana.
The market is different. The capital available is different. Customers behave differently. Infrastructure is different. Regulation is different. Even the cost of being wrong can be different.
That does not mean there is nothing to learn from Silicon Valley. It means advice has to survive contact with the environment you are actually building in.
Bubu can sound harsh when he says things like that, but I think that realism is useful. Sometimes the person who says “this is what the ground actually looks like” is more helpful than the person giving you the most inspiring answer.
That is one reason I would like to have a longer conversation with him.
What happens to companies after the founder?
That discussion also led Edem Kumodzi to bring up Bending Spoons.
I only understood part of that thread in the moment, so I looked it up afterwards. Bending Spoons describes its model very simply: it acquires digital products, improves them, and keeps operating them for the long term rather than buying them just to resell them.
That opened another question for me.
Will Africa eventually have companies whose job is not only to start software companies, but to buy, operate and improve software companies that other founders no longer want to run forever?
Maybe that was the bigger point underneath the Bending Spoons example.
A founder should not necessarily have to remain attached to one company for life just because they started it. A healthy technology ecosystem also needs ways for companies to change hands, outlive founders and become part of something bigger.
I do not have a conclusion there yet, but I want to understand it better.
I think I understand what I want these conversations to feel like
I have listened to long conversations for years. I like when somebody starts with one question and the answer creates another question, and then that answer opens another door. Sometimes twenty minutes later everybody is somewhere nobody planned to go.
I never really thought of that as something I wanted to do myself.
Now I do.
The bigger thing is that I am learning how I learn.
If somebody uses a word I do not understand, I want to stop there.
If somebody says the software ecosystem was different ten years ago, I want to know what “different” looked like.
If somebody says regulation kills startups, I want to know which regulation, at what stage, and what actually happened to somebody who went through it.
That is where the interesting conversation starts for me.
One unfinished thread
One part of the Space is still running through my head.
Edem Kumodzi talked about people who seem unusually good at noticing where technology is moving early. He mentioned someone who got into crypto early and is now moving into inference engineering. We also touched on AI engineering and what these new careers actually mean.
I did not really know what inference engineering was.
That made it interesting.
It opened a much bigger question for me: if AI is changing software work, what should somebody entering technology now actually be learning? Is this still a good time to study computer science? What should a student learn outside university? Which skills become more useful as AI gets better? And can somebody sitting in Accra realistically become world-class in one of these emerging areas?
That is probably where the next Tech Buddies Space goes.
I like that this Space did not leave me with a neat conclusion. It left me with better questions.
That is probably the point.