Portfolio — 2026 · Lagos, Nigeria · Remote worldwide · Available Q2

I build automation systems
that run real businesses.

I'm Olawale Emmanuel Olaonipekun — an AI Automation Engineer specialising in production-grade workflow systems powered by n8n, large language models, and modern API ecosystems. I design and ship the kind of infrastructure that lets a small team operate like a much larger one — quietly, reliably, around the clock.

Watch it work — 90 sec ↗ View case studies
15+
Production workflows shipped
4
Live client systems
2
Cities served
24/7
Production uptime
Now Maintaining live commerce systems · taking on new automation work for Q2 2026
Live demo · 90 seconds · recorded today

This is what I build.

A customer scans a QR code, orders directly from the web form, pays through Monnify, and the kitchen receives the alert — all in under two minutes, no human in the loop. Watch the full flow happen end to end.

2 min
End-to-end order to kitchen
0
Manual steps required
3
Systems integrated in flow
01 About

Automation is not a tool. It is a discipline.

I treat every automation project the way a senior engineer treats production infrastructure — with retry logic, error logging, version control, and a clear handoff path. The goal isn't to build something clever in a sandbox. It is to build something that survives Monday morning at 8am, when a real customer is waiting on a real reply. I work at the level where a "small" bug means a customer paid for an order that never reached the kitchen. The work is making sure that doesn't happen — and that when it does, we know within ten seconds.

n8n is the orchestration layer, not the ceiling. When the visual editor doesn't reach far enough — and on real production systems it often doesn't — I drop into Code nodes, patch workflows at the database level, write Python scripts against SQLite to apply changes safely under transactions, and verify the result byte-by-byte before restarting the service. The framework is a starting point. The system is what you build around it.

My core stack is n8n for orchestration, Supabase and PostgreSQL for data, Anthropic and OpenAI for intelligence, and Twilio, Monnify, Telegram, and Google Workspace for the channels that businesses actually live on. I work primarily with founders and operators in West Africa, but I build systems that meet international standards.

Most of my work runs in production today — serving customers, processing payments, qualifying leads, and alerting kitchens that an order has come in. That is the only kind of work I take seriously.

Based in Lagos, Nigeria
Phone +234 706 231 5595
Availability Open to roles & contracts
Work mode Remote · Hybrid
Time zone WAT (GMT+1)
Languages English · Yoruba
Focus n8n · LLM workflows · Payments · Dashboards
02 Stack

The tools I reach for.

My stack is intentionally narrow and deep. I'd rather know eight tools deeply than fifty tools superficially — because production systems break in the details, and the details are where experience compounds. With n8n specifically: I've operated installations under load, recovered from database corruption, patched live workflows through the underlying SQLite, written custom error-trigger workflows, and built encrypted backup pipelines around the platform. That's the level of depth I bring to every tool on this list.

O

Orchestration

The control plane for every system I build. Self-hosted or cloud, with version-controlled workflow JSON.

n8n Make.com Cron
I

Intelligence

LLM integration for natural language, classification, qualification, and structured JSON extraction.

Anthropic Claude OpenAI GPT Whisper
D

Data

Relational and document storage, with row-level security and clean schema design as a default.

Supabase PostgreSQL Google Sheets Airtable
P

Payments

Nigerian gateways with webhook verification, idempotency checks, and server-side amount validation.

Monnify Paystack HMAC
C

Channels

The places real customers and teams actually are — messaging, alerts, and email infrastructure.

Twilio WhatsApp Telegram SMTP
F

Frontend

Lightweight, single-file dashboards, order forms, and admin panels — deployed to a CDN, secured with auth.

HTML/CSS Vanilla JS Chart.js Vercel
S

Scraping

Compliant data acquisition for lead generation and market intelligence pipelines.

Apify HTTP Request Cheerio
∞

Infrastructure

Linux servers with Docker, nginx, and SSL — configured by hand and documented for handoff.

Ubuntu Docker nginx Certbot
03 Selected work

Real systems. Real customers.

Six representative builds — each one chosen because it solves a clearly defined business problem, runs in production today, and demonstrates a different facet of automation engineering.

01

Amala Sky — WhatsApp Commerce Bot

Conversational ordering system · Restaurant chain · Three-branch deployment
Live in production · since April 2026
Before

Bulk orders handled manually in WhatsApp threads. Missed messages during peak hours. No visibility into what each branch was processing.

After

Orders auto-captured 24/7 in four languages. Voice notes transcribed automatically. Each branch's kitchen alerted in seconds. Operations visible on one dashboard.

What I built

A complete WhatsApp commerce stack — from message ingestion to kitchen alert — running 24/7 on dedicated cloud infrastructure. The bot understands natural language and voice notes in English, Pidgin, Yoruba, and Hausa, and adapts its menu, pricing, and delivery flow to the customer's city.

WhatsApp bot conversation showing city selection and menu options
Live conversationThe bot greets the customer, asks for the city, and routes through the entire ordering flow. Business name redacted; everything else is real.
  • Multi-step conversation engine — full state machine covering city selection, menu, cart, modifiers, delivery vs. pickup, summary, and payment, persisted per phone number.
  • Natural-language ordering — customers type in plain language or send voice notes; the LLM extracts items, quantities, and intent.
  • Discount tier logic — automatic bulk discounts applied server-side at summary stage, never client-trusted.
  • Real-time kitchen routing — payment confirmation fires an alert to the correct city's kitchen channel with the full order breakdown.
  • Abandoned cart recovery — scheduled workflow checks for incomplete sessions and re-engages customers automatically.
  • Daily operations summary — management receives an end-of-day report covering orders, revenue, and staff escalations.
02

Amala Sky — Web Order Form & Monnify Payment System

QR-code ordering · Virtual account payments · Instant kitchen routing
Live in production · since April 2026
Before

No way to take orders from walk-in customers who didn't want WhatsApp. Bank transfer payments had to be reconciled by hand. Card payments weren't supported at all.

After

QR-code ordering for any customer. Bank transfers, cards, and USSD via Monnify. Instant verified confirmation. Order arrives in kitchen the moment payment clears.

What I built

A mobile-first web order form and a fully integrated Monnify payment system, sharing the same workflow back-end as the WhatsApp bot. A customer scans a QR code, fills the form, and is redirected straight to a payment page — no WhatsApp required. The moment payment clears, the order flows into the same kitchen and management pipeline as every other order.

Mobile web order form showing cart summary
Web order form
Monnify payment page with bank transfer and card options
Monnify payment
n8n workflow handling web orders end to end
n8n workflow
  • Mobile-first order form — clean responsive web page customers reach by scanning an in-store QR code; submits to a secured webhook with anti-abuse headers and a server-side total recalculation.
  • Monnify integration — transaction-specific virtual accounts generated on the fly, supporting bank transfer, card, and USSD across all major Nigerian banks.
  • Inline payment redirect — the payment link appears directly on the success page and auto-redirects customers to Monnify, so QR-code customers never need WhatsApp.
  • Webhook payment confirmation — the bot confirms orders the instant Monnify reports a successful transaction; no manual reconciliation needed.
  • Server-side amount validation — the amount Monnify reports paid is checked against the amount the system stored at order time, preventing client-side manipulation.
  • Idempotency guard — the same payment reference is never processed twice, protecting against replay attacks.
  • Receipt & kitchen alert — on confirmation, the customer gets a WhatsApp receipt (if a number was provided) and the correct branch kitchen is alerted instantly.
  • Multi-branch settlement — Garki and Wuse branch revenue routes directly to branch-specific sub-accounts via Monnify income-split, with verified end-to-end transaction flow.
03

Amala Sky — Staff Operations Dashboard

Role-based admin panel · Live orders · Menu control · Branch analytics
Live in production · since April 2026
Before

Staff had to open Google Sheets, the workflow engine, and the payment dashboard separately just to answer "did this order pay?". No role boundaries; everyone saw everything.

After

One login. Kitchen staff see only their branch. Managers see analytics. Admins see everything. Menu availability toggles in real time. Token-gated APIs on every endpoint.

What I built

A single-page web dashboard with role-based access, authenticated login, and live data feeds from the same back-end that powers the bot — protected behind a secure path on the same domain.

n8n workflow handling dashboard login with rate limiting and lockout
Dashboard authentication workflowEnd-to-end login flow: input parsing, user lookup, lockout check, credential validation, attempt logging, and locked-account response branch.
  • Role-based access control — three roles (admin, branch manager, kitchen staff) with each role seeing only the data and controls relevant to their job.
  • Authenticated login & sessions — staff log in with username and password; sessions expire after a fixed window of activity and idle time.
  • Live orders feed — real-time list of incoming orders by branch, with status, customer reference, and totals.
  • Menu availability toggle — kitchen staff can instantly mark items as available or out-of-stock; the bot picks up changes within seconds, so customers never order what isn't available.
  • Branch analytics — managers see order volume, revenue, fulfilment status, and trend charts scoped strictly to their branch.
  • Token-gated APIs — every dashboard endpoint requires an authenticated token; no public scraping of customer data is possible.
  • Brute-force protection — five failed login attempts in fifteen minutes triggers a thirty-minute lockout, with attempt history logged for forensic review.
  • Logout & multi-device — clean logout flow; staff can work from any device with no local install required.
Amala Sky end-to-end system architecture
Amala Sky system architecture. Customer → order channel → WF-05 → Monnify → fulfilment + audit + nightly reconciliation. Every box is a workflow I built; every arrow is a path that handles real money in production today.
04

FOC INC — Strategic Event Calendar System

Operational database & live dashboard · Event-driven brand portfolio
Live · Phase 1 complete
The problem

FOC INC operates 17+ projects across food, talent, media, and brand services — all activated against a calendar of 50+ Nigerian cultural, music, food, and corporate events each year. The existing calendar was a static HTML page: beautiful to look at, impossible to query, and disconnected from operations. Leadership couldn't see at a glance which months were busiest, which projects were overcommitted, or where activations were colliding.

What I built

A relational database, a public-facing dashboard, and an admin layer — replacing the static calendar with a queryable, role-aware operational system the whole organisation can act from.

  • Relational schema — six interconnected tables covering events, categories, projects, activation links, locations, and post-event outcomes, with row-level security.
  • Live management dashboard — a single-page web app pulling real-time data, with overview KPIs, filterable event list, project leaderboard, and a year-at-a-glance timeline.
  • Custom admin panel — authenticated CRUD interface for non-technical admins to add events, manage projects, and upload briefs and flyers per event.
  • Recruitment & brand services modules — expansion layer adding role management, application tracking, and client brief intake on top of the same data foundation.
  • Phase 2 automation layer — n8n workflows for event countdowns, monthly digests, conflict detection, and post-event ROI collection.
05

Lead Intelligence Pipeline

Automated B2B lead discovery, qualification & scoring
Production-ready
The problem

Finding qualified prospects for an AI booking and receptionist offering — restaurants, salons, medspas, home service providers — requires combing through hundreds of listings across markets, evaluating each for genuine fit, and reaching the right ones first. Done manually it's a full-time job. Done badly, it burns budget on cold lists and erodes outreach reply rates.

What I built

A daily, fully-automated pipeline that discovers small businesses on Google Maps, normalises and deduplicates them, detects their existing booking tools from their website, qualifies each one with a structured LLM call, scores them with a deterministic weighted formula, and alerts the operator only on the highest-fit leads.

  • Daily discovery — scheduled workflow rotates through category and city seeds, hitting Apify's canonical Google Maps actor and returning structured place data.
  • Tech-stack detection — lightweight regex-based website analysis flags existing booking tools so we know exactly what's already in place.
  • AI qualification — a single Claude API call per lead produces structured JSON: sub-scores, pain points, signals detected, and suggested outreach angle.
  • Deterministic scoring — final 1–10 score is computed in code, not by the LLM, using a weighted formula across booking friction, manual dependence, automation gap, and activity signals.
  • Operator notification — high-value leads trigger an instant alert with the score, signals, and angle, ready for outreach.
  • Failure observability — scraper and AI failures land in a separate log with stage, error code, and seed query, so the pipeline degrades gracefully.
06

SmartBook AI — Booking & No-Show Prediction

End-to-end appointment automation with ML risk scoring
Shipped & open-sourced
The problem

Service businesses — salons, clinics, tutors, repair shops — lose a significant share of revenue every year to no-shows and missed appointments. Most are still operating on phones, WhatsApp threads, and spreadsheets, with no system for reminders, cancellations, or post-appointment feedback.

What I built

A full booking automation stack that handles the entire lifecycle — intake to feedback — with an ML layer that predicts no-show risk on every new booking and triggers proactive re-confirmation messages on the high-risk ones.

  • Booking webhook — receives requests, validates, saves to Supabase, calls the ML service for a risk score, and dispatches confirmation email + SMS.
  • Hourly reminder engine — sends 24-hour and 2-hour pre-appointment reminders via email and SMS, never duplicating.
  • Conversational booking — Claude-powered chatbot extracts booking details from natural-language messages and auto-creates the booking.
  • Cancellation & feedback loop — cancellation endpoint updates the record and notifies; a daily evening job emails one-click star-rating links to completed appointments.
  • ML no-show risk — FastAPI microservice serves a trained classifier; bookings above a configurable risk threshold receive an immediate re-confirmation SMS.
04 Security & Trust

Built like it matters. Because it does.

Automation systems handle customer data, payment flows, and business operations — which makes them attractive targets. Every system I ship is hardened against the realistic threats it will face, and is documented so the team that takes it over can defend it long after I've handed it off.

i

Payment integrity

Every payment webhook is verified by signature where the provider supports it, and the amount reported paid is independently checked against the amount the system stored at order time — so a tampered payload cannot result in a confirmed order.

ii

Idempotency & replay protection

Payment references and order IDs are tracked so the same transaction can never be processed twice. Replay attacks — the most common form of payment fraud against automation systems — are rejected at the workflow layer.

iii

Authenticated dashboards

Internal dashboards sit behind a login system, with role-based access enforced on every API call. Kitchen staff cannot see admin data; managers cannot see other branches; tokens expire after a fixed activity and idle window.

iv

Secrets & credentials

API keys, payment secrets, and service tokens are never hard-coded into shared files. They live in the workflow engine's credential store, environment variables, or auth files outside the code path — and rotate when a project changes hands.

v

Server hardening

Production servers run on Ubuntu with Docker isolation, nginx in front, SSL via Certbot, and firewall rules that close every port the system doesn't need. Direct access to internal services from the public internet is blocked by default.

vi

Observability & failure logs

Every workflow logs its failures to a dedicated channel — with stage, error code, and context — so a problem at 2am can be diagnosed at 9am without guesswork. Silent failures are the enemy of trust.

vii

Data minimisation

Workflows only request and store the data they actually need. Customer phone numbers, order references, and payment data live in scoped sheets and databases — never aggregated into one unprotected file.

viii

Handover discipline

Every system I ship comes with a credentials list (in the client's password manager, not mine), an architecture diagram, and a written plan for "what to do if this breaks." Security that lives only in my head doesn't survive contact with reality.

I assume an attacker is already trying. The job is to make the easy attacks impossible and the hard ones obvious enough to catch.

Every measure listed above is implemented and verified on at least one live system I operate today. Not a checklist of intentions — an inventory of what's actually running.

05 Production Track Record

Incidents handled, not avoided.

A system that has never failed is a system that has not yet been used in production. The real measure of an engineer is what happens in the first hour after something breaks. These are real incidents I handled on systems running today.

Recovered from full SQLite corruption in under 10 minutes

The workflow database corrupted mid-write during a routine update. Customer orders coming in had nowhere to land. I restored from the last verified snapshot, replayed the missing window from external logs, and had the system processing live again within the SLA window I'd set for myself. The root cause — concurrent writes to a single-file database — was then fixed structurally.

What this proved — the backup and recovery process I documented at build time actually worked when I needed it. Most engineers find out their backups don't restore on the day they need them. Mine did.

Closed a silent failure in the order pipeline

The order webhook was returning success even when the order itself failed to persist — meaning a customer could pay for an order that the kitchen never received. I identified the gap by tracing one anomalous reconciliation entry, traced it to a continue-on-error setting on the sheet-write step, and reworked the workflow so persistence failures are fatal and visible. The customer either gets a working payment link or a clear error — never a silent loss.

What this proved — I read every node my code touches, not just the ones I wrote. Silent failures are the most expensive kind because they only show up as disputes weeks later. This pattern is now closed across every workflow in the system.

Rotated leaked credentials with zero downtime

A service-account key had been embedded in an early version of a workflow file. The right move was full rotation. I generated the replacement, deployed it to every component that referenced it, deleted the old key at source — and then audited every caching layer I'd missed. Two of them surfaced bugs that would have failed silently once the old key expired. Both were fixed before the cutover.

What this proved — credential rotation is not a single change. It's a discipline of checking every place the credential could live, including the places you forgot you put it.

Two-hour debugging session resolved by reading bytes

A payment integration returned a "code not recognized" error for a value that the same API confirmed was registered against the same account. I cycled through every plausible cause — wrong API key, wrong contract, expired credential, permission boundary. None matched. The fix came from printing the value byte by byte and finding an invisible trailing space introduced two days earlier during a routine paste into a terminal editor.

What this proved — when an API error contradicts your understanding of reality, the answer is usually a character you cannot see. I added that to the playbook so the next person doesn't lose two hours to it.

Backups encrypted at rest, verified decryptable

The original backup script copied a plaintext database to cloud storage. After realising that the storage credential and the backup credential were in the same wallet — meaning a single compromise could leak both — I rewrote the script to AES-256-encrypt every backup with a passphrase stored separately from the system. Then I actually verified the decryption end-to-end by restoring a real backup into a fresh container. Then I deleted the old plaintext backups from cloud storage.

What this proved — "we have backups" and "we have backups that restore" are two different sentences. I make sure both are true.

Daily reconciliation, nightly

Every night at 23:00 Lagos time, a scheduled workflow compares the day's orders against what the payment provider settled. Mismatches alert me before they become disputes. This has been running continuously since April 2026 with zero missed nights.

What this proved — the best fraud prevention isn't a smarter signature check. It's a boring nightly job that runs forever and tells you within hours if something's wrong.

I assume an attacker is already trying, a customer is already confused, and a server is already about to fail. The job is to make those situations boring instead of catastrophic.

06 Services

What I'm good for.

I take on a narrow set of engagements where automation, AI, and operational rigour intersect. If your problem fits one of these shapes, I can almost certainly help.

/ 01

WhatsApp & messaging commerce

End-to-end conversational ordering, booking, and customer service bots on WhatsApp, Telegram, or SMS — with payment, voice notes, multi-language support, and human handoff when it matters.

/ 02

Payment systems integration

Monnify, Paystack, and international gateway integration with proper webhook verification, amount validation, idempotency, and abandoned-order recovery built in.

/ 03

Internal tooling & dashboards

Custom admin panels, operational dashboards, and role-based staff systems for teams that have outgrown spreadsheets but don't want a heavyweight SaaS bill.

/ 04

LLM-powered workflows

Production-grade integration of Claude, GPT, and Whisper into your existing systems — with structured output, retry logic, prompt caching, and cost guardrails.

/ 05

Lead generation pipelines

Automated discovery, qualification, and scoring of B2B leads from Google Maps, Yelp, and other public sources — with LLM-based fit analysis and operator-ready outreach angles.

/ 06

Audits & rescue work

Inheriting a messy automation setup that nobody trusts? I'll audit it, document it, harden it, and hand it back with workflows your team can ship behind.

07 Process

How I actually work.

Most automation projects fail because they get built before they get understood. My process exists to keep that from happening.

i.

Understand the operation

Before I open the workflow engine, I want to see how the work happens today — the WhatsApp threads, the spreadsheets, the workarounds. Automation that doesn't match how a team actually operates gets quietly abandoned.

ii.

Specify, then build

I write down the data model, the workflows, the integrations, and the failure modes before I build them. The spec is short. The build is faster because of it.

iii.

Ship the smallest useful slice first

A working booking webhook on day three is more valuable than a complete architecture on day twenty. I sequence builds so each phase delivers value independently.

iv.

Harden for production

Retry logic, error workflows, rate limiting, dedup, observability. Every production handoff includes a failure-mode walkthrough — not just a green checkmark.

v.

Document for the next person

Every system I ship comes with a one-page architecture diagram, a credentials list (in your password manager, not mine), and the answer to "what do I do if this breaks at 2am."

Available for new work — Q2 2026

Let's build something that actually ships.

Whether it's a full-time role, a fixed-scope contract, or an audit of an existing system — if it lives in the space between automation, AI, and real business operations, I want to hear about it.

olawaleemmanuel100@gmail.com ↗ LinkedIn ↗
Phone +234 706 231 5595 WhatsApp +234 706 231 5595 X @LaoniAI