I build cloud-native SaaS platforms, and lead the teams that ship them._

The problem

Streaming is an unforgiving thing to build with a small team. Media has to be delivered fast and stay protected, subscriptions have to clear through payment rails that differ by country, and the same product has to work on web and mobile without maintaining two codebases' worth of business logic. Any one of those is a project; together they decide whether the company exists.

Decisions that mattered

1. 01

   Built the backend serverless-first on AWS Lambda and DynamoDB rather than standing up servers. Pre-revenue, the fixed cost of idle infrastructure is the thing that kills a small platform; this way the bill tracks actual usage.

2. 02

   Integrated three payment gateways, Stripe, Paystack, and Flutterwave, instead of one. A single processor cannot serve both Nigerian and international subscribers well, and payment failure is churn you never see coming.

3. 03

   Protected media with signed delivery through CloudFront and S3, and put JWT authorisation with fine-grained RBAC in front of every business endpoint, so access control is enforced at the boundary rather than assumed by the client.

4. 04

   Made one OpenAPI-documented REST surface the contract for both clients. Web and mobile consume the same endpoints, so subscription and entitlement logic exists in exactly one place instead of drifting apart across two implementations.

5. 05

   Wired unit, integration, and end-to-end coverage (Jest, Supertest, and Playwright) into the deployment pipeline, so a regression in payment or authentication fails in CI rather than in front of a paying subscriber.

Outcome

Live at coventi.app across web and mobile, with transactional email through Amazon SES and production alerting through CloudWatch. Every release goes out through an automated pipeline, which is what makes shipping on a two-person team sustainable rather than nerve-racking. AI coding assistants (Claude Code, Copilot, and Codex) speed up day-to-day implementation, with every generated change read for correctness before it ships.

Products

• Dealer management SaaS (DMS, 15k+ customers)
• Medical EMR
• University portal (45k+ students)
• Fintech platform

The problem

Working across four industries inside one company is a different problem to going deep in one. The compliance surface, the data model, and the cost of a defect change completely between them: an EMR's audit trail has nothing in common with a DMS syncing inventory for 15,000-plus subscribed dealerships, a university portal serving 45,000-plus students has a seasonal load fintech never sees, and money has to reconcile. What generalises across all four is architecture, authorisation, and delivery discipline. What doesn't has to be recognised early, before it's built the wrong way.

Decisions that mattered

1. 01

   Drew service boundaries so teams could ship independently: event-driven services on NestJS and Express, deployed across Cloud Run and AWS Lambda, with API contracts defined up front rather than discovered during integration.

2. 02

   Made authorisation a first-class design problem rather than a middleware afterthought: role-based access control backed by Passport.js, AWS Cognito, and Google Cloud IAM, so permissions resolve from identity at the boundary. Across clinical records and financial data, that is the requirement, not a feature.

3. 03

   Built a shared layer of reusable frontend components and backend libraries, so a new product starts from working primitives instead of a copied repository. Four products with one team only works if the common parts are genuinely common.

4. 04

   Moved infrastructure into code with AWS CDK and automated the path to production through GitHub Actions, GitLab CI/CD, and Azure DevOps, then wired CloudWatch and Google Cloud Logging so problems surface before customers report them.

5. 05

   Treated code review, written architecture documentation, and mentoring as the mechanism that keeps standards consistent across four products and a distributed team. At this scale, consistency is not something you can hold in one person's head.

Outcome

Promoted twice in five years, from full-stack developer to senior to lead: the clearest signal available that the work held up, because it's someone else's assessment rather than mine. I now own features across their full lifecycle and set technical direction across the products, including adopting AI-assisted development with a review discipline attached: every generated change is read for correctness, security, and maintainability before it ships.

The problem

Financial software has a different failure cost to most products. A slow page is an annoyance; a wrong balance, a permission that resolves too broadly, or a transaction recorded twice is a regulatory problem. That changes what you optimise for: you trade some velocity for isolation, contracts, and tests.

Decisions that mattered

1. 01

   Contributed to a microservices architecture specifically for fault isolation, so a failure in one financial workflow degrades that workflow rather than the platform.

2. 02

   Designed and documented API contracts in Swagger/OpenAPI before integration, which is what made secure connection to internal and third-party financial systems predictable instead of a negotiation.

3. 03

   Built authentication, authorisation, and role-based access control around sensitive financial data as a design constraint from the start, not a hardening pass at the end.

4. 04

   Designed the MongoDB data models around integrity first and query performance second. In financial records, a schema that permits an inconsistent state is a defect waiting for the right sequence of writes.

5. 05

   Made release confidence explicit with unit, integration, and automated test suites running through Azure DevOps pipelines, so deploying to a production financial system was a routine event rather than an occasion.

Outcome

Shipped secure, scalable features into production at surebanka.com across React and Angular frontends and NestJS services, spanning Azure, GCP, and AWS, and built the habits around contracts, isolation, and testing that I've carried into every system since.

Products

• Phone & gadget repairs
• Smartphone & device sales
• Device trade-in / swap
• Genuine accessories

The problem

A local repair and retail business needs a site that does three unrelated jobs well at once: sell accessories and devices, put a real number on a used phone's trade-in value before the customer walks in, and get someone into a conversation immediately, where WhatsApp, not email, is how this business actually talks to customers. None of those is hard alone. Getting all three right in one small app, built and maintained by one person, is what makes it a real project rather than a template site.

Decisions that mattered

1. 01

   Built a full trade-in valuation flow instead of a static "contact us for a quote" page: a brand and model catalogue (iPhone through the 17 series, Samsung S10 onward, iPad, MacBook, Google Pixel), a condition questionnaire covering battery health, cosmetic condition, carrier lock, and repair history, and a computed estimate breakdown, so a customer has a number before they ever reach out.

2. 02

   Skipped a contact form and email backend for the primary channel entirely: the WhatsApp widget composes a signed, pre-filled message and opens it directly in WhatsApp, matching how the business already talks to customers, with no server to maintain.

3. 03

   Built the site's forms on Angular v22's Signal Forms rather than mixing form patterns: signals for state, computed() for derived values, no NgModules, matching a WCAG AA and full-AXE accessibility bar set as a hard requirement from day one.

4. 04

   Embedded TikTok activity with TikTok's own embed widget rather than building and maintaining a custom feed integration, keeping content that changes daily out of the site's own build and deploy cycle.

5. 05

   Backed the site with a serverless API on Lambda and DynamoDB rather than a server to patch and scale by hand, and deployed the whole stack (S3, CloudFront, Route 53, a certificate through ACM) with AWS CDK, so the app and its infrastructure ship from one reproducible, version-controlled pipeline.

Outcome

In active development: architected, built, and maintained solo, end to end, for a phone and gadget repair, sales, and trade-in business in Opebi, Lagos, with AI coding assistants speeding up implementation and every change reviewed by hand before it shipped.