I've built 20 apps for 13 clients across 6 countries, mostly in Flutter.
The other projects are in the index below, but these four give you a good idea of the kind of problems I've had to deal with.
The requirements weren't clear.
Two teams had already worked on the product before me, but the main problem wasn't the code. Nobody had properly figured out how the product was supposed to work.
I helped turn the loose requirements into something the team could actually build.
The app had to work without the internet.
This was software that had to run on physical hardware, with no reliable internet connection and no easy way to push an update later.
That changed how almost everything had to be built.
The problem wasn't really the app.
The business had hundreds of tables running on timers, and service was getting missed.
The client didn't come to me asking for three separate apps. They came asking why service was slipping.
The software was the answer.
Most of the difficult work was around media.
The product had a short timeline because investor meetings were already scheduled.
That meant getting the media pipeline, playback and delivery working properly without spending months building it.
Let me be honest with you.
Design is probably my weakest point.
I have a good eye for design. I can look at an interface and tell when something feels wrong, and I'm pretty good at taking an existing design and implementing it properly.
But designing a really creative app from a blank page? That's not really my thing.
So if you're building a product and you already have a UI/UX designer, I actually prefer that. You design the thing, and I'll make sure it looks like your design when it gets into the app.
If you don't have a designer, it's fine. I've built enough mobile apps to know the usual patterns, so I can still put something together that looks good and works properly.
It just probably won't be the most creative app you've ever seen.
I designed this website myself, so you can judge for yourself.
I don't like being the person who simply receives an API specification and says, "Yes sir."
The backend and mobile app are part of the same product, so I like talking to the backend developer about how their decisions affect the actual experience.
If a backend decision makes the mobile app slower, more complicated or unnecessarily expensive, I'll bring it up.
We'll look at the trade-offs together.
Maybe there's a better approach. Maybe there isn't. If the backend constraint is intentional and the trade-off makes sense, I'll happily work with it.
But if I need a WebSocket event instead of polling an API every time something happens, I'm probably going to ask your backend developer for a WebSocket event.
That's not me being difficult. That's just us building the same product.
I don't work on Saturdays or Sundays.
I'm very confident in how much I can get done between Monday and Friday.
So I don't really believe in leaving things until Saturday and then telling you, "I'll get it done this weekend." I'd rather work for 18 hours on a weekday than 2 hours on a weekend.
No. We'll get it done during the week.
The only exception is a serious production bug or something genuinely urgent that can't wait until Monday. If your users can't use the app, I'm obviously not going to say, "Sorry, it's Saturday."
Aside from that, weekends are for me.
Monday me can deal with the app again.
Some of these apps are publicly available. The rest were built for clients, internal teams, hardware, or products that never launched publicly.
Some are in closed testing. Some are waiting to launch. A few have since been retired.
That's the reality of client work. Not every product is meant to live in an app store.
And if one of these apps looks like it's not working, there's a good chance the backend has simply been switched off—not the app itself.
I'm Emmanuel, The Mastermind.
I build mobile apps in Flutter, usually for people who have a product they need turned into something real.
I started taking client work in 2024 and have been doing it since.
Most of the time, I've been the main engineering person on the project. On some projects I've also worked with backend developers and designers, which meant I was responsible for making sure the different parts actually came together.
That's taught me that a lot of problems between clients and developers aren't really technical problems.
They're communication problems.
Someone has an idea. Someone else has to turn that idea into requirements. Then someone has to turn those requirements into software.
I've spent a lot of time doing all three.
Working across different products has also meant making plenty of mistakes myself.
I've built architectures that couldn't handle the next feature. I've had integrations break after working perfectly. I've had apps rejected because I missed something I should have caught earlier.
You learn from those pretty quickly when you're the person who has to fix them.
I'm looking for a full-time remote mobile engineering role now.
After working on a lot of different products, I'd like to spend more time with one team and one product — understanding it properly, improving it over time and seeing what happens when you get to work on something for years instead of months.
Outside of work, I run a channel where I try to learn things I'm bad at, usually on a deadline, and document the process.
It's a completely different kind of work, but it's taught me a lot about learning quickly and actually finishing things.
I'm looking for a full-time remote Flutter or mobile engineering role.
Based in Lagos. Comfortable working across UTC−5 to UTC+4.
I reply to everything.