I have spent a lot of time over the last few years thinking about things I could build.
Too many things, probably.
Developer tools. Software for tattoo artists. Healthcare infrastructure. An energy company. An observability product. An EMR. Products for founders. Products for doctors. Products for writers. Products for readers. Products for the military. Products for creators. Gambling products. Investment products. Study aids. Games. Products that probably should never become companies at all.
At first glance, this might look like a lack of focus.
I don't think it is. I am, at my core, a thinker and a builder. I get an itch, I philosophise and make detailed notes, then I write code and that itch is allayed.
The industries are all over the place, but the ideas that actually hold my attention tend to have the same shape.
There is some constrained thing — a person, a team, a machine, a battery, a doctor's time, a founder's attention, a gambler's fast-dwindling finances, a neophyte investor's faster-dwindling resources — and the product makes considerably more output possible from it.
I keep coming back to leverage.
Not "productivity" in the usual software sense. Not saving somebody three clicks. Certainly not putting a prettier interface around an existing workflow.
I mean changing the ratio between the resources you have and what those resources make possible.
That distinction explains a surprising amount about what I like building.
I don't find automation particularly interesting
Not by itself, at least; although I have always obsessed about automation and productivity and efficiency.
A lot of software is sold on time saved.
A task took twenty minutes. Now it takes five.
Good. Often useful. I would pay for plenty of software like that.
But it rarely makes me want to spend the next five years of my life building the company behind it.
The interesting question to me is what happens after the twenty minutes becomes five.
Does the person just have fifteen minutes back?
Or does removing that constraint change what they can reasonably attempt?
Those are very different outcomes.
If you make an engineer 10% faster at writing code, you have improved their productivity.
If you give one engineer enough leverage that they can build and operate something that previously needed five engineers, you have changed the economics of the problem.
That is much more interesting.
The same applies to companies.
A tool that helps a ten-person sales team write emails faster is useful.
A system that lets a founder do work that would otherwise require building a ten-person sales organisation is something else entirely.
The first optimises the organisation.
The second potentially changes the organisation you need.
I keep finding myself more interested in the second category.
Lucien AI was probably the clearest version of this
Lucien started as a developer agent I was building in my spare time, which I'd started soon after Devin AI publicly announced their own developer agent (which was quite possibly the first publicly available agent in its category).
At the time, the idea was fairly straightforward: give an AI access to a sandboxed development environment, let it inspect a codebase, plan work, write code, execute stuff, test, and iterate. And let it do multiple streams of this kind of work simultaneously, dramatically increasing any regular software engineer's productivity and scale of impact.
I eventually became less interested in the coding agent itself.
The more interesting problem was everything surrounding it.
A founder has a company in their head.
There are product decisions, engineering, customers, competitors, hiring, sales, marketing, finances, things people promised to do in Slack, things quietly going wrong in production, things that should have happened last week and didn't.
The founder becomes the integration layer.
That does not scale particularly well.
Lucien gradually became less "AI that writes code" and more "what would an AI management layer for a company look like?"
Something that understands the organisation, watches the systems it operates in, notices what matters, coordinates work and eventually executes a meaningful amount of it.
I kept describing it as an AI Chief of Staff, and eventually as something closer to an AI COO.
The terminology was imperfect, but the direction mattered.
I wasn't interested in giving founders another chat box.
There are enough chat boxes.
I wanted to know how much larger a surface area one competent person could control if the software around them could actually observe, reason and act.
Could five people operate like twenty? One like six?
Could a founder postpone entire categories of hiring?
Could an organisation acquire capabilities before it acquired headcount?
Could software absorb some of the coordination overhead that normally appears as companies grow?
That is leverage.
And I think it is why I keep circling back to products for founders, even when I deliberately try to think about something else.
I'd really love to see Lucien evolve into an actual product with an actual company behind it. That is an idea I could see myself obsessively working on for the next 10 years.
AI made the question much bigger
Software has always been simultaneously about abstraction and leverage.
That is almost the point of software.
In fact, most of the time abstraction becomes leverage, which fuels the next cycle of abstraction-leverage.
You write something once and it performs the same operation a million times. You define procedures to encode a process so the next person does not need to reconstruct it. You build an abstraction and stop thinking about the machinery underneath it every time you use it.
A good engineer can already command an absurd amount of infrastructure because layers of software compress the complexity underneath them.
Nobody operating a web service is manually routing packets.
Nobody using Postgres is thinking about how bytes should be arranged on disk every time they execute a query.
The average Joe (or Judy) at a tech startup, picked at random, does not really care about memory allocation or garbage collection or how the kernel schedules processes or how packets actually make their way across the internet or how light-encoded data travels across the ocean bed and bounces around in fiber optics cables before coming to rest on their MacBook as a JPEG. Most software engineers don't spend much time thinking about these things. They don't have to. Decades of abstractions have pushed those problems far enough down the stack that most of us can build really useful things without understanding, much less directly managing, the machinery underneath.
That is leverage too. Every good abstraction takes a problem somebody once had to think about constantly and turns it into something the next person can mostly take for granted. The result isn't just that we do the old work faster. It is that our attention moves up a level, and we get to spend it on larger problems. And our solutions to these problems feed into the next layer of abstraction and leverage.
The abstraction gives you leverage over the layer below.
AI is interesting because it starts moving that abstraction boundary into cognitive work. Until recently, software mostly needed us to tell it exactly what operation to perform.
Now we can increasingly give software an objective, context, tools and some room to work out the operations itself.
That is not just another improvement in interface design. It potentially changes which parts of an organisation require human attention at all.
I think people sometimes frame this too narrowly as "AI replacing jobs" and are scared of it. And I think we are right to be scared.
I am scared.
But I am much more interested in the other side of that equation: what does a person become capable of when they can command much more software, information and execution than they could before?
We already know what machines did to physical leverage.
One person with an excavator can move an amount of earth that would be absurd to attempt manually.
I think we are very early in discovering what the cognitive equivalent looks like. What the world could look like when every engineer is a unicorn – the mythical 10x engineer.
This keeps appearing in my other ideas too
The strange thing is that once I noticed the pattern in Lucien's evolution as a product, I started seeing it everywhere else.
Take the tattoo studio product I've been thinking about.
On the surface, it has almost nothing in common with an AI Chief of Staff. It's a very different customer and a very different market, optimising a very different workflow.
What interests me isn't "Can I build Canva for tattoos?"
I don't think that is enough, and I don't think that is novel. Procreate already dominates that niche. I'm not trying to re-build Procreate. Procreate wouldn't keep me up most nights over the last 2 weeks.
The idea I find really interesting is: how much more capable can one tattoo artist become?
A client has an idea.
The artist has to interpret it, produce a design, place it on a body, adjust composition around anatomy, work around existing tattoos, convert the final artwork into something physically usable, scale a stencil correctly, plan the execution, and then actually tattoo it. And while tattooing they must remain cognisant of needle size and depth and frequency and greywash composition.
A surprising amount of that work sits outside the moment where needle touches skin. Today, much of it is manual, fragmented and dependent on the artist having accumulated years of experience. So the useful product is not merely an image generator: software that spits out nice pictures; the product gets interesting when it allows an artist to move from vague client intent to something executable with substantially less friction and in a fraction of the time that takes now.
Generate and modify the design.
Visualise it on the client's actual body.
Respect areas the client wants included or avoided.
Keep important details intact when the artwork changes.
Produce the stencil, annotated with as much detail as the artist needs.
Scale it correctly for printing.
Potentially turn the finished design into an execution plan.
Maybe one day tell a less experienced artist which needles, passes or techniques are likely to produce the intended effect.
At that point the software isn't merely making pictures. It's compressing expertise and workflow into a tool that streamlines that workflow and democratises competent output.
Project Solar is the same idea, just with hardware
Project Solar looks even further removed from software.
Nigeria has an electricity problem. This sentence barely even captures the extent of it.
The obvious business opportunity is to sell people solar panels, batteries and inverters; but I have never found the hardware-reseller version especially compelling. The interesting problem is (or seems to be, at least) getting more useful electricity out of limited capital.
Panels and batteries are expensive and every extra kilowatt of capacity costs real money, in a country where so few have any real disposable income.
So what if the system around the hardware made the hardware itself more productive?
Meter consumption and allocate power intelligently.
Catch battery degradation early.
Detect faults remotely instead of waiting for a customer to complain.
Autonomously schedule maintenance before equipment fails.
Know which installations are underutilised and which are overloaded and possibly automatically reroute energy storage and load to proximal, underutilised installations.
And structure financing so a customer who cannot afford the system outright can still access it, possibly by paying a monthly subscription (Paul Graham would be proud), potentially serve several users from infrastructure that would otherwise belong to one.
Now the product is no longer a simple solar installation. It's become a system for getting more economic output from every naira spent on energy infrastructure.
If I can make ₦1 million of hardware behave, economically, more like ₦1.4 million of hardware, that is real leverage I can directly translate into business revenue and saved cost to the customer.
If I can make one technician effectively maintain a much larger installation fleet because the fleet tells him where he is needed, potentially before he is needed, that is leverage.
If reliable power lets a business operate when it otherwise could not, the leverage continues into the customer's business as well.
And maybe I can finally stop paying a whopping ₦7500 for my daily cup of coffee.
One layer multiplies the next.
Healthcare keeps pulling me in for similar reasons
I spent a couple years in medical school before eventually deciding that I wanted to build systems more than I wanted to learn medicine (and that I didn't even want to practise medicine at all). But healthcare never really left my head after I dropped out. In fact, I spent a short while working for a healthtech startup based out of Lagos.
The problems I keep noticing in healthcare are rarely "we need another screen for entering this information". Nigeria does not mainly suffer from a shortage of healthcare software.
The constraints are deeper and progress is possibly 30 years behind the developed world:
Doctors are limited.
Specialists are more limited.
Good laboratories are unevenly distributed.
Patient records are fragmented.
Trust is poor.
Privacy is poor.
Insurance is nearly non-existent.
So when I think about something like Orbit — the point-of-need, private health testing service I've been exploring — I don't think the interesting product is an app where somebody remotely orders an STI test.
One could build that in a weekend.
The harder and more useful thing is an operating system around access.
Can somebody get tested without surrendering unnecessary parts of their identity?
Can the courier move a sample without needing to know what is being tested?
Can the lab perform the test without every participant in the chain having access to the person's full medical context?
Can results move back to the patient securely?
Can a doctor be pulled in when necessary?
Can the same infrastructure eventually support many categories of testing?
If you get these right, you increase the capability of existing healthcare infrastructure without necessarily owning all of it.
Maybe this is why I am suspicious of a lot of SaaS
There is a category of company that is objectively good business and still leaves me unexcited.
Take an existing business process > move it into a web application > add a dashboard > add "integrations" > add AI-generated summaries (because apparently everything now requires AI-generated summaries) > charge $49 per seat.
There is nothing wrong with that.
I may very well build something like it one day if the economics are good enough. I am, after all, a capitalist.
But I have realised that I do not naturally think in seats. Seats often imply that the organisation remains fundamentally the same.
Twenty people had a problem. Now twenty people each pay for software that makes the problem slightly less annoying.
I am much more interested in products where, after the software exists, you ask why there are still twenty people involved.
That can sound like a fixation on replacing labour, but it isn't. Sometimes the constrained resource is not even labour at all. Sometimes it is expertise. Or electricity. Or trust. Or capital. Or simply the number of things one human being needs to keep in their head at once.
The common question is whether the product attacks the actual constraint strongly enough that the system looks different afterwards.
I think this is also why observability and performance monitoring has always appealed to me
Observability sounds like a different category again, but it fits.
A complex system is not useful if you cannot understand it. The more software, agents, servers and automation you put underneath one person, the more important it becomes that the person (and the rest of their team) can tell what the heck is going on. Remove this and leverage succumbs to entropy.
There are really two sides to leverage. The first is increasing how much a system can do. The second is ensuring a human can still understand and control the expanded system. Without the second, the first stops scaling.
An autonomous agent that can perform a hundred tasks but cannot explain what it did is not necessarily more useful than one that performs ten.
A fleet of solar installations that requires manually visiting every site to diagnose problems is not really a fleet. Maybe a chain?
A company full of AI agents doing invisible work while the founder discovers mistakes after the fact is probably worse than the company we started with.
Good leverage needs feedback. It needs observability and it needs control. To rewrite the age-old cliche: from where leverage is derived, data is expected.
I once tried starting an observability/APM company, around 3.5 years ago.
There is also a personal reason this appeals to me
I like small teams, I like people who can own large problems, and I like systems where understanding and integration matters more than ceremony.
I have never been particularly attracted to the idea of building a giant company simply because giant companies are what successful companies are supposed to become. There are problems that genuinely require huge organisations (like making humanity a multi-planetary species), but headcount is often used as a substitute for better systems. Something becomes difficult, so we add another person. That person creates a coordination problem, so we add a manager. The manager creates another interface and might require a manager of managers (like an executive or vice president).
Soon half the organisation's work is keeping the organisation synchronised, something I've seen at so many companies over the years.
Some amount of this complexity is unavoidable but a lot of it probably isn't. And in this AI age, a lot of such avoidable complexity should probably be recognised as a breach of fiduciary duty or something like that – because it's simply unnecessarily, one might even think purposefully, wasted money.
One of the promises of better software — and AI in particular — is that perhaps very small organisations can have much larger ambitions without recreating all of the organisational machinery that ambition traditionally required.
I find that prospect deeply appealing.
A five-person company doing something that would have required fifty people ten years ago. Or a founder who can test an idea in two weeks instead of raising money to hire six people before learning whether anybody cares. Or a doctor whose capabilities are amplified by every patient the system has previously learned from. Or an artist who spends more of their time making artistic decisions and less time fighting their tools. Or a small business whose limited energy infrastructure is intelligent enough that they can depend on it.
The constraint matters more than the technology
I think this is the part I'm still learning.
It is so easy, particularly as an engineer, to start with the technology.
What can the model do?
What can I automate?
What interesting system can I build?
That produces clever products surprisingly often, but I think it produces ground-shifting products much less often.
Leverage only matters relative to a constraint. If you multiply something nobody was short of, nobody cares.
If tattoo artists are not constrained by design iteration, making design iteration ten times faster does not matter.
If founders do not struggle with coordinating their organisations, Lucien is a solution looking for a problem.
If the real constraint on solar adoption is financing, the world's best monitoring dashboard will not fix it.
If people avoid medical testing because they fear judgement or disclosure, reducing the turnaround time from twelve hours to nine is almost irrelevant.
The job is to identify what is actually preventing the desired outcome and then attack that. This is a very different picture than simply chasing efficiency or productivity.
If you multiply something nobody was short of, nobody cares.
I have built enough things to know how easy it is to become excited about leverage that exists only in your own internal model of the problem.
Where this leads
I don't think my eventual company has to be an AI company. It well might be. I hope it, at least, involves software.
But "AI" isn't really the thesis. Neither are healthcare, energy, developer tools or any of the other categories I've spent time exploring.
The thesis is leverage: finding an important system, discovering the thing constraining it, and building something that meaningfully changes the ratio between input and output.
It may well be that I keep coming back to this thesis because of how aware I am of my own shortcomings in expertise and experience.
I don't particularly want software that helps me do the same things a little faster. I want tools that change what I can reasonably attempt and, understanding myself as well as I do now, I suspect a lot of the products I build from here will be attempts to do exactly that.