Omair Saleh

Full-Stack Engineer · AI-Native Builder

I take messy problems and
ship working software.

12 years building production systems — donation platforms, fintech, logistics, data pipelines, and AI agents. Solo builds, charity budgets, real users.

12 years · 29+ production apps · Payments · Logistics · Nonprofit · AI · Shipped solo

Each built solo. The real story is the mess I walked into and the decisions that got it shipped.

01

CharityRight — Donation Infrastructure Rebuild

Next.js 15 · Bun · Stripe · PostgreSQL · SQLite · Prisma · Docker · Live ↗

UK charity, ~£3.3M/year. When I joined, the technology was in fragments. Every donate button routed through an agency's hosted checkout the charity didn't own. Donations were scattered across three platforms with different payout cycles (2 days vs weekly vs two months). CRM integration was broken. Gift Aid reconciliation was manual. Mobile donation flow took over 30 seconds.

Over 18 months as the sole developer, I replaced every external dependency — 14 repositories. New checkout with Stripe PaymentIntents + SetupIntents, Apple/Google Pay, progressive disclosure, Zod validation. P2P fundraising engine with team pages, leaderboards, and URL attribution across 15 Prisma models. Config-driven campaign pages with a 30-field interface so the fundraising team could launch Ramadan appeals without a developer.

Then the data layer. Three sync pipelines: Enthuse via Playwright with a four-layer auth chain (SSO → magic-link email → Gmail OAuth → TOTP), LaunchGood via Playwright CSV export, and a MySQL→PostgreSQL warehouse with five data streams landing in raw tables then transforming into a canonical model. That model feeds N3O CRM queue payloads and a donor messaging system on n8n + Chatwoot + WAHA. Terminated the agency retainer (£1,200/month saved). Migrated hosting.

The decision that mattered

Nobody told me to handle Zakat compliance. I just knew that if a Muslim donor selects Zakat, the system needs to give them a clear choice about admin fees — because Zakat is a religious obligation with specific rules about how the money is used, and that choice needs to be explicit, not buried. I built it as a per-donation and per-plan toggle so the donor controls what happens, not the system. Nobody told me to move Gift Aid capture to post-payment either. But asking a donor for their home address before they've committed to giving kills conversion. I moved it. HMRC still gets what they need. The charity gets more donations. These aren't in any spec. They're the kind of decisions you only make if you understand the domain, not just the technology.


02

AI Outreach Engine

Python · OpenAI · PostgreSQL · Apify · In Production

The charity needed to reach partner organisations across the UK — 100K+ registered charities in the Charity Commission dataset. The fundraising team was manually searching, manually qualifying, manually writing emails. No tooling, no scale.

I built a pipeline: raw Charity Commission data into PostgreSQL, then OpenAI translates natural language queries ("education charities with income over £1M operating nationally") into SQL filter logic via a custom segment engine. Qualified leads get personalised outreach — emails and talking points generated against each charity's actual profile, income band, and operational focus. Not mail-merge. Apify enriches contacts to find the CEO or Head of Fundraising. The whole thing runs from a CLI with deterministic Python underneath.

The decision that mattered

The AI makes decisions, but the infrastructure is boring and reliable. On purpose. Retry logic, structured outputs, cost ceilings, caching layers, human-in-the-loop gates. Anyone can call OpenAI. The hard part is building the deterministic scaffolding that makes it safe to let AI call the shots — and knowing where the human needs to stay in the loop.


03

PledgeNow

Next.js 14 · PostgreSQL · Stripe · OpenAI · Gemini · Live ↗

Charities using third-party pledge platforms were losing money to fees, waiting weeks for payouts, and had no control over the donor experience. The existing options — Enthuse, LaunchGood — were slow to pay out, inconsistent with Gift Aid handling, and charged admin fees the charity couldn't avoid. I built an alternative from scratch.

Full pledge checkout with Stripe integration — commit now, pay later, with three payment rails (bank transfer, GoCardless direct debit, card). Pledge lifecycle tracks through five statuses: new → initiated → paid → overdue → cancelled. Built-in bank statement reconciliation with configurable column mapping. But the real story is the AI "Steward": an embedded assistant that helps fundraisers manage their campaigns. It uses OpenAI with Gemini fallback, structured function calling with 13 tools that return rich visual cards — stats grids, pledge tables, campaign detail, WhatsApp status, nudge drafts. Every response is grounded in real pledge data.

I stress tested it across 31 scenarios in 10 categories — both bash and Python harnesses. Dashboard overview, pledge lookups, campaign queries, setup status, action requests, navigation, edge cases (gibberish input, dangerous requests like "delete all our data"), brand compliance (regex checks for forbidden terms: "AI assistant", "language model", "ChatGPT", "artificial intelligence"), persona scenarios (event lead, treasurer asking about Gift Aid, attribution queries, pledge amendments, trustee report prep), and tone validation (gives specific advice, responds with empathy not shame). 31 of 31 pass.

The decision that mattered

The Steward never identifies as AI. It's a concierge, not a chatbot. The brand compliance tests grep the response for forbidden terms and fail the build if any appear. Every response references real pledge data, real campaign numbers, real donor activity — not vibes. If the data doesn't exist, the Steward says so instead of making something up. I built this because I've seen what happens when AI hallucinates in a trust-sensitive context. It destroys credibility instantly.

Also shipped

AI Command Center

Node.js · OpenAI · Sentry · GitLab API · PostgreSQL · MySQL

Six-agent autonomous system running on scheduled cycles. Safety agent checks command policy first. Reliability agent pulls unresolved Sentry issues and opens GitLab issues with severity mapping (p0/p1/p2). Code-steward reviews open merge requests, posts automated notes, blocks failed pipelines — up to 3 MRs per cycle. Analytics agent runs cross-database metric queries and publishes reports. Auto-pause on excessive API spend, command allowlists, dry-run mode. Nothing executes without human approval.

Hub Platform

Chatwoot · OpenAI · Node.js · Salla API

AI conversation intelligence for B2B customer service. When a support agent opens a conversation, the system pulls the customer's real order history from Salla and suggests contextual responses with structured function calling — actual order numbers, actual product names, actual interaction history. Not vibes-based autocomplete.

QuikCue — Self-Hosted Infrastructure

Node.js · Express · PostgreSQL · Ghost · Docker Swarm · Traefik · Live ↗

Full company platform: static site with live ship log API (CRUD + bearer auth + member filtering), dual Ghost blogs with separate databases, self-hosted Gitea, Chatwoot, n8n automation, WAHA for WhatsApp. Everything on Docker Swarm behind Traefik with auto-provisioned SSL. One server, one operator, zero managed services.

CIEF Worldwide — Logistics & Fintech Platform

Laravel 5.6–9 · Vue 2 · MySQL · Python · Docker

Six years, 4,300+ commits, nine repositories. Shipping portal (China→Malaysia logistics with 3 carrier APIs), cross-border currency exchange (MYR/RMB/USD booking-to-payment with Billplz, wallet system, bank reconciliation), CRM, customer portal, analytics dashboard with ML forecasting (Apriori, regression), Python ETL pipeline (49 MySQL tables → Google Cloud Storage). Six Laravel monoliths.

Problem first, not spec first

Most real problems don't come with specs. They come with deadlines, complaints, and half-understood business rules. I figure out what needs to exist, design it, and build it.

AI-native, not AI-curious

I don't prototype with AI. I ship with it. Every AI system I build has cost controls, structured outputs, human approval gates, and deterministic infrastructure underneath. The API call is the easy part.

Ship, then iterate

A working system in production teaches you more than six months of planning. I build the smallest thing that solves the real problem, ship it, and improve based on what actually happens.

Reduce complexity, increase leverage

Most software problems are complexity problems disguised as feature requests. I look for the architectural move that makes ten future problems disappear instead of solving them one by one.

Let's talk.

I don't need onboarding. I need a problem and a git repo.

omair@quikcue — terminal
omair@quikcue:~$ explore portfolio
Click to launch interactive experience
WhatsApp +60 11 6222 2512
Location Remote (UTC+8) · Malaysia — overlaps London hours

Available immediately.