Bootstrapping an International Company From Kenya: Six Months In, Here's Where I Am If you're a software engineer who has ever thought about building your own company, you've probably asked yourself one question: Where do I even start? I had the same question. I wanted to build an international software company from Kenya. Not another side project. Not another application that would sit on GitHub. An actual company, with real products, real customers, and eventually, real revenue. The problem was that I had been a good employee for most of it. Business was not my thing. I decided to document the journey, including the mistakes, the lessons, and everything in between. Here is where I am six months later. First, the company My first step was registering the company. At least the shell company that would eventually hold the different products I intended to build. I settled on a Delaware C-Corporation. It seemed like the easiest option to get started with, and it was well-documented. After getting a 50% discount from Stripe Atlas through @jeff_weinstein and @DanThaKaya, I went through the registration process. It was surprisingly straightforward. Within a week, Engimeets, Inc. was registered. I had the necessary incorporation documents, a few startup perks, and a rather large assignment ahead of me. I now had a company. But a registered company without a product or customers is just paperwork. What exactly was I going to build? I had been consuming a lot of content from Palantir and a16z, particularly around forward-deployed engineering. The approach fascinated me. Instead of building generic software and hoping customers would find a use for it, you start by understanding a specific industry, its operations, its problems, and how its systems interact. Then you build reusable services around those workflows, making them configurable enough to deploy for different customers without rebuilding everything from scratch. And be able to do that in weeks. At least, that was my interpretation of the playbook. The goal wasn't to build another conventional SaaS product with a fixed set of features and expect every business to adjust its operations around the software. I wanted to build software that could adapt to how businesses actually operate. But first, I needed an industry, a vertical. I chose freight forwarding. Three months learning an industry I knew almost nothing about From my earlier interactions with people in freight forwarding, I knew one thing: it was an operations-heavy industry. Shipments, trucks, drivers, customers, customs, clearing agents, documentation, invoicing, payments, and multiple regulations. Everything seemed connected to everything else. I also knew that trying to build software for an industry I didn't understand was a good way to spend months solving the wrong problems. Fortunately, I found a company willing to give me access to its operations. I spent three months in their offices. Attending meetings. Observing how things worked. Asking questions. Trying to fix their Excel sheets. Following processes from beginning to end. Think of an apprenticeship where you sit next to a master and watch them work. That was me. I read practically anything I could find about international logistics. It felt like taking a diploma course and cramming the entire syllabus into three months. Before this experience, I didn't even know what a Bill of Lading was. Terms like consignor and consignee were completely foreign to me. Three months later, I could follow the movement of a shipment, understand the documents involved, and see how decisions in one department affected operations in another. More importantly, I started understanding why certain problems existed. This was probably the most valuable part of the entire journey. I was learning that understanding the business is just as important as knowing how to write the software. Then came the building Once I understood the operations well enough, I started building. The first version was too basic. So was the second. The third and fourth versions became genuinely useful. By the fifth version, I had something much more robust, covering the major workflows I had observed in freight forwarding. I called it Engimeets Atlas. But getting there wasn't simply a matter of writing more code. I had to understand why a local purchase order is different from a fuel order. How a shipment connects to a trip. How that trip connects to a truck, a driver, expenses, customer invoices, and ultimately, profitability. And how all these relationships need to remain consistent as operations change. A small misunderstanding of the business could lead to an entire feature being designed incorrectly. I would build something, realize I had misunderstood a workflow, and go back to the drawing board. Fun fact: I really struggled to understand the relationship between a quote and a ratecard 😂 Again and again. By the end of September, I had a product ready to go live with the company that had helped me understand the industry. That was roughly six months invested in the same idea, from learning the business to building and rebuilding the product. Six months without knowing whether this would eventually become a sustainable business. Having a product is not the same as having a business At this point, I had accomplished two things. I had incorporated Engimeets, Inc. And I had built Atlas, a freight operations platform based on actual industry workflows. That felt like progress. But I was also beginning to understand something: building the software might not be the hardest part of building a software company. The next question was whether the product was reliable enough to support day-to-day business operations. Not whether it worked during a demonstration. Whether people could depend on it when managing real shipments, processing documents, assigning trucks, generating invoices, and coordinating operations. There is a big difference. A product can have all the right features and still fail the people using it. And I wasn't interested in building something that looked impressive but became another operational headache for customers. So the next phase became clear. Now comes the part that will determine whether this works I need customers. Not thousands of customers. Not even hundreds. Two. Then five. Then ten. Businesses I can easily access, talk to, observe, and learn from. My immediate plan is to identify freight forwarding companies in Nairobi, understand their existing workflows, demonstrate Atlas, and work with those willing to try it. I want to know where the product breaks. What I've misunderstood. Which features matter and which ones I spent too much time building and are not necessary for most companies. And most importantly, whether Atlas solves problems that businesses care enough about to pay for. This part cannot be solved by sitting behind my laptop and writing more code. It requires conversations, demonstrations, feedback, rejection, and probably another round of rebuilding things. Six months in. Still at the beginning. I still need to stabilize the product, earn customers' trust, prove that it creates value, and figure out how to turn it into a sustainable business. There is no guarantee that it will work. But six months ago, freight forwarding was an industry I barely understood. Today, I have built software that models much of what I learned about its operations. That is progress. If you're a developer thinking about building your own company, one lesson I'd share from this experience is this: Don't start by asking what software you can build. Start by finding an industry you can learn deeply enough to understand what software it actually needs. You don't need to understand everything on day one. But you need to be willing to spend time learning things that have nothing to do with programming. For me, that meant three months in a freight forwarding office, talking to people on the ground. Doing the day-to-day thing. That is not our specialization, but at some point, you may need it. Now comes the real test. Can I turn Engimeets Atlas from a product I've built into a business that customers are willing to pay for? That's the next chapter. And I'll be sharing how it goes.

Building a Global Software Company from Africa: 3. The Challenge of Finding Customers If you're an engineer building a software company, you probably understand how much work goes into getting a product to function properly. There are complex business requirements to understand, systems to design, and countless technical problems to solve. But even after you have built something that works, there is another challenge: getting it into the hands of people who need it, and convincing them to pay for it. This is the stage I have entered with Atlas. As part of my series on building a global company from Africa, I have been sharing my experiences building Engimeets (@engimeets), from incorporating the company in Delaware to developing Atlas, our freight operations platform (engimeets.com/atlas). Now, I am learning how to take the product to market. And so far, it has been quite an interesting experience. Building the product and building the business I have narrowed my immediate priorities down to two things now that Atlas is taking shape: 1. Talking to customers. 2. Building and stabilizing the product. Both are equally important. On the technical side, I am confident in my ability to build complex systems. There is still plenty to learn, but I am comfortable understanding business constraints and translating them into working software. The other side is marketing and sales. This is relatively new territory for me. I developed a marketing plan covering content, branding, SEO, and cold email outreach. I decided to begin with cold emails because I am still stabilizing Atlas and want to explore the market beyond the one customer I originally built it for. I need to understand how other freight companies operate, what problems they experience, and whether Atlas can solve those problems. Of course, the first challenge is getting someone to talk to me. Apparently, companies don't want to be sold to One of the funniest things I am discovering is just how much effort companies put into making sure they are not sold to. Marketing and promotional emails are filtered, restricted, and sometimes blocked entirely. I understand why. Nobody wants their inbox flooded with people trying to sell them something. But when you're on the other side, trying to introduce your product to potential customers, you quickly discover how difficult it can be to get someone's attention. At first, the whole process sounds quite simple. Find companies, get their emails, write a convincing message, and send it. Then, presumably, sit back and wait for people to flood my inbox, begging to buy my solution. Shock on me, lol 😂 Unfortunately, that is not how sales works. The process is quite humbling, especially when you're asking someone to spend thousands of dollars on software in a margin-constrained industry like freight. You might have built something genuinely useful, but that doesn't mean the person receiving your email understands the problem you're solving, trusts you, or considers it a priority. And honestly, why should they? They don't know you. So I decided to start small. My first 10 emails My initial approach was straightforward. Find freight companies online, get their contact information, and send emails manually. Easy, right? Well, not quite. On the first day, I sent about 10 emails. No response. The following day, I sent slightly more, and my email account was restricted. That was an interesting introduction to cold emailing. Proper character development 😂 I have worked with transactional emails before, but this was my first serious attempt at non-transactional emails. And I am discovering that the two are very different. With transactional emails, someone is generally expecting a message. Perhaps they signed up for an account, requested a password reset, or completed a transaction. With cold emails, nobody is expecting anything from you. You are interrupting someone's day, hoping that what you have to say is relevant enough for them to care and respond. And even before they can decide whether your message is relevant, you have to get it delivered. There was also the problem of doing everything manually. At one point, I confused a customer's name in an email. Imagine approaching a company to discuss software that could help manage its operations, only to get the company's name wrong. Not exactly the introduction you want. At that point, I decided to approach the problem the same way I approach most engineering problems. Break it down into smaller pieces and solve them one at a time. 1. First, finding potential customers The first problem was lead generation. Surprisingly, this is becoming one of the easier parts of the process. Thanks to the internet and AI. There are now quite a number of tools for finding businesses and the people who work in them, provided you know what you're looking for. One of the most common is Apollo, which allows you to search for contacts based on their companies, roles, industries, and other criteria. I also came across Treg people-search, which connects all these tools like Apollo, Hunter, Tomba, People Data Labs, name it, and costs a fraction for each search. And, of course, there is the good old Google Maps search. I decided to build a small internal tool to bring some of these tools together. Why not use Instantly, or Brevo, etc.? I could have used an existing platform for everything. But I also wanted to understand how the process works, and I figured that if I could build a reliable prospecting pipeline, it could become useful for other projects. My approach was to start with companies, then enrich the information I collect about them. I started by getting a list of businesses from Google Maps. There are many open-source Google Maps scrapers on GitHub. I decided to integrate one into my tool. Now I can describe the type of businesses I am looking for, specify a location, and collect a list of potential prospects. For instance, I can search for freight forwarding companies in Nairobi, and it gives me a list with any of their data saved on Google Maps. That gives me a starting point. But having a list of companies doesn't necessarily mean I have anyone to talk to. Which brings me to the second step. 2. Finding the people who make decisions Once I have a company, the next challenge is figuring out who I should contact. I don't necessarily want to send emails to everyone in an organization. I want to identify the people who would be involved in making a decision about a platform like Atlas. Someone who can do something. Buy, influence purchase decisions, etc. Depending on the company, that could be someone in operations, technology, or management. So the next step in my system is data enrichment. The tools I mentioned earlier, like Apollo, make the search for relevant decision-makers possible. They try to find their professional information, including LinkedIn profiles, business email addresses, and phone numbers where available. This has been one of the more interesting parts of the process. And also one of the more frustrating parts. Finding accurate information about some companies is surprisingly difficult. Sometimes you can find the company, but not the people running it. Sometimes you find a LinkedIn profile, but no reliable contact details. Other times, the information is simply outdated. And even when you find an email address, there is no guarantee that it still works. But gradually, I was putting together something useful. I could identify businesses, find relevant people, and generate personalized emails. Surely, the hardest part was over? Not quite. 3. Getting the emails into someone's inbox It turns out that finding an email address and sending an email are two very different problems. Cold email delivery is a business of its own. There are companies whose entire business revolves around helping other companies send marketing and sales emails. And some of these tools are quite expensive. As a startup, I am trying to be careful with expenses, especially when I am still validating the market. I also figured that learning how to build a reliable outreach process could be useful beyond Atlas. So I started experimenting. One of the approaches I considered was self-hosting a mail server. That led me into an entirely different world of email infrastructure. Domain reputation, IP reputation, SPF, DKIM, DMARC, blacklisting, bounce handling, sending limits, and domain warm-up. Things I had previously given little thought to. Apparently, sending an email is easy. Getting it delivered reliably, especially when the recipient hasn't asked for it, is a completely different challenge. There is also the issue of making sure the emails are valid, respecting people who don't want to be contacted, and understanding the legal requirements surrounding B2B outreach. Oh My! What did I get myself into 😂 I had to learn that automation doesn't remove these responsibilities. Eventually, after experimenting with several ideas, I decided to start with something simpler. Send a handful of emails, spread them out over time, and gradually improve the process. 4. Bringing everything together with Mautic For the scheduling and automation side, I settled on Mautic. Mautic is an open-source marketing automation platform that you can self-host. The idea is to connect everything I have been building into one workflow. My internal tool handles lead generation, company research, contact enrichment, and email generation. I skipped how I generate the emails. I use AI. A few API calls to Gemini. Mautic handles campaign scheduling, sending, and supported engagement tracking. Mautic makes it possible for me to monitor replies and determine which prospects need follow-ups. For instance, if I contact a company and nobody responds, I might want to follow up later with a different message or reach out to a more relevant decision-maker. If someone replies, I want that conversation to take priority over further automated outreach. And if someone indicates that they're not interested, the system should respect that. The goal is not to send thousands of emails and hope that something sticks. It is to develop a repeatable process for finding relevant companies, introducing Atlas, and starting conversations with the right people. Of course, the entire system is only useful if the messages are relevant and the people receiving them actually have a problem worth solving. Which brings me to the results. So far, nobody has replied 😂 Not a single response. Zero, Sufuri, Zéro, Cero, Null, Zero, Zero, Rei, Líng, Sifr 😂 I have researched companies, experimented with prospecting tools, built parts of an internal outreach system, explored email infrastructure, and spent quite some time trying to understand email deliverability. And I still haven't received a response from a potential customer through cold email. It is a little funny when I think about it. I started with the assumption that sending emails would be one of the simpler parts of taking Atlas to market. Instead, it has become an entire learning experience. But I am beginning to understand a few things. Having someone's email address doesn't make them a qualified prospect. Having a good product doesn't automatically make someone interested in buying it. And automating an outreach process doesn't necessarily make that process effective. You still have to understand the customer, identify the right problem, communicate your solution's value, and earn their attention. This is where I am beginning to appreciate the relationship between engineering and sales. Engineering helps me solve customers' problems. Sales and marketing help me discover which problems matter enough for customers to invest in solving them. The two feed into each other. The more conversations I have with freight operators, the more I can learn about what Atlas should become. And the more useful Atlas becomes, the better the conversations I can have with potential customers. The next step For now, I am continuing to stabilize Atlas while improving my outreach process. I want to get better at identifying the right companies, writing relevant emails, ensuring they reach the intended recipients, and following up appropriately. But more importantly, I want to start having actual conversations. Just getting in front of people who might benefit from what I am building, understanding their problems, and seeing whether Atlas is a good fit. I have already learned quite a bit from trying to send a handful of emails. I imagine there is even more to learn when people actually start replying. And this is another part of what it means to build a global software company from Africa. It is also about learning how to reach those customers, earn their trust, and build lasting business relationships. For now, I have the software, and I have the beginnings of an outreach system. That's the solid start. The next milestone: Get the emails delivered. Get someone to respond. Have an actual conversation. Then learn from it. The software can be built in isolation. The business cannot. If you've built a software product and had to figure out how to find your first customers, I'd be interested to hear what worked for you.

Every ‘viral’ post I make has over 5 bots in the responses 😂

PHP listings this week 😂

Hi Cedric, I think your claims about Lennox are not only inaccurate, but also malicious. You can inquire directly from him @_lennoxomondi, or engage @SamProgramiz, @shadrac_matata @StanleyMasinde_ and will share more about Reduzer. But no man, this is not it.

Why I Registered @Engimeets as a Delaware C-Corp From Kenya If you're building a company from Kenya but want to sell globally, one question comes up surprisingly early: Where should the company actually be registered? To me, that foundational question was necessary. This is the second part of my series on trying to build an international company from Kenya. Last time, I shared the overview. This time, I want to explain why I ended up registering a Delaware C-Corporation. My decision was partly logical and partly emotional. The logical part was simple. I didn't want to think of the business as something restricted to Kenya's roughly 50 million people. I wanted to build products that I could sell in Africa, the US, Europe, or wherever the customer happened to be. I have worked with global companies, including a Fortune 500 company, so building internationally didn't feel completely abstract. The question was how to structure the company. Some of the places I considered are Delaware, Wyoming, Dubai, Seychelles and countries with e-Residency like Estonia and Lithuania. My main considerations were how difficult the company would be to operate, the regulatory burden, and whether the structure would still make sense if the company grew. Then there was the emotional part. Around 2020, I joined Y Combinator's Startup School. That was probably the first time I paid serious attention to Delaware corporations. YC has historically favored Delaware C-Corps for venture-backed startups as investors are familiar with the structure. If you eventually want venture investment or an acquisition, familiarity can reduce friction. That stuck with me. So my next decision was: LLC or C-Corp? An LLC looked simpler and potentially cheaper. But I kept coming back to the same question: what happens if this company becomes bigger than I expect? I eventually chose the Delaware C-Corp. Was it definitely the cheapest option? No. In fact, one mistake I made was not spending enough time comparing cheaper alternatives before committing. I optimized more for what I thought the company could become than on minimizing the cost of incorporation. To register, you can handle the incorporation yourself, or use an agency like Stripe Atlas. I didn't want to make mistakes here, so I went with @atlas. I got 50% off, so I only paid $250 for the registration. Some agencies charge less than Stripe for incorporation, so this is one area where it is worth doing your own research before paying full price. For me, Atlas was convenient, straightforward, and has no hidden costs. Instead of figuring out incorporation documents, registered-agent arrangements, and the initial setup individually, Atlas handled most of the process. You fill in the information, pay the fee, and eventually receive the documents establishing the company. PS: This is not a paid promotion. I am not affiliated to Stripe Atlas in any way. It's just the service I used. And in a week, I owned a US company. That part is surprisingly easy. Maintaining it is the part you need to understand. And I will admit, I had not done proper research on this one, but we learn everyday. A Delaware company comes with ongoing obligations: registered-agent fees, Delaware filings and taxes, federal tax requirements, and potentially accounting or professional fees depending on your situation. So don't register one simply because X, YC, or another founder told you Delaware is the place to be. Understand what you are signing up for. For me, this C Corp was about giving myself a structure from which I could attempt something bigger than my immediate geography. Whether that decision turns out to be brilliant or unnecessarily expensive is something I'll probably discover along the way.

I would argue that the value of software has not gone down. In most cases, it has remained the same. Organizations still need software. Individuals still need software for their business. Service-based businesses remain one of the best, and software is the best service business I know.

This mailbox not found issue is too common in Kenyan freight companies. What could be the reason? One side, it’s a challenge that probably they do stuff the old school way. The other end, it’s an opportunity that they need systems in place to handle their operations. But it’s a worrying trend. Every 6 emails I send, one is either mailbox not found or mailbox suspended.

It’s the faith that, whatever we are selling, someone needs it. Biggest challenge: connecting the two Biggest opportunity: connecting the two My challenge, is also my biggest opportunity