I did not begin Beaverly because I wanted to build an “AI startup.” I began with a much more practical frustration: financial-market work demanded too much operating from the person trying to use it.
I knew that experience personally. Trading had become a major part of my life, but the work around it was exhausting: watching markets, managing decisions, staying disciplined, and dealing with tools that assumed the user wanted to become a full-time operator.
I kept coming back to one question: how much of this work could dependable software carry without taking control away from the person using it?
I first tried to hand the problem off
I was not a software engineer when this started. I hired developers and tried to turn the idea into a product through other people. Some disappeared. Some attempts stalled. Some work came back incomplete. I also knew people who could have materially changed the situation, and more than once I built plans around help that never actually arrived.
Eventually I stopped building plans around rescue.
If Beaverly was going to exist, I had to build with no permission. Build regardless.
The conditions were not romantic
At different points while building Beaverly, I sold four phones.
The first was my iPhone 15. Later I bought and sold an iPhone XR three different times as money tightened again. For more than a year, I had no phone of my own at all. If I needed to post, reply to someone, or use my banking apps, I borrowed my wife’s phone.
My development machine was a Samsung NP300E5A-A0KUK from 2012. The battery had failed, so it was basically a keyboard attached to a television: remove power and everything died. The LCD was worn out and flickered badly enough that the screen could freeze every few seconds. Some keyboard keys and touchpad buttons barely responded.
And I was building in Nigeria.
Electricity became part of the development stack.
There were days when no light meant no meaningful work and my mood would crash because I could see exactly what needed to be done but could not do it. Then electricity would return at midnight and I would be genuinely happy because I had another window to ship.
So I would.
Midnight became 3am. 3am became 7am. I would sleep, wake around 10am or 1pm, and continue. Eventually I got sick from the grind.
Then I went back to building.
Not “budget tight” broke. Sell-my-phone-four-times broke.
I learned to build with AI because I had to
I was not an engineer when I started Beaverly. I had to become one.
AI changed what was possible for me. It became an implementation layer: a way to generate code, understand unfamiliar systems, debug faster, compare approaches, and move through areas I had never been formally trained in.
But production does not care whether the code came from a human hand or a model. Real users eventually find the weak assumptions. Providers fail. Networks fail. Deployments break things you did not expect. Models can be confidently wrong. Somebody still has to understand the product deeply enough to tell the difference between a convincing answer and a dependable system.
Shipping Beaverly forced me to learn the unglamorous side of engineering: reliability, security, state, integrations, infrastructure, failure handling, and the discipline of proving that something actually works outside a demo.
The test was never whether I could reproduce every line of syntax from memory. The test was whether I understood the system well enough to make it work in the wild.
Over time, I did.
I was not completely alone
Beaverly was founded by Kolawole Oyedeji and me. The product problem came from my years around the markets; building the company through the hard parts became work we carried together.
Kola kept standing with me when the build became difficult. There was a point where I could no longer split myself cleanly between earning money elsewhere and building Beaverly. He worked, supported me with cash when I could not afford to stop and earn, and also brought his cybersecurity experience into the systems we were shipping.
That mattered. Especially in a period where a lot of other expected help simply did not materialize.
The product kept teaching me what it needed to become
The first versions of Chilla were much more mechanical. Users connected an account, chose ways of working, chose markets, set boundaries, activated work, then inspected the results.
That was already useful automation, but it still left too much complexity with the user. We had moved work out of the market terminal and into a better interface, but the user was still operating the machinery.
The direction became clearer over time: the product should start with the person’s goal, not with the configuration needed to pursue it.
Eventually the product stopped being a tool and became a worker
Today the product idea is much simpler to explain: tell Chilla what you are working towards. Chilla handles the product complexity and brings the choices that still need you into the conversation. You stay in control of what matters.
That is where Chilla landed: tell it what you want, make the decisions that matter, let it do the work, and hear back.
That is a very different relationship from a dashboard, a trading bot, or an AI chat that happens to have a broker tool attached.
Why M-II exists separately
Making Chilla easier to talk to should not make financial work casual. M-II is the Beaverly AI system behind Chilla, powering the ongoing work, safeguards and live financial execution while the user experience stays simple.
You use Chilla. M-II is the system behind it.
The lesson became bigger than the product
The more Beaverly developed, the more obvious the underlying mission became. People should not have to become operators of increasingly complicated software just because software became more powerful.
Good software should absorb complexity. It should let the person express intent, keep important control explicit, do the repeatable work dependably, and surface the parts that deserve attention.
Financial markets are where Beaverly is applying that idea first.
Move financial work from something people operate to something software can carry.
What has not changed
The core motivation is still freedom from unnecessary operating work. Chilla should not demand that someone stare at charts all day to prove they are taking their finances seriously. It also should not hide risk, promise outcomes, or make important choices disappear behind “AI.”
The standard is harder than that: make the experience calmer while the systems underneath become more disciplined.
Beaverly did not come out of ideal conditions, a perfect machine, reliable electricity, a large engineering team, or people lining up to give me permission.
It came out of repeatedly losing the conditions I thought I needed and building anyway.
That is what I am still doing.
For the current company and product direction: