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.

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

Does cold outreach really work in our market? I don’t know. See.

Docling has shown me bad things. I have to look for alternatives. Document processing is a non negotiable here, but anything that requires big budget infrastructure is no go at the moment. So, what I will do is have options. It is still the best I have found for my use case so far, but I will keep the implementation as an option for those willing to pay for such infrastructure

I could have easily automated this email sending thing. But sending the emails, one by one, customizing each email for each prospect . That is the goal. I still have like 100 unsend emails, and Friday is perhaps the wrong day to send them But will send them anyway.

My biggest lesson from building products is, “You can do things” I may not know every tiny detail about what I am doing. I haven’t figured out how it will end. I don’t even have to have a perfect start. And that translates into other areas of my life.

Building a big company involves a lot of luck. Very few people have been able to pull big companies back to back like Jack Dorsey. But a lot of people struggle to build another massive company. Look at Travis Kalanick for example. He built Uber, but after the exit, no other massive company. Watch the story of Steve Jobs when he left Apple. Next was burning money, massively bailed by investors. If you build something and it succeeds, leaving/selling and assuming you will pull the same is usually delusional.

Never push pawns in front of the King In this position, the white is completely tossed 😂 I just needed to open up the h or g file, and I completely toss. It’s crazy how most sub 1000 elo players ignore g and h files after castling 😂 Like dude, that’s your life 😂