Backend engineer · Abuja, Nigeria

I build the systems
products depend on.

I design and ship backend platforms for fintech, safeguarding, and public-health products — turning dense operational rules into secure, dependable services that hold up in production.

Explore selected systems Résumé GitHub

systems-profile.tslive

API layerNestJS · REST · WebSockets

Domain servicesMulti-tenant business logic

Async workersQueues · cron · events

MySQL

MongoDB

Redis

Secure by designBuilt for changeProduction-minded

Years shipping backends: 5+
Transactions processed: $2M+
Production systems: 7
Countries deployed in: Multi

Portrait of Raymond Temtsen — **Raymond Temtsen**Available for work

00 / Profile

Backend engineering is where product promises become operational reality.

I've worked across startup teams to turn early concepts into maintainable web and mobile backends. My strongest work sits where business rules are dense: cooperative finance, safeguarding case operations, and public-health coordination.

I care about the less visible qualities that make software trustworthy — clear domain boundaries, tenant isolation, reliable background work, auditable state, careful access control, and integrations that fail predictably.

Isolation
I enforce tenant boundaries at the connection layer instead of patching them into individual queries.
Recoverability
I design deferred work to claim jobs atomically, recover stale leases, and retry within defined bounds.
Auditability
I keep financial and case state transitions explicit, versioned, and reconstructable.

01 / Featured systems

Work, shown from the inside out.

I break down each system by its purpose, architecture, integrations, and the engineering decisions I made while building it.

Fuse is cooperative banking software for African cooperatives. I joined the product as a core pioneer backend engineer and helped build the platform that processed more than $2M in transactions during its first three years.

NestJSTypeScriptMySQLTypeORMRedisBullRabbitMQDockerNginx

View repository

Purpose

Give cooperatives one operational system for member accounts, savings, lending, payments, governance, and administration without collapsing tenant boundaries.

My contribution

I build and continue to manage multi-tenant APIs at Tech Fusion Africa, translating cooperative finance rules into backend modules and long-running operational workflows.

Major functionality

Cooperator onboarding, profiles, tenant administration, plans, billing, permissions, roles, and staff operations.
Wallets, deposits, withdrawals, transfers, cooperative accounts, shares, dividends, subscriptions, and ledger history.
Loan types, applications, repayment schedules, liquidity, guarantor flows, and marketplace-linked lending.
Elections, polls, referrals, rewards, cashback, marketplace, PayFlow payroll, activity timelines, and analytics.

Architecture

I structured the platform as a NestJS monorepo that separates the HTTP service from a dedicated worker. I use MySQL and TypeORM to model common and tenant financial data, with Redis-backed caching and queues supporting hot paths. Scheduled and dynamic jobs handle settlements, reminders, billing, balance history, and other deferred work, while WebSocket and event modules support real-time and domain-event flows.

Integrations

Paystack & Flutterwave payments
Mono open-banking data
Twilio / Dialog360 messaging
SendGrid email
Prembly identity checks
Cloudinary & Filestack media

Engineering challenge

A cooperative banking platform combines tenant isolation with sensitive financial state. I address this with tenant-aware connections and cache interceptors, explicit ledger and settlement models, dedicated workers, throttling on sensitive endpoints, and risk-context/SAR event modules.

CIMS is a multi-tenant case information management system contracted by UNFPA and deployed in multiple African countries. I independently designed and built the APIs that power the platform.

NestJSTypeScriptMongoDBMongooseRedisRabbitMQWebSocketsDocker

View repository

Purpose

Help organizations record sensitive incidents, coordinate case work, analyze patterns, and strengthen gender-based violence response through one configurable platform.

My contribution

I owned backend API delivery, shaping the tenant model, case workflows, analytics surfaces, access controls, and supporting worker services.

Major functionality

Case intake, customizable questions, updates, comments, approvals, worker assignment, transfers, and activity history.
Organization, team, invitation, role, permission, billing, and subscription management.
Real-time messages and permission updates over WebSockets.
Statistics plus MongoDB aggregation pipelines for GBV/FGM, age, geography, and state analysis.

Architecture

I organized the backend as a NestJS monorepo with separate API and worker applications. I used MongoDB and Mongoose to provide a common database alongside dynamically created tenant connections and tenant-specific models. Redis cache interceptors protect repeated reads, while RabbitMQ microservice clients and scheduled workers keep background workloads off request paths.

Integrations

Twilio SMS
SendGrid email
Cloudinary & Filestack uploads
RabbitMQ services
WebSocket messaging

Engineering challenge

Sensitive case data must remain isolated while each tenant can customize its workflow. I combined per-tenant connections, guards, permissions, response filtering, rate limits, secure middleware, and cache routing that respects the active tenant.

naPTS is a pregnancy tracking system for registering pregnant women, coordinating community health workers, identifying follow-up priorities, and connecting operational teams to suitable facilities.

NestJSTypeScriptMongoDBMongooseJWTDockerGitHub Actions

View repository

Purpose

Turn nationwide registration and follow-up data into actionable, jurisdiction-scoped workflows without presenting rule-based risk flags as medical diagnoses.

My contribution

I designed the backend around explicit geography, authority, risk, assignment, reminder, and analytics domains, with an API service and an independent scheduled worker.

Major functionality

Pregnancy registration with idempotency, stored risk assessments, referral guidance, and secured self-service access.
CHW profiles, ward service areas, pregnant-woman assignment, visits, follow-up tasks, and operational profiles.
Facility readiness, jurisdiction hierarchies, scoped admin teams, and national/state/LGA visibility.
Dashboard analytics, risk distributions, priority queues, activity streams, OTP login, confirmations, and health reminders.

Architecture

I built separate NestJS service and worker applications that share MongoDB/Mongoose schemas and domain modules. I implemented a versioned rule engine to persist auditable assessments and a scheduled worker that selects reminder frequency from stored risk levels. Jurisdiction services derive access from authenticated memberships rather than trusting requested scope.

Integrations

Termii transactional SMS & OTP
Nigeria geography dataset
Docker Compose
DigitalOcean deployment workflow

Engineering challenge

The most interesting boundary is where clinical caution meets software automation. I designed the engine to preserve medical, access, and decision-readiness signals independently, store explanations and due actions, and emit a clear safety statement. I also made reminder jobs claim records atomically to reduce duplicate sends across workers.

The PSEAH backend supports safeguarding-oriented staff operations, structured learning, assessments, and a “Data to Action” ideas workflow.

NestJSTypeScriptMongoDBMongooseDockerNginxGitHub Actions

View repository

Purpose

Give distributed staff a governed place to learn, track progress, submit ideas, and let administrators manage content and teams at operational scale.

My contribution

I built a service/worker monorepo with role-aware APIs, durable import pipelines, staff onboarding, content administration, and deployment automation.

Major functionality

Published books, ordered chapters, video metadata, assessments, immutable attempt snapshots, and resumable learning progress.
Admin preview-and-confirm imports for DOCX, EPUB, XLSX, and JSON learning content.
Staff CRUD, office redeployment, CSV verification, and asynchronous bulk onboarding.
Team authority controls and auditable idea submission/review state transitions, including anonymous submissions.

Architecture

I built a NestJS API and worker that share MongoDB/Mongoose modules. I stage source files in GridFS, then use worker processors to claim jobs atomically, recover stale leases, generate previews, create drafts, and clean orphaned inputs. I automated DigitalOcean deployment with Docker Compose, Nginx routing, and GitHub Actions.

Integrations

MongoDB GridFS
DOCX / EPUB / XLSX parsers
Docker & Nginx
GitHub Actions
DigitalOcean

Engineering challenge

User-supplied documents are unpredictable and expensive to parse synchronously. I used a preview-and-confirm design to keep request latency low, report structured warnings instead of raw failures, preserve sources only as long as necessary, and protect historical assessment attempts from later content edits.

30Plus is a NestJS financial-services backend centered on clients, agents, wallets, structured savings, loans, collections, settlements, and related operational controls.

NestJSTypeScriptMySQLTypeORMRedisBullRabbitMQTwilio

View repository

Purpose

Coordinate field-facing financial operations and payment flows while keeping financial state transitions traceable and deferred work recoverable.

My contribution

I developed modular APIs and worker processes spanning product configuration, client and agent workflows, transactions, verification, notifications, and reconciliation.

Major functionality

Agent and super-agent management, groups, commissions, clients, teams, permissions, and activity timelines.
Plus Savings, target savings, Osusu, loans, guarantors, schedules, deposits, withdrawals, remittance, and disbursement.
Wallet and ledger histories, settlements, payouts, transaction resolution, direct debits, and USSD surfaces.
Scheduled closing, repayment, settlement, commission, notification, and reconciliation tasks.

Architecture

I separated the NestJS API from a dedicated worker service. I used MySQL/TypeORM repositories for financial entities and Redis caching with Redlock-style interceptors to coordinate concurrent work. Bull processors, RabbitMQ publishers, domain events, and cron tasks move slower or retryable operations off request paths.

Integrations

Paystack payments
Prembly verification
Twilio messaging
Brails services
Push notifications

Engineering challenge

Savings and settlement flows are concurrency-sensitive. I made transaction boundaries, lock interception, ledger settlement, replayable event handlers, and resolution tasks explicit instead of hiding them inside controllers.

Guardeum manages background-check submissions and internal review data, with user, staff, admin, analytics, activity, and partner-access modules.

NestJSTypeScriptMongoDBMongooseJWTCloudinaryDocker

View repository

Purpose

Collect verification information for operational teams while exposing only an intentionally limited result to an authorized external partner.

My contribution

I built the NestJS/MongoDB backend, protected internal management routes, and shaped a purpose-specific integration contract for background-check lookup.

Major functionality

Background-check submission, review, update, deletion, pagination, search, and aggregate dashboard counts.
User, staff, admin, role, activity timeline, and utility modules.
A partner endpoint that returns only identity and status fields for the latest email match.

Architecture

I organized the monorepo into NestJS modules backed by MongoDB/Mongoose models. I used JWT to protect internal reads and writes, global throttling to constrain request rates, and security middleware across the wider API.

Integrations

MongoDB / Mongoose
Cloudinary media
Partner API-key endpoint

Engineering challenge

I designed the partner lookup around data minimization: it escapes user input before an exact case-insensitive match, projects only contract fields, removes database identifiers, and compares API keys using constant-time primitives while failing closed when configuration is absent.

The Fuse Webhook Forwarder centralizes receipt and delivery of webhooks across Fuse and TechFusion services, including provider-specific Paystack, Mono, and Dialog360 routes.

NestJSTypeScriptAxiosDocker

View repository

Purpose

Acknowledge providers quickly while independently delivering the same event to multiple configurable downstream systems.

My contribution

I extracted webhook fan-out into a dedicated deployable service with source-aware routing, authentication, retry controls, and loop-avoidance rules.

Major functionality

Generic and provider-specific webhook endpoints with immediate HTTP 200 acknowledgement.
Parallel fan-out to configuration-driven targets with headers, timeouts, retries, and attempt logging.
Source propagation and Dialog360-to-Fuse filtering to prevent unintended forwarding paths.

Architecture

I built a stateless NestJS service that loads validated target configuration at startup. Delivery continues asynchronously after acknowledgement; each target gets an independent bounded retry loop and a source-qualified path. I used Docker and health-oriented process handling to keep deployment simple.

Integrations

Paystack webhooks
Mono webhooks
Dialog360 webhooks
HTTP downstream services

Engineering challenge

Webhook providers should not wait for slow internal systems. I separated acceptance from delivery, contained failures per destination, preserved provider context in headers, and added support for an optional incoming shared secret.

02 / Experience