Nairobi Labs

I have written before about why I believe what I believe about effective acceleration, and separately about why a fish company made sense to me when a dozen other ideas did not. Nairobi Labs is the place those two beliefs live together, and it is the harder essay to write, because a company is not one product with one clear customer and one clear meal at the end of it. It is a bet about what a company should be doing at all, made across more products than I can describe in a single sentence, and I would rather take the space to describe it properly than compress it into something that sounds finished before it has earned the right to.

What a company is for

I think a company is one of the more honest inventions available to a person who wants to change something. It is not a government, so it cannot force anyone to use what it makes. It is not a charity, so it cannot survive on the goodwill of people who already agree with it. It has to make something, offer it to a stranger, and continue existing only if the stranger keeps saying yes, again, on an ordinary day, for no reason beyond the thing being worth it. That is a stricter test than most institutions submit themselves to, and I think most companies quietly find ways around it long before they admit that is what they are doing.

Nairobi Labs exists because I wanted a company built around that test, held across more than one kind of product, rather than a single company solving a single narrow problem forever. Not a holding company either, collecting unrelated bets for the sake of a balance sheet, with no reason for any one part of it to know the others exist. Something closer to a workshop that happens to have grown walls and a name: a place that builds software when a problem is solved in code, hardware when a problem needs a physical object in someone's hand, and the systems underneath both when the actual bottleneck was never the product at all, but the road it had to travel to reach someone. The medium is chosen by the problem. The company is the discipline that keeps choosing correctly, year after year, even once it would be easier to specialize and stop asking the question.

The exchange

Every product is a transaction between the person who made it and the person who uses it. I think most of what goes wrong with technology, at every scale from a single app to an entire industry, comes from that transaction quietly stopping being a transaction. The user keeps paying, in time, in attention, in the small daily currency of being present somewhere, and stops receiving anything close to equal value in return. The product survives anyway, because leaving costs more than staying, or because the user never quite notices the trade has gone bad, the way a person can be underpaid for years before they sit down and do the arithmetic.

I want Nairobi Labs held to a plainer standard than that. A product should be a fair exchange: something a person pays for, uses, and is glad afterward that they did. I do not think this needs a long definition. Everyone already knows the feeling of a good exchange from ordinary life. You buy a meal, and it feeds you, and there is nothing hidden in the price. You buy a tool, and it does the job, and it is still doing the job a year later. You listen to a piece of music and it moves something in you, and you carry that for the rest of the day. None of these experiences require an explanation of why they were good. They just were, and you know it the way you know weather.

What a good exchange is not

I have spent a long time watching what happens when that exchange breaks, not because I want to build a company defined by what it refuses, but because understanding the failure clarifies what I actually mean by success. A broken exchange rarely announces itself as broken. It usually looks, for a long time, like a product that is simply popular. People open it every day. They stay inside it for hours. By the ordinary measures a company reports to its investors, it is thriving.

What is missing from that measurement is the only question that actually matters: does the person leave better off than they arrived. A product can hold someone's attention for an hour and return nothing to them at the end of it, no rest, no progress, no memory worth keeping, only the faint sense that an hour is gone and could have been anything. I think a company that has stopped asking whether its product returns something real has already decided, quietly, that the person on the other end is a resource rather than someone it is in an exchange with. It rarely announces this decision either. It just optimizes for the hour, and lets the meaning of the hour become someone else's problem.

I do not want to build that kind of company, and I do not think avoiding it requires a list of practices to reject. It requires a single, continuous question, asked about every product before it ships and periodically after: if a person spends money, or time, or attention here, do they leave with more than they arrived with. If the honest answer is no, the product is not finished, no matter how well it is performing by every other measure available.

Why more than one product

It would be simpler to describe Nairobi Labs as one thing. A software company. A hardware company. A food company. Each of those descriptions would be easier to say at a dinner and easier to fit inside a pitch deck. None of them would be true, and I would rather the company be accurately described than easily described.

The company builds across software, hardware, and the systems that connect them, because the problems I care about do not arrive pre-sorted by discipline. Some are solved by a well-written application, distributed as freely as the internet allows, open where openness serves the person using it and closed where it does not. Some require a physical device, engineered and manufactured and shipped, because no amount of code will substitute for something a person can actually hold, charge, repair, and own outright. Some sit underneath both, in the unglamorous machinery of supply chains and food systems and the infrastructure that decides whether a good idea ever reaches the person who needed it, or dies somewhere in the space between a warehouse and a market that never heard about it in time.

I did not choose this range to look ambitious, and I am aware it can read that way from outside. I chose it because narrowing to one medium in advance would mean turning away good answers for the wrong reason. A company that only writes software will eventually meet a problem that needs a machine, and either abandon the problem or force a bad software answer onto it out of habit, the way a carpenter with only a hammer starts describing everything as a nail. I would rather keep the range open and let the problem decide, even when that makes the company harder to summarize.

The discipline of restraint

There is a kind of company that behaves, in its interface and its habits, the way a good product behaves at its best: it asks for what it needs, does the job, and steps back. And there is a kind that behaves the way a bad exchange behaves at its worst: it interrupts, it manufactures urgency where none exists, it makes leaving harder than arriving. I think you can tell almost everything you need to know about a company by watching what it does in the ordinary, unglamorous moments where no one is paying close attention. Does it wait for you to ask before it speaks. Does it let a small task stay small, or does it find a way to attach itself to your attention past the point the task required.

I want this discipline to be something Nairobi Labs simply practices rather than something it advertises. A company that has to tell you it respects your time has usually already lost some of the practice of doing so. I would rather the products carry the evidence themselves, in how quickly they get out of the way once they have done what they were for.

What acceleration means here

I have written elsewhere about what effective acceleration means to me, stripped of the language of civilizations and energy scales that usually surrounds it. The shorter version is this: scarcity is mostly a solved problem waiting on enough energy, computation, and manufacturing to be pointed at it, and the order in which the world receives its own tools is not fixed. It is produced by where capital looks first and what political systems reward, and it can be changed by people who decide, on a long enough timeline, to change it.

Nairobi Labs is that belief given a company rather than an essay. Every product built here is meant to move something closer, cheaper, sooner, to someone who would otherwise have waited years longer for it, or never received a version of it built with them in mind at all. That is the accelerationist part of the company, and I want to be precise about where it lives. It does not live in the language the company uses about itself. It lives in the gap between when a capability normally arrives somewhere like this, and when it actually does, once a company here decides that gap is not owed to anyone. The company argues through what it ships rather than through what it claims, and I trust that argument more than I trust any essay, including this one.

The person on the other end

Somewhere at the end of every system the company builds, someone uses the thing. They open an application to get through a piece of their day. They pick up a device because it does something nothing else in their life could do yet. They eat something because it was fresh, available, and priced within reach of an ordinary week. None of these people are obligated to understand the company behind the product, and none of them should have to. The product should carry the whole argument on its own, without requiring the person holding it to first understand our theory of the market.

I think a company reveals what it actually believes about people through how it behaves at that final point of contact, more than through anything it says about itself elsewhere. Whether it respects the time of the person using it. Whether it assumes the person is capable, arriving with knowledge of their own life that no amount of research on our end will replace, or whether it quietly assumes they need to be managed, corrected, onboarded into a way of living they had already worked out for themselves. I would rather build a company that never has to answer these questions in a policy document, because the answer is already sitting in how the products behave when no one from the company is in the room.

Speed and patience

There is a tension in this that I do not think resolves cleanly, and I would rather name it than pretend it does not exist. An accelerationist company is supposed to move quickly, and a company built on a long vision toward a place like this one is supposed to be patient enough to still be here in twenty years. I have come to think these are not opposites so much as two different clocks running in the same building. Some things deserve speed: a product that could reach someone this year should not be held back to next year by caution dressed up as diligence. Other things deserve patience: the trust of a farmer, a customer, a market that has been sold a version of the future before and watched it fail to arrive, is not won by moving fast at it. It is won slowly, by being right often enough that the next promise is believed a little more easily than the last one was.

I want Nairobi Labs to know which clock a given piece of work is running on, rather than defaulting to one pace for everything. Some things ship in a season. Some things are only worth doing if the company is still doing them a decade from now, and I would rather say that plainly than pretend every part of the work moves at the same speed.

The work that remains

I do not think Nairobi Labs will feel finished in any of our lifetimes, and I am suspicious of the kind of company that describes itself as though it will. What I want is narrower and more durable than a mission statement: a company that keeps choosing the medium the problem actually needs, keeps the exchange with every user honest enough to survive the arithmetic if they ever sat down and did it, practices restraint rather than announcing it, and keeps building for a place that is used to being built for last. The rest, the size of the company, the shape it eventually takes, the products it has not made yet, is less important to me than whether, years from now, the people who used what it made are still glad they chose to.