What I Bring

Working directly with the people who own the problem — operations staff, founders, a client’s own engineers — to turn an incomplete brief into a defined scope with a costed estimate and an agreed definition of done. I have run this from both sides: as an internal business process specialist mapping undocumented finance and logistics workflows, and as an outside engineer scoping AI projects for SMEs who had never bought one before.

Supporting

requirements discovery · As-Is / To-Be process mapping · costed build estimates · written sign-off before build · stakeholder workshops

Proven in Case 02 · Case 04

AI systems that have to run inside a real operation: document extraction with a human review step before anything is committed, customer-support assistants with knowledge structure, tool integration, session handling and escalation to a person, and RPA workflows across finance and logistics tasks that used to be typed by hand.

Supporting

OpenAI / Claude APIs · RAG · retrieval tuning · prompt versioning · tool calling · OCR (PyTesseract) · Power Automate · Datagrand RPA · Selenium · LangChain / LangGraph (evaluated) · Ragas (proof of concept) · n8n · Dify

Proven in Case 02 · Case 03

Connecting systems that were never designed to be connected — a client’s legacy ERP, source systems with no API at all, third-party commerce and payment platforms, message queues, and the manual steps in between. The recurring decision is build versus buy, and I have been on both sides of it enough to know that the interesting question is which constraint makes the bought component fail.

Supporting

REST API design · OpenAPI / Swagger · webhooks · OAuth 2.0 / JWT · RabbitMQ · Redis · PostgreSQL / MySQL · Shopify API · Stripe · PayPal · non-invasive integration patterns

Proven in Case 01 · Case 02

Owning a system past its release. Long-running jobs that resume from where they stopped rather than starting over. Failures that surface at a time of day when a human can still fall back to the manual process. Queue-based handling so one slow request cannot block the next customer. Submissions that cannot be double-fired by a page refresh. Idle capacity that gets released instead of held.

Supporting

queue workers · async processing · checkpointed runs · idempotent submission · caching strategy · Docker · NGINX · CI/CD · AWS / GCP / Azure · monitoring and alerting

Proven in Case 02 · Case 05

I have led delivery and technical decisions rather than headcount: the final architecture and technology-selection calls after taking the team’s input, the code-review practice a team works to, and mentoring developers through the thing actually blocking them — which, in my experience, is almost always the API contract rather than the code.

Supporting

technical leadership · code review practice · mentoring · sprint planning and work breakdown · trilingual delivery (English · Mandarin · Bahasa Malaysia)

Proven in Case 01 · Case 05