Four-plus years building and shipping APIs in Python and FastAPI — crash-ingestion pipelines for a live game, multi-tenant SaaS, real-time clinical systems, distributed job processing. I own services end to end: schema and API design through implementation, testing, deployment and production maintenance.
The work is built for production, not for a screenshot. Tenant isolation and authorization live in the dependency layer, not sprinkled through handlers; every schema change goes through Alembic. My largest system carries 248 passing tests against a CI pipeline that stands up live Postgres and Redis service containers on every push. I care about the part most portfolios skip entirely: what the system does on the bad path — when the model times out, when the token expires mid-socket, when two tenants collide.
I came to engineering from a law degree, retrained, and now teach this stack to cohorts of 40 developers — writing the curriculum, reviewing code, explaining why an architecture holds rather than just how to type it. That route is also why picking up something unfamiliar fast is the normal case for me, not the exception. Most recently that meant shipping a Web3 backend in a 48-hour hackathon, having never written one before.
Designed and deliver backend engineering training to cohorts of 40 developers — Python, REST APIs, SQLAlchemy, PostgreSQL and Git — through project-based learning, hands-on code review and worked solutions.
Mentor learner teams through end-to-end delivery on production-shaped projects: a job recruitment platform spanning candidates, employers, applications, interviews and administration, and a multi-vendor e-commerce marketplace.
Backend Engineer Tenece Services Ltd
Feb 2025 — Feb 2026 · Contract
Designed and shipped the crash-tracking service for Nautical Fury, a live game — capturing forced closes and crashes from both code errors and graphics overload so the game team could reproduce and fix them.
Built the real-time event ingestion pipeline on FastAPI and Celery, processing crash events, uncaught exceptions, request failures and performance anomalies through a distributed, event-driven architecture. Owned the service end to end, from system design and database architecture through to deployment and production maintenance.
Freelance Backend Developer
Dec 2021 — Mar 2025
Built and maintained REST APIs and backend services for 15 clients across software and technology projects — data modelling, business logic and third-party integrations in Flask, FastAPI, SQLAlchemy and PostgreSQL — plus database and automation scripting, and debugging inside existing client codebases.
Education
2016 — 2025
Diploma in Backend Engineering, AltSchool Africa (2024–2025). Bachelor of Laws (LL.B.), Enugu State University of Science and Technology (2016–2021).
A peer-to-peer naira ↔ USDC exchange on the Africa ↔ Bolivia corridor: local agents handle add-money and cash-out for Pollar wallets, and a Stellar escrow holds the USDC between the two legs. Either side can send first, because whoever moves first is never the side carrying the risk.
The whole design turns on one awkward fact: the other leg is a bank transfer the server will never see. So the escrow moves on evidence only — USDC is locked up front and released when the counterparty confirms, and a disputed order freezes on purpose. No timer advances it and no action is offered to either party, because whether naira actually arrived is not something the system can know. An operator settles it against the receipt.
The backend is functional core, imperative shell. Every rule — who may act on an order and when, what it costs, what an agent's float allows, whether a Stellar payment really funds a cash-out — is a pure function over immutable records in domain/, with no await, no I/O and no clock; now is passed in. Postgres, Stellar and Pollar sit at the edges and are handed to services explicitly. Enforcement and the actions the UI offers read the same state-machine table, so the buttons a user sees cannot drift from the rules the server applies.
Paying the same person twice is the failure that costs real money, so it gets its own decision layer: the Stellar gateway reports what the chain shows, a pure function judges it, and a second payout is reachable only by an operator marking the first one bounced — never by either party claiming a transfer failed. A public, sign-in-free proof page shows live escrow reserves against every agent's liabilities, each settled order linked to its on-chain transaction.
The escrow is the only leg the server controls — which is exactly why the bank transfer is the only thing left to dispute.
0 I/O in the domain layerStellar · USDC escrowPostgreSQLNext.jsLive demo
I owned the backend for a four-person ETHOnline 2026 submission — and I had never written a line of Web3 before the weekend started.
Intentra ties every payment to what a person actually authorised and what was actually delivered: the AI proposes, the human signs an EIP-712 mandate, USDC sits in a Solidity escrow on the Arc testnet, delivery photos are hashed and anchored on-chain, and a disputed job settles only on a split both parties signed. I built the FastAPI modular monolith that orchestrates it — the trusted coordinator that never holds funds.
The engineering discipline is the part I'd point at. Money states commit on chain events only: the API requests, an event watcher applies them. A single state machine is the only writer of transaction state, and that invariant is enforced by an AST scan in the test suite rather than by convention. Signature verification, idempotency keys, an outbox and a reconciliation pass hold the rest together.
Money states commit on chain events only — the API requests, the watcher applies.
20 test suites48 hoursEIP-712 · Solidity · The GraphFastAPI · PostgreSQL
A hospital-grade patient status platform. Clinical staff update patient state; families receive push notifications the moment it changes. Every hospital runs as a fully isolated tenant, and every access path enforces that boundary — which is the genuinely hard part.
Ships with role-based access control, WebSocket live updates behind a token watchdog, shift-handover workflows, emergency flags, a super-admin backoffice, and five dedicated documents covering architecture, security and operations.
One status change fans out two ways — and never leaves its hospital's tenant.
An LLM document-extraction service built as a multi-tenant SaaS backend. Upload a PDF, image or DOCX; get structured JSON back by async polling or webhook callback.
Schema-driven extraction runs through an LLM map-reduce pipeline with layered reliability, so a single model outage never permanently blocks a job. Redis Bloom filters catch duplicate uploads before they cost anything. API keys are hashed, tenants are fully isolated, job progress is persisted and streamable.
One model timeout cannot strand a job — each chunk fails and recovers on its own.
An asynchronous medication-adherence API with intelligent scheduling and multi-channel notifications — but the security model is the point: JWT token rotation, real session management, Redis-backed rate limiting, and Google OAuth.
Adds adherence analytics, a medication logging system, cron-driven reminder dispatch, Docker packaging and a GitHub Actions deploy workflow.
7 test suitesSQLAlchemy 2.0OAuth2 · JWT rotationDockerised
The backend curriculum I run, from pure-Python fundamentals through SQLAlchemy ORM modelling to a full FastAPI REST API with routers, schemas and auth.
Written to be read: each project stands alone, with worked solutions and the reasoning behind every design choice. If you want to know how I think about code, this is the fastest way to find out.
3 progressive projectsWorked solutionsLive cohort
04Practice
Architecture
Per-feature modules — models / schemas / service / routers — so a codebase stays navigable at 50 files and at 500. Multi-tenancy and authorization enforced once, at the dependency layer.
Data
Async SQLAlchemy 2.0 on PostgreSQL. Every schema change through Alembic — no create_all() in anything that matters. Trigram indexes and real constraints where the query plan calls for them.
Reliability
Celery workers for anything slow. Redis for caching, rate limits and deduplication. Retry-and-fallback layers around third-party calls, health endpoints, and persisted job state so nothing dies silently.
Security
JWT with rotation, RBAC, hashed API keys, rate limiting, Pydantic v2 settings. Secrets live in the environment, never in the repository.
Proof
Pytest suites that cover edge cases and failure paths, not just the happy one. CI on push and pull request. Pinned dependencies with comments explaining why each pin exists.