Omeonu Joshua — Lagos, Nigeria
I'm a full-stack engineer in Lagos. For the last three years I've been shipping production systems — retail distribution, property management, learning platforms — for teams who notice within minutes when something breaks.
Currently at TechMinte, building Comtrova — and on the Hardeverse learning platform at Harde Business School.
01/Story
Seven years, one detour through mechanical engineering, and a slow education in what production software actually costs.
2019
I studied Mechanical Engineering at Nigeria Maritime University. Most of what I remember isn't thermodynamics — it's the discipline of tolerances. A part is either within spec or it isn't. You can't argue a shaft into a bearing.
That turned out to be the most useful thing I took into software.
2022
I wrote my first serious interface in my final years of school and immediately preferred it to everything else I was studying. The feedback loop was instant. Something either rendered or it didn't, and when it didn't, that was on me.
I taught myself React the slow way — building, breaking, rebuilding — until I could put something in front of a stranger without flinching.
2023
SalesUnbox was my first real production system: a retail platform used by hundreds of Nigerian SMEs, with merchant dashboards, inventory, orders and payments through Paystack and Flutterwave.
It taught me the part nobody warns you about. Shipping a feature is maybe 40% of the work. The rest is the states you didn't plan for — the failed charge, the duplicate submit, the merchant on a 3G connection in Aba whose token expired mid-checkout.
2023—now
At TechMinte I've worked across a lot of surfaces — an LMS, a marketing site, an AI dashboard, a media platform — usually as the person who takes a Figma file and a half-finished API and makes them agree with each other.
The habit I picked up here is boring and it's the one I'd bring anywhere: read the API response before you design the state. Almost every frontend mess I've had to untangle started as an assumption about data that nobody checked.
2025
I joined Harde Business School to work on Hardeverse, their learning platform — course delivery, quizzes, certificates, and four different programmes running off one codebase. I'm still there.
The enrolment flow is where I learned the most. The backend didn't return an application ID after payment, which meant a learner could pay and end up in no programme at all. Rather than wait for a fix, I built an unreconciled-payment path that records the charge and resolves it later. You rarely get to choose the API you're handed — only whether your app degrades or dies when it misbehaves.
2025
Comtrova is a property management platform — multi-estate, role-based, money moving through it. Facility managers, estate admins and residents all see a different product built from the same data, which meant building two front-ends against one API and keeping them honest as it changed underneath me.
It's the first codebase where I've been responsible for the architecture rather than just the screens, and the first where getting a permissions boundary wrong has consequences that aren't visual.
2026
Every app I'd built until then fetched its state. RadCare pushes it — patients and caregivers messaging over a socket while the same data sits in an RTK Query cache that thinks it knows better.
Reconciling those two is the hardest bug class I've worked on. A cache and a socket will always disagree eventually; the design question is what happens when they do. I now reach for that question before I write the first subscription.
2026
Every system before this one had a backend somebody else wrote. Kabs Diner is a restaurant platform where I designed the schema, the auth and the payment verification myself — supper-club bookings, an online store, one admin dashboard behind both.
The lesson arrived in the first week: I put payment verification in the browser, realised anyone could mark an unpaid booking as confirmed, and moved it into an edge function. Anything a user can benefit from lying about has to be decided by the server. Obvious in hindsight, which is how most of the good ones land.
02/Work
Work I can talk about for an hour. Different domains, but a recurring problem each time: several front-ends, one API, and a permission model deciding what each person is allowed to see. The last entry isn't finished — its build status is listed with it.
Frontend lead · two clients
A multi-estate management platform running two separate front-ends against one API: an admin panel for estate managers and facility staff, and Mello, the resident app. Same data, different permissions, genuinely different products. Service charges and utility payments move through it, so the failure modes are financial rather than cosmetic.
Frontend engineer · client app + admin consoleIn private beta
A platform connecting patients with caregivers — scheduling, real-time messaging, care plans and billing on the patient side; credential verification, assignment management and vendor oversight on the admin side. The first thing I've built where the state isn't just fetched, it arrives.
Frontend engineer · contractInternal — no public link
Two internal systems for a global nutrition organisation: a procurement and approval portal, and a card reconciliation tool. Corporate environment — staff sign in against the organisation's directory, finance data comes from their ERP, and the app ships through a containerised pipeline rather than to a static host.
Full-stack · sole engineer
A restaurant platform built end to end: a ticketed supper-club booking system, an online food store, and one admin dashboard behind both. The only project where I designed the database rather than consuming someone else's.
Frontend engineer · learner portal + admin
The platform behind Harde Business School — course delivery, assessment and certification for learners, with an admin dashboard for the people running the programmes. Four programme types share one codebase, which is most of the interesting problem.
Backend · sole engineerIn progress
A REST API for my university's alumni network, and the first backend I'm writing by hand rather than consuming. Authentication, the role model and validation are being built rather than configured — that's the layer every other project on this page let somebody else own.
Build status
03/Craft
Not a process diagram. Three things I actually believe, learned the expensive way.
The unglamorous implementation that works on Monday beats the elegant one that lands in three weeks. I'd rather put something real in front of users and let their behaviour tell me where the complexity actually needs to go.
Most frontend messes I've inherited started as an assumption about the shape of a response. I check the payload first, model the state around what the server actually sends, and raise the gap with the backend team on day one rather than patching around it for a month.
Loading states, empty states, the error message when the network drops halfway through a payment. Users never see your architecture. They see what happens when things go wrong, and that's the part that decides whether they trust the software.
Every day
Regularly
Have shipped with
04/Next
Three things I'm pointed at, and an honest account of how far along each one is.
01Shipped the surface
I built the dashboards for Magent, an AI marketing platform, which meant designing UI around model output — streaming responses, partial states, results that arrive wrong sometimes. What I want next is the layer underneath: structured extraction, tool calling, and the evaluation loop that tells you whether a prompt change made things better or just different.
StandingComfortable building interfaces over an AI backend. Now working through the integration layer myself.
02Already doing it
Most of what I've built replaces a spreadsheet and a WhatsApp thread — approval routing at Nutrition International, card reconciliation against internal records, multi-format export at Harde, payment verification in a Supabase edge function. It's the part of the job I like most, because the before-and-after is measured in someone's afternoon.
StandingExtending into scheduled jobs, webhook-driven reconciliation and background processing rather than user-triggered actions.
03Building now
Every production system on this page is me consuming an API someone else designed. Kabs Diner got me closer — I modelled that Postgres schema and moved payment verification into an edge function — but Supabase handles the parts I most want to understand. So I'm writing one properly: an Express and MongoDB API for my university's alumni network, with the auth, role model and validation layer built by hand rather than configured.
StandingStructure and database layer are in place; auth and profile endpoints are what I'm writing now. It goes in the work section above once it serves requests, not before.
04Early
Almost everyone using what I build is on a phone. I rebuilt the Comtrova portfolio dashboard mobile-first after finding estate managers never opened it on a laptop, and Mello is a resident app people check between other things. Responsive web goes a long way, but push notifications, offline reads and camera capture don't.
StandingLearning it now. Nothing shipped yet — I'd rather say that than imply otherwise.
What I want alongside all of this is a team with real users and engineers more senior than me to argue with. I've built the same problem three times now — several clients, one API, permissions deciding what each person sees — and I'd rather go deeper on one product than wider across six.
04/References
Josh takes a design and an unfinished API and makes them agree with each other. He surfaces the gaps early instead of quietly working around them, which saves the whole team time.
Detail-oriented and fast to understand the business behind the feature. He asks the question the rest of us should have asked.
06/Contact
I read everything and reply within a day. A sentence about what you are building is enough to start.
joshuaomeonu@gmail.com