What I do
What I actually build.
Six kinds of project. Where I have shipped one before, the work is linked so you can go look at it instead of taking my word for it.
E-commerce stores
Online stores that take real money, not demo checkouts.
Product listings, cart, checkout and the payment state behind them. Paystack and card flows wired into live products, with the retry and webhook cases handled, because a store that loses one order in fifty is worse than no store at all. I have built both a full subscription-free store platform and a reusable storefront on top of it.
What you get
- Product listings, cart and checkout
- Paystack payments with webhooks handled
- A CMS so you edit products without calling me
- Order and subscription state that survives retries
Good fit when: You sell something and the current setup is manual, fragile or does not exist.
SaaS and web apps
Multi-tenant products with accounts, billing and permissions.
The kind of app where every customer gets their own workspace, their own data and their own bill. Authentication with real session revocation, subscription state, custom domains, offline behaviour and real-time updates. This is the work I do day to day as Head of Software Engineering at The Coast.
What you get
- Multi-tenant workspaces with proper data separation
- Auth, roles and session revocation
- Subscription and billing state
- Custom domains and real-time features
Good fit when: You are building a product people log into and pay for monthly.
AI-powered products
AI inside the product, plus the evals that tell you when it degrades.
I have shipped a plain-language answer engine over Nigerian tax law and a tool that checks claims against sources. AI features fail quietly: a model update makes the output slightly worse and no test catches it, because there is nothing to catch. I build the feature and the evals together so quality is a number you can watch.
What you get
- AI workflows built into real product features
- Evals so regressions are visible before customers find them
- Guardrails on what the model is allowed to do
- An honest read on where AI does not belong
Good fit when: You want AI in the product and you would rather it be measurable than magical.
Dashboards and tracking tools
Interfaces for data that changes while you are looking at it.
Live status, maps, filtering and the states most builds skip: empty, loading, stale and error. I built a package tracker with interactive maps, live updates and delivery predictions, which is mostly an exercise in showing people the truth about where something is without making them refresh.
What you get
- Real-time data with sane loading and empty states
- Maps, filtering and search that stay fast as data grows
- Charts and status views your team will actually read
- Access control on who sees what
Good fit when: You have data trapped in a spreadsheet or an API nobody can see.
Landing pages and marketing sites
Fast, editable sites that hold up on a cheap Android.
A landing page is judged in about two seconds on a slow connection, so I build for that first and add the nice parts after. Real content structure, working forms, and a CMS behind it so marketing can change copy without a deploy. The site you are reading is one of these, running on Payload.
What you get
- Built from your design, including the states designers skip
- A CMS so copy and images change without a developer
- Working forms with validation and spam handling
- SEO structure, metadata and social previews
Good fit when: You need a site that converts and that your team can edit.
Rescue and migration work
Taking over a codebase that is holding you back, without stopping feature work.
Sometimes the job is not a new build. I have moved a production app from one backend architecture to another while the team kept shipping. The migration is the easy half. The contract between the old and new sides is the real work, so I write that down before touching code and keep both sides honest until the old one can be deleted.
What you get
- An audit of what you have and what it is costing you
- A written contract between the old and new systems
- Incremental cutover instead of a release weekend
- ADRs so the reasoning survives after I am gone
Good fit when: You inherited a codebase, or the developer who wrote yours is gone.
However we start, it goes like this
01
Call
Twenty minutes. You show me the product and tell me what keeps breaking.
02
Build
You see it running every week, not once at the end.
03
Handover
Code, docs, and a build your team can run without me.
Not sure which one you need?
Tell me what is breaking