Israel Abiona

Israel Abiona·Backend Engineer

I design backend systems that stay reliable under real load.

Payment flows, logistics APIs, and multi-tenant platforms across FinTech, EdTech, and SaaS — Django, FastAPI, PostgreSQL, Redis, and Celery.

5+ years across FinTech, EdTech, and SaaS. The full record lives on the resume.

  1. 01

    Built Tagon — logistics APIs with WhatsApp, Telegram, and Flutterwave.

    FastAPI · PostgreSQL · Redis · Celery

  2. 02

    Cut Reown's monthly infrastructure bill by 90% while hardening reliability.

    Django · Redis · Celery · circuit breakers

  3. 03

    Shipped PCI-DSS payment systems with bank rails and AI fraud checks.

    Stripe · Plaid · HuggingFace · AWS Lambda

  4. 04

    Scaled an EdTech school registry past two million Nigerian records.

    Django REST Framework · PostgreSQL

  5. 05

    Founded Milestone — milestone payouts for remote and contract work.

    Stripe · Flutterwave · Redis · Celery

  6. 06

    Architected multi-tenant dropshipping with logistics partner APIs.

    DRF · GiG · TopShip · Kwik

See the workGet in touch

Selected work

Three projects, each with the problem it solved and the call I made.

Tagon

Logistics infrastructure APIs so African businesses can automate delivery without rebuilding ops from scratch.

Delivery operations fragment across chat channels, payment providers, and internal dashboards. Without one API plane, every integration becomes a one-off webhook and a silent failure mode.

  • FastAPI
  • SQLAlchemy
  • PostgreSQL
  • Redis
  • Celery
  • Twilio WhatsApp
  • Telegram
  • Flutterwave

› What I built

  • Shipped a FastAPI service with async SQLAlchemy, Alembic migrations, and a warm DB pool so cold starts do not stall the first request
  • Wired WhatsApp, Telegram, and Flutterwave webhooks behind one /api/v1 surface with health checks that surface which integrations are live
  • Queued background work on Celery with Redis as broker — message delivery and payment side-effects stay off the request path
  • Separated web routes, API routers, repositories, and services so channel adapters can grow without coupling to domain logic
  • Configured JWT auth, Redis backoff, and Mangum-ready entrypoints for flexible deployment targets
Inbound channels and payment providers hit one API; Celery workers handle delivery and settlement against PostgreSQL and Redis.

WhatsApp

Twilio webhook

Telegram

Bot webhook

Flutterwave

Payment webhook

Tagon API

FastAPI /api/v1

Redis

Broker + cache

Celery workers

Async tasks

PostgreSQL

Source of truth

  • wa → api
  • tg → api
  • fw → api
  • api → redis (enqueue)
  • redis → worker
  • api → db
  • worker → db

› Why I built it that way

One API plane for channels, payments, and workers

Context
Logistics products usually grow chat bots, payment callbacks, and admin APIs as separate apps. That multiplies auth, logging, and failure handling.
Choice
Kept Tagon as one FastAPI application with versioned API routes, channel webhooks, and Celery workers sharing the same config and data model.
Because
A single contract for health, auth, and schema means a new channel is an adapter — not a new service to operate.

The hard part is not accepting a webhook; it is knowing which rails are configured when something fails at 2am. Tagon's health endpoint reports database, auth, WhatsApp, Telegram, Flutterwave, and Redis state in one place. Background work is mandatory for message and payment side-effects, so Celery is treated as part of the product, not an optional queue.

Options considered

Separate microservices per channelMonolith without workersOne API + Celery workers
Ops surfaceMany deploys and health checksOne deploy, blocked requestsOne deploy, async side-effects
Adding Telegram or WhatsAppNew service + networkingBlocks the request threadAdapter + queue task
Payment webhooksDuplicated auth and loggingSlow responses under loadShared schema, async settle
ChosenNoNoYes

Nobook

School finance and operations on Django — fees, attendance, students, and reports in one ledger-minded backend.

School admins juggle fees, attendance, and student records across spreadsheets. Without a single system of record, balances disagree and collections stall.

  • Django
  • Django REST Framework
  • PostgreSQL
  • Celery
  • Redis
  • Stripe
  • Twilio
  • ReportLab

› What I built

  • Modelled schools, students, attendance, lessons, finance, and reports as Django apps with a shared user domain
  • Integrated Stripe for payment collection and Twilio for operational messaging
  • Ran background jobs on Celery with Redis for notifications and report generation
  • Generated PDF reports with ReportLab for finance and school operations
  • Containerised and configured Fly.io deployment with Gunicorn and WhiteNoise for static assets
  • Produced a security review artifact (Nobook Security Review) as part of hardening the surface
School domains share one Django project; Stripe and Twilio sit at the edge while Celery handles async finance and messaging work.

School admin

Web / API clients

Nobook

Django + DRF

Finance

Fees & balances

Ops

Attendance · students

Stripe

Collections

Twilio

Messaging

Celery

Reports · notify

  • admin → api
  • api → finance
  • api → ops
  • finance → stripe
  • api → worker
  • worker → twilio

› Why I built it that way

Domain apps over a single god-module

Context
School platforms tempt you to dump fees, attendance, and academics into one models.py. That works until finance rules need different release cadence than attendance.
Choice
Split Nobook into focused Django apps — schools, students, finance, attendance, lessons, reports — sharing auth and a common project config.
Because
Each domain can evolve its models and Celery tasks without dragging the whole school surface into every migration.

Payments and messaging sit at the edge (Stripe, Twilio) while domain state lives in Django models backed by PostgreSQL. Celery keeps SMS and heavy PDF work off the request path. The security review forced an explicit look at auth, tenancy, and money-moving endpoints before calling the system production-ready.

Options considered

One monolithic appMicroservices per school domainDjango domain apps
Migration riskEvery change touches everythingDistributed transactionsScoped per app
Team speedMerge conflicts in modelsContract overhead earlyClear ownership boundaries
Ops costLowHighLow — one deploy
ChosenNoNoYes

Lura

Marketplace platform with financials, management tooling, and an AI submodule for product workflows.

Marketplace products need catalog, money movement, and ops tooling to move together. Bolting AI onto a chaotic domain model creates brittle prompts instead of reliable workflows.

  • Django
  • PostgreSQL
  • Redis
  • Docker
  • Fly.io
  • GitLab CI
  • lura-ai

› What I built

  • Structured the product around marketplace, financials, and management Django apps under one project
  • Added a dedicated lura-ai submodule so AI features can version independently of core commerce
  • Containerised the service with Docker and Fly.io config for repeatable deploys
  • Wired GitLab CI for automated checks on the main branch
  • Kept Redis available for caching and async workloads beside the primary SQLite/Postgres data path
Marketplace and financials own the domain; management operates them; lura-ai consumes structured domain data for assisted workflows.

Buyers / sellers

Marketplace clients

Marketplace

Catalog · orders

Financials

Money movement

Management

Ops tooling

lura-ai

Assisted workflows

Database

Domain state

  • buyer → mkt
  • mkt → fin
  • mgmt → mkt
  • mgmt → fin
  • mkt → db
  • fin → db
  • ai → mkt (reads domain)

› Why I built it that way

AI as a submodule, not a tangle in commerce code

Context
Embedding model calls inside marketplace views couples prompt experiments to payment and inventory releases.
Choice
Kept lura-ai as a git submodule beside the Django project so marketplace and financials stay the source of truth, and AI features consume them deliberately.
Because
Commerce correctness and model experiments have different blast radii — they should not share every deploy.

Lura's repository layout makes the boundary visible: marketplace, financials, and management own the domain; lura-ai sits alongside for AI-assisted workflows. CI on GitLab gates the main line. That keeps experiments moveable without rewriting checkout or ledger paths every time a prompt changes.

Options considered

AI inside every viewSeparate AI SaaS onlyCore Django + AI submodule
Release couplingPrompt change = commerce deployHard integration taxIndependent versioning
Domain truthScatteredDuplicated over HTTPOwned by Django apps
ChosenNoNoYes

Capabilities

What I've built in production — and the shape of each system.

  1. 01

    Apel Assets

    Investment operations APIs for an internal platform.

    Built backend systems on the flagship internal operations platform for Memo, Jobbing, requests and processes, plus trade requests and execution — wiring Qdata in a direct connection with CSCS APIs. Shipped direct-debit payment infrastructure on NIBSS so collections sit on the same operational surface as trading and workflow approvals. Also built APIs that managed communications and day-to-day workflows across Apel's group of companies — Wealth, Trust, Assets, and Registrars — so entities share process and messaging without forking separate stacks.

    Django REST Framework · Qdata · CSCS · NIBSS · direct debit · group workflows

    Group entities share one ops and messaging plane; trade execution hits CSCS via Qdata while NIBSS powers direct-debit collections.
    1. Wealth · Trust · Assets · Registrars
    2. Memo · Jobbing · workflows
    3. Trade via Qdata → CSCS
    4. NIBSS direct debit
    Capability 1 of 7
  2. 02

    Milestone

    Founded Milestone — milestone payouts for remote work.

    Built a project management and payment automation platform serving 30+ active users. Milestone-based flows with Stripe and Flutterwave cover subscriptions and automated payouts. Redis caching and Celery queues improved system performance by about 40%.

    Django · FastAPI · Stripe · Flutterwave · Redis · Celery

    Work milestones trigger billing and payout rails through one automation path.
    1. Milestone completed
    2. Billing service
    3. Stripe / Flutterwave
    4. Payout to contractor
    Capability 2 of 7
  3. 03

    ElitePayables

    Led PCI-DSS Accounts Payable with bank rails and AI fraud checks.

    Tech lead for an enterprise AP SaaS integrating Bank of America, Stripe, and Plaid for ACH. Designed PCI-DSS-compliant systems with HuggingFace fraud detection, Amazon Textract invoice automation, and multi-layer approvals across QuickBooks, SharePoint, and Google Docs. Serverless tasks ran on AWS Lambda with Dockerised containers.

    Stripe · Plaid · AWS Lambda · Textract · HuggingFace · PCI-DSS

    Invoices enter, get extracted and scored, then move through approval before ACH settlement.
    1. Invoice intake
    2. Textract + fraud models
    3. Approval workflow
    4. ACH via bank rails
    Capability 3 of 7
  4. 04

    Reown Africa

    Rebuilt Reown API V2 and cut infrastructure cost by 90%.

    Refactored the backend for a ~30% performance gain through query optimisation, caching, and DevOps restructuring. Led API V2 as the product pivoted to electric vehicle retail with real-time EV bike monitoring. Circuit breakers resolved launch-critical reliability issues and monthly infra spend fell from $150 to $15.

    Django · Redis · Celery · circuit breakers · cost optimisation

    EV telemetry and retail APIs share a hardened Django core with cache and workers.
    1. EV bike telemetry
    2. Reown API V2
    3. Redis + Celery
    4. Retail dashboard
    Capability 4 of 7
  5. 05

    RockTea

    Architected a multi-tenant B2B2C dropshipping platform.

    Custom DRF middleware, pricing automation engines, and client self-service site deployment. Integrated GiG, TopShip, and Kwik logistics APIs so platform merchants could fulfil reliably without owning every carrier contract.

    Django REST Framework · multi-tenant · logistics APIs

    Merchants share one multi-tenant core; orders fan out to partner logistics APIs.
    1. Merchant storefronts
    2. RockTea platform
    3. Pricing engine
    4. GiG · TopShip · Kwik
    Capability 5 of 7
  6. 06

    FCMB FlipToTech

    Powered a nationwide school registry past two million records.

    Built and deployed DRF APIs on PostgreSQL for a database of 2M+ Nigerian schools. Contributed to the flagship e-learning platform with React and Vue dashboards for progress tracking and course payment milestones.

    Django REST Framework · PostgreSQL · EdTech

    Nationwide school data feeds admin and learning products through one API layer.
    1. School registry (2M+)
    2. DRF APIs
    3. Admin dashboards
    4. E-learning progress
    Capability 6 of 7
  7. 07

    Shipped SlumArt donations and Queeka logistics aggregation.

    SlumArt: backend and payment integrations for a donation and art sales platform that raised $10,000+ for children in Lagos slums. Queeka: a logistics aggregation backend giving e-commerce businesses multiple shipping options through one unified API.

    Payments · logistics aggregation · social impact

    Capability 7 of 7

Build log

Releases, repositories, and writing.

What I have shipped, written, and opened — most recent first.

  1. 17 Jul 2026Shipped

    Tagon

    FastAPI logistics API with WhatsApp, Telegram, Flutterwave webhooks, Redis, and Celery workers.

    Entry 1 of 8
  2. 12 May 2026Shipped

    Nobook (Bond-Finance)

    Django school finance and operations — fees, attendance, Stripe, Twilio, and report generation.

    Entry 2 of 8
  3. 19 Mar 2026Built

    Lura

    Marketplace, financials, and management on Django with a dedicated lura-ai submodule.

    Entry 3 of 8
  4. 29 Jan 2025Opened

    HRBase

    Job recruitment platform connecting employers and seekers with Django-backed hiring flows.

    Entry 4 of 8
  5. 15 Oct 2024Wrote

    Navigating the Tech Maze

    Using job postings as a signal to stay relevant early in a tech career.

    Entry 5 of 8
  6. 18 Sep 2024Wrote

    Structuring API Responses with Custom Middleware in DRF

    Standardising Django REST Framework responses so frontend teams get a predictable contract.

    Entry 6 of 8
  7. 17 Aug 2024Wrote

    Technology As An Accelerator Of Momentum, Not The Creator Of It

    A short essay on approaching technology with the right perspective.

    Entry 7 of 8
  8. 15 Jul 2024Opened

    Code Review Helper

    FastAPI + Cohere assistant that reviews snippets for improvements and likely bugs.

    Entry 8 of 8

Last updated from public GitHub / GitLab activity

Cloud & platform

I run payment rails, queues, and cloud deployments that keep backends honest.

Operating

  • Docker & container deploys

    Containerised Django and FastAPI services with Fly.io and cloud targets for repeatable releases.

  • Celery + Redis

    Background workers for payouts, messaging, reports, and anything that must not block a request.

  • GitHub Actions & GitLab CI

    Automated checks and deploy pipelines across personal products and client work.

  • AWS & GCP

    Lambda task execution, managed databases, and cost-aware infrastructure — including a 90% spend cut at Reown.

  • Kubernetes & Terraform

    Cloud-native delivery patterns with infrastructure as code where the product needs it.

  • Payments & compliance

    Stripe, Flutterwave, Plaid, and PCI-DSS-minded designs for money-moving systems.

Foundations

  • Python · Django · DRF · FastAPI
  • PostgreSQL · Redis · MySQL · ClickHouse
  • AWS · GCP · Docker · Kubernetes
  • Terraform · ArgoCD · Nginx
  • LangChain · OpenAI · HuggingFace · Textract

Direction

What I am working on next.

  • ·Deeper AI agent workflows
  • ·n8n automations
  • ·Kubernetes / AKS patterns
From a git push to a monitored cloud deployment
  1. Git push
  2. CI (Actions / GitLab)
  3. Container image
  4. Registry
  5. Cloud deploy
  6. Health & alerts

Writing

Notes on APIs, Django, and how technology actually helps.

Published on Medium.

Get in touch

Building something? Let's talk.

Tell me what you are building, or email me directly and skip the form.

or send a message