I build cloud-native platforms and AI systems, and lead the teams that ship both._

The problem

Video streaming is hard to build with a small team. Live and on-demand delivery needs infrastructure you don't want to run yourself. Viewers expect live chat that keeps up with the stream. Subscriptions have to be charged in the currency people expect, not one exchange rate for everyone. And the people running the platform need an admin portal that's a proper application, not a settings page bolted onto the main site. Getting all of that working across two clouds is what decides whether a two-person team can run this.

Decisions that mattered

1. 01

   I integrated a third-party video streaming service for both live and on-demand delivery instead of running streaming servers myself. A small team should rent that kind of infrastructure, especially before there's revenue.

2. 02

   Live-stream chat runs on WebSockets, separate from the REST API that handles everything else, so chat speed doesn't depend on a request and response cycle built for ordinary CRUD.

3. 03

   Payments pick the currency and gateway automatically from the visitor's timezone. Nigerian users pay in Naira through Flutterwave or Paystack, and everyone else pays in US dollars through Stripe. The app and the API agree on that choice, so the price shown is the price charged.

4. 04

   The admin portal is its own React and Vite app, deployed separately to Azure App Service, instead of a route inside the main Next.js site. The people running the platform get a tool built for their job, and it ships on its own schedule.

5. 05

   Sign-in uses NextAuth.js and JWT across the Next.js site, the admin portal, and the backend API, so there's one way of handling sessions instead of three.

6. 06

   Email goes through Amazon SES, with IAM permissions limited to SES only, even though the rest of the platform runs on Azure. SES is the right tool for deliverability, and the limited permissions can't reach anything else in the account. Azure Application Insights covers the backend and CloudWatch tracks email delivery, so a bounce shows up alongside everything else in production.

Outcome

Live at coventi.app. The backend API and admin portal run on Azure App Service with MongoDB as the database, and media lives in Azure Blob Storage and ImageKit. Code and deployments run through Azure DevOps, and Application Insights and CloudWatch cover monitoring across both clouds.

Products

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

The problem

Working across four industries in one company is a different problem from going deep in one. The compliance rules, the data model, and the cost of a bug change completely from product to product. An EMR's audit trail has nothing in common with a dealer system syncing inventory for more than 15,000 subscribed dealerships. A university portal serving more than 45,000 students has seasonal load that fintech never sees. And money has to reconcile. Architecture, permissions, and delivery habits carry across all four. Everything else has to be spotted early, before it gets built the wrong way.

Decisions that mattered

1. 01

   I 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 agreed up front instead of discovered during integration.

2. 02

   I treated permissions as part of the design from the start, not something bolted on afterwards. Role-based access control runs on Passport.js, AWS Cognito, and Google Cloud IAM, so what someone can do is decided from their identity at the boundary. With clinical records and financial data, that's a requirement, not a feature.

3. 03

   I built a shared set of frontend components and backend libraries, so a new product starts from working building blocks instead of a copied repository. Four products on one team only works if the common parts are genuinely common.

4. 04

   I moved infrastructure into code with AWS CDK and automated the path to production with GitHub Actions, GitLab CI/CD, and Azure DevOps. CloudWatch and Google Cloud Logging catch problems before customers report them.

5. 05

   Code review, written architecture notes, and mentoring are how standards stay consistent across four products and a distributed team. At that size you can't hold consistency in one person's head.

6. 06

   I built an MCP (Model Context Protocol) server at Exquis, which turned the AI direction into something shipped instead of a policy document.

Outcome

I was promoted twice in five years, from full-stack developer to senior to lead. That's the clearest sign the work held up, because it's someone else's judgement, not mine. I now own features across their whole lifecycle and set technical direction across the products. That includes bringing in AI-assisted development with a review rule attached: every generated change is read for correctness, security, and maintainability before it ships. It produced working software, not just guidelines, including that MCP server.

The problem

Financial software fails differently from most products. A slow page is annoying. A wrong balance, a permission that's too broad, or a transaction recorded twice is a regulatory problem. That changes what you optimise for: you trade some speed of delivery for isolation, clear contracts, and tests.

Decisions that mattered

1. 01

   I helped build a microservices architecture, mainly for fault isolation, so a failure in one financial workflow slows that workflow down instead of taking the platform with it.

2. 02

   I designed and documented API contracts in Swagger/OpenAPI before integration. That made connecting securely to internal and third-party financial systems predictable instead of a negotiation.

3. 03

   Authentication, authorisation, and role-based access control around sensitive financial data were design constraints from day one, not a hardening pass at the end.

4. 04

   I designed the MongoDB data models for integrity first and query speed second. In financial records, a schema that allows an inconsistent state is a bug waiting for the right sequence of writes.

5. 05

   Unit, integration, and automated tests ran through Azure DevOps pipelines, so deploying to a production financial system was routine instead of an event.

Outcome

I shipped secure, scalable features into production at surebanka.com, across React and Angular frontends and NestJS services on Azure, GCP, and AWS. It also gave me 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 website that does three different jobs at once. It has to sell devices and accessories from live stock. It has to put a real number on a used phone's trade-in value before the customer walks in. And it has to get people talking straight away, on WhatsApp, because that's how this business actually talks to customers, not email. None of those is hard alone. Getting all three right in one small app, built and maintained by one person and fast on a phone, is what makes it more than a template site.

Decisions that mattered

1. 01

   I built the trade-in flow as a real valuation model instead of a "contact us for a quote" page. It only accepts models the shop will swap: iPhone X through the 17 series, Galaxy S10 onward (including Fold and Flip, but not the A series), iPad 6th generation onward, MacBooks from 2018, and Pixel 6 Pro onward. It asks the questions that actually move the price: cosmetic grade, battery health, carrier lock, SIM type, repair and part-replacement history, and biometrics. Then it works out an estimate in the browser from the model's age, tier, storage, and condition, added up across every device the customer lists. The questions change by device type, so nobody with a MacBook is asked about a SIM.

2. 02

   The catalogue comes from a live AWS API Gateway endpoint instead of being baked into the build, so the business can change stock without a redeploy. The site doesn't trust that data blindly: it drops products that are unavailable or incomplete, falls back to a category image when a product has no photo, and shows twenty at a time with search, category, and condition filters.

3. 03

   WhatsApp is the enquiry channel, so I didn't build a contact backend. A floating widget, built with Angular 22 Signal Forms, writes a pre-filled message with the site's signature and opens WhatsApp directly. That matches how the shop already talks to customers, and there's no server to run for enquiries.

4. 04

   Discover is a reel-style feed that mixes devices with repair and trade-in services. It uses scroll-snap slides, an IntersectionObserver to track the active one, and a matchMedia switch between vertical paging on phones and horizontal paging from 768px up. Scrolling or swiping past the last slide loops back to the first.

5. 05

   I treated accessibility as a requirement, not a polish pass, with WCAG AA and AXE as the bar written into the project. There's a skip link, proper landmarks, focus moved into every dialog and returned on close, Escape to close, scroll locked behind modals, live regions for state changes, and a dark mode that follows the system setting, remembers your choice, and never flashes on load.

6. 06

   Deployment runs through a GitHub Actions pipeline. Pushing to a deploy branch builds the app, publishes it to S3, and invalidates CloudFront, signing in with GitHub OIDC and an assumed IAM role instead of long-lived AWS keys. Google Analytics only runs on the production hostname, so previews and local runs never skew the numbers.

Outcome

Live at matechinnovation.com, served from S3 through CloudFront on a Route 53 domain with an ACM certificate. Customers can browse live stock, get a trade-in price, and message the shop on WhatsApp, all in one app, with TikTok and Instagram posts embedded on the home page. It runs on Angular 22 with lazy-loaded routes and signal-based state, Tailwind CSS 4, and Vitest specs on the components and services. I designed, built, and maintain it on my own, with AI coding assistants speeding up implementation and every change reviewed by hand before it ships.