Built,Not Given

Growing up in a family with very little teaches you something no classroom ever could: how to keep going without a safety net. My early years were long walks to school, arriving late more often than not, and sitting in rooms where even focus felt like a luxury, because getting by came before anything else.

I didn't grow up with technology at my fingertips. There was no laptop waiting on a desk, no fast internet, no shelf of books telling me what was possible. What I had instead was a daily, unglamorous lesson in making do with less.

When you have little, you learn to make the most of whatever is in front of you. You stop looking for easy exits and start looking for something you can actually move. You get good at making a little go a long way, and you carry that instinct into everything you touch afterward.

Before I ever wrote a line of code, I was already working. Street jobs to get by, whatever kept things moving that week. Work was never a choice I got to make. It was simply how life was.

Those jobs taught me how to show up when nothing about the day was easy, how to finish what I started even when no one was watching, and how to be useful inside systems much bigger than me.

It wasn't the kind of experience that fits neatly on a résumé. But it built the part of me that keeps sitting at the desk long after the excitement fades, the part that treats effort as the one thing I can always spend.

Before I wrote software, I was already working on systems. They were just mechanical instead of digital. I found my way into vehicle rewiring and mechanical troubleshooting, and later into Mechanical Engineering at university.

When you stare at a stripped vehicle harness or a dead engine, there is no room for guessing. A wire either completes the circuit or it doesn't. A part either holds the load or it fails. Physical systems are honest in a way that is almost harsh, and I came to respect that.

Working with my hands taught me how to follow a fault from the symptom back to the cause, how to respect the way things are built, and how to stay calm when a system refuses to start. Looking back, I was debugging long before I knew the word.

There came a point where effort alone wasn't turning into progress. University was getting harder to manage, and life wasn't matching the work I was putting in. I was running hard and going nowhere.

Then I reached out. A friend saw something in me that I was too tired to see in myself. He didn't just offer encouragement. He pointed me toward technology and helped me get into AltSchool in 2024.

That one conversation changed everything. It took the work ethic I'd built rewiring vehicles and getting by with little, and finally gave it a direction that could grow.

AltSchool was a full reset. At first it's easy to think software engineering is just learning syntax: how to write React, manage state, style a component with Tailwind.

That idea didn't last. I quickly saw that clean code is useless if it solves the wrong problem. Engineering isn't really about the language you write in. It's about thinking clearly, shaping the whole system, and understanding the person on the other side of the screen.

I had to drop the habit of just doing tasks and start thinking like a product owner, someone who asks why before working out how. That shift, from coder to product engineer, still shapes how I work.

Every developer has a project that breaks their brain in the best way. For me it was Scissor, a URL shortener. I remember looking at that site and feeling both intimidated and obsessed. The fluid layouts, the smooth interactions, the sheer precision of it felt years ahead of anything I could build.

Instead of moving on, I decided to rebuild it. I spent days pulling apart what I saw and trying to recreate it from scratch. I failed over and over. My animations broke, my layouts fell apart at the edges, and my logic didn't hold up.

But I kept staying up, fixing the pieces, and trying again until it finally worked. That obsession taught me more about frontend architecture than any tutorial ever could, because I wasn't following steps. I was taking excellence apart to understand it.

There's a version of tech culture that talks about learning to code as if it happens in a vacuum: just grab a laptop, open YouTube, and build. My reality was much heavier.

There were days and whole weeks where I couldn't afford enough mobile data to stream a tutorial or push code without counting the cost per megabyte. Learning had a price, and I paid it in choices about what I could and couldn't load.

That isn't a story for sympathy. It's the reason I build with so much discipline today. When you have to ration data just to read the docs, you don't waste time. You read carefully, think through your logic before you run a build, and treat every chance to learn as something you can't afford to waste.

Software is often painted as a solo pursuit: one engineer, alone in a dark room, with a keyboard. But my path was built by a group of people who shared what they knew, pushed my thinking, and refused to let me quit.

From the friend who first showed me the tech world, to mentors like Naheem, Hacksultan, and Stanley, down to the classmates who debugged beside me in the trenches, every milestone I've reached carries their fingerprints.

Building in the open means admitting that your growth is tied to the community that lifts you. It's a debt I try to repay by opening doors for the people coming up behind me.

Building under real pressure changed how I see my own ability. In a hackathon you don't have time to over-think or doubt your instincts. You have hours to spot a real problem, design a clear experience, build the frontend, and pitch a working prototype.

Standing there with my team as runner-up at the Zenith Hackathon, with a ₦10,000,000 prize, wasn't really about the money or the applause. It was proof I could hold in my hands.

It was the moment I realized that the late nights, the rationed data, and the failed prototypes had added up to real skill. I stopped wondering whether I belonged in the room.

Most developers build small demos that get abandoned after the first commit. I wanted to build something that would actually live and serve people. That's why I built, and still run, AltBase, a dedicated platform for AltSchool alumni.

AltBase isn't just a project. It's a real lesson in product ownership. From reshaping the database to building the real-time features that keep alumni connected, it forces me to deal with the messy side of running live software.

It taught me how to listen to feedback, manage the shortcuts you take under pressure, and ship updates without breaking what already works. I'm still building it, still improving it, and still learning from it every single week.

I'm not looking for a comfortable finish line. I'm chasing a genuinely better life, for myself, for the family that held me up, and for the people I'll get to build with and mentor, including through Badagry Tech Bridges, the community I started to open doors for others.

Every product I design, every rough edge I fix, and every line of code I write is a deliberate step toward that future.

I know for certain that I haven't built my best work yet. My curiosity is sharper than it was when I was rewiring vehicles, my thinking is stronger than when I wrote my first script, and my drive to solve real problems keeps growing. That's what gets me to the desk every morning.