I build AI systems that answer customers on WhatsApp, and I keep them running in production.
Open to senior roles and projects · Kuala Lumpur, UTC+8 · remote or on-site
A customer asks a small business a question on WhatsApp at 11:42 pm. Nobody is at the desk. The next five stops are what happens before they get an answer, all built and run by me.
I write the design first, high level and low level, covering scale, security and cost. Then I build all of it: the backend, the AI layer and the AWS infrastructure behind ezychat.io. Hover the hologram to see the parts.
The reply is marked as owed in the same transaction the message is saved, so a crash can’t lose it. Try it: kill a worker mid-reply.
Ask about my work. This runs a real search over 22 facts from my CV in your browser, with the same rule as production: below the score floor, it declines instead of guessing.
Drag the load up and watch the dashboard. These are my real load-test numbers from a production-sized task: throughput fell as callers rose, until I added admission control.
throughput 157.6 req/sp99 107 ms
The fix derives the concurrency limit from a 200 ms latency target and sheds overflow with a 503. At twice the load, p99 fell from 6.5 s to 3.7 s.
Sent exactly once, inside WhatsApp’s 24-hour window, priced on a per-call ledger. That’s ezychat.io, an AI platform with paying customers. I can build yours, or join your team.
Scroll to fly through the system, or pick a stopScroll through the system, or pick a stop
Three systems I shipped and ran in production: the problem, what I built, what changed, and the decisions behind it.
Small businesses lose customers who message on WhatsApp, Instagram or web chat when nobody is free to reply.
The whole backend: AI employees with hybrid RAG and tool calling for bookings and orders, a shared inbox, model failover, Stripe usage billing and the AWS stack in Terraform.
API throughput 35 → 70 req/s, p50 349 → 121 ms after a load test at production size. No reply is lost by design: every owed turn is swept and replayed.
Site teams run projects in WhatsApp groups, so tasks, defects and decisions get buried in chat.
The HLD, LLD and backend: a REST API, a real-time WebSocket hub and an AI service. The agent turns chat into tasks and defect reports, reads photos and voice notes, and writes the nightly site report.
In production with contracting companies across Malaysia, with Docker deploys to AWS through GitHub Actions.
New features could slow pages down without anyone noticing, until search rankings dropped.
Real-time Core Web Vitals monitoring from real users through Logstash into Elasticsearch and Kibana. I also owned AdTech across regions.
Slowdowns caught before they hurt SEO. 10M+ ad impressions a month without slowing pages, and ~25% lower Datadog costs.
The ezychat.io API was load-tested at production size: 0.25 vCPU, 50 tenants, 400,000 conversations and 2 million messages. One tenant holds 55% of the data, so a missing index can’t hide. The two charts are separate runs, so compare numbers within a chart rather than across them.
Every response was still a 200, yet at 192 callers the server did a third of the work it did at 4. Admission control now derives the concurrency limit from a 200 ms latency target, and overflow gets a typed 503 with Retry-After.
Before in grey, after in violet. Shorter is better for latency; longer is better for throughput. Throughput and p50 are for the full load-test request mix at 16 concurrent callers.
New indexes plus 57 foreign-key indexes. The p99 row is with admission control at about twice capacity.
On labelled real conversations, a candidate model scored with 5.8% errors against 11.5%. It cost 50–70% more and was less consistent from run to run, so I kept the cheaper one and reported the sample sizes.
It helps at twice the load. At ten times it barely helps, because the process is starved before any middleware runs. I documented that and left edge shedding as the deliberate next step.
A vendor moved a model alias and tripled the price; a dead failover lost a quotation. Each has a root cause, a fix and a guard. Every model ID is now pinned.
Everything you’d screen for on one card. Or paste your job description to see where I match, and where I don’t.
A keyword match against my CV, run in your browser. Nothing is sent anywhere, and gaps are shown too.
I take on a few freelance projects for teams that need AI or messaging systems that hold up in production. Each one starts small and fixed in scope, so you see working results before you commit to more.
A RAG assistant, an agent with tools, or document AI, with the safety net already built in.
First stepA working prototype on a sample of your own data.
Customer conversations on WhatsApp, Instagram and Messenger, wired into your product properly.
First stepOne channel, end to end, with your real templates.
For a product that wobbles under load, leaks between tenants, or costs too much to run.
First stepA written audit with a prioritised fix list.
A few lines are enough. I read every brief myself.
Yes. I work remotely from Kuala Lumpur (UTC+8).
Most likely, if it’s Python or PHP on AWS. I’ve shipped FastAPI, Django REST, Laravel, PostgreSQL, MongoDB and Redis in production.
A short brief: the problem, your stack and any deadline. A call then settles the scope before any proposal.
I’m open to Senior Backend and AI Engineer roles, remote or in Kuala Lumpur. The hiring card above has the details.
Data structures and system design taught from the first idea to expert level, and notes from running AI systems in production.
How real-time chat works: polling vs WebSockets, message ordering, receipts, presence, fan-out across servers and slow readers, with live demos and real code.
How heaps and priority queues work, from ER triage to heapq, heapify, Dijkstra, timing wheels and the asyncio scheduler, with demos and production code.
How consistent hashing works, from hash % N to rings, virtual nodes, jump hash, Maglev and Redis Cluster slots, with live demos and measured numbers.