Ship the MVP fast, then harden it
A product that exists can be corrected. Most of my launches were measured in days or weeks, and the hardening happened against real usage instead of an imagined version of it.
I started as the sole engineer at Astrodipity while I was still finishing my Computer Science degree at the University of Ilorin — BSc, Second Class Upper, December 2022. Lectures in the day, production incidents at night. It taught me early that the interesting part of software is not writing it, it is keeping it alive.
From there to GetZing.ai, and now GoodAction. The through-line has never changed: I ship alone or as the primary engineer, and I own the outcome rather than a slice of it. Mobile app, backend, pipeline, IAM policy, review rejection — all of it is the same job to me.
That means I am comfortable in the parts of product engineering people usually hand off: negotiating an App Store rejection with Apple, wiring GitHub Actions into AWS with OIDC instead of long-lived keys, deciding which half of a data model belongs in Firebase and which half belongs in PostgreSQL.
I work from Nigeria on UTC+1, which overlaps US mornings, and I have only ever worked remotely — with teams in Canada, Maryland and Atlanta. Remote is not an adjustment for me; it is the only way I have ever shipped.
A product that exists can be corrected. Most of my launches were measured in days or weeks, and the hardening happened against real usage instead of an imagined version of it.
If I wrote it, I own how it reaches production: pipelines, IAM, alarms, rollbacks. Code that only runs on my machine is not finished work.
Every model call returns a shape the application can parse, under an explicit token and cost ceiling. Non-deterministic output belongs behind a contract.
Rejections are a build problem, not a paperwork problem. I have cleared App Store review rejections directly with Apple and treat the review queue as part of the release pipeline.
2025 · ROLE 1 / 6