AI Systems & Automation Engineer · Malaysia (GMT+8)

Zi Ling Teoh

Build. Deploy. Operate. Improve.

Systems Engineering (Harvard E-178) · Engineering Economics (Harvard E-188) · MIT OCW Systems Thinking

Engineering Framework

Each case study below contains Decision Points (DP) — documented moments where analysis shaped the system direction. Methodology tags (E-178, E-188, SSM, VSM) trace each decision to its engineering framework.

V-Model Lifecycle (E-178)

Requirements Analysis
Architecture Design
Build & Deploy
Verification (metrics)
Validation (outcomes)

Case Studies

CS1

Luxury French Retail Brand (NDA) — AI Content Pipeline

n8n self-hosted · Claude API · Custom NestJS backend · Supabase

Architecture

7 Data Sources (API, RSS, scraping)
n8n Orchestration (15-min batch sync)
Claude API (structured extraction)
NestJS API + Supabase
React Dashboard
7
Automated data streams
15min
Batch sync interval
99%+
Autonomous uptime
1
Operator (me)
DP-1 Cost: Build custom vs. buy SaaS E-188

Context: Client needed automated content aggregation from 7 sources. Off-the-shelf SaaS tools (Feedly, Zapier) priced per-seat, per-connection.

Analysis (E-188): Projected 12-month total cost of ownership. SaaS stack: ~USD 800/mo at required volume. Self-hosted n8n + Claude API: ~USD 150/mo. Break-even at month 2.

Decision: Self-hosted. Accepted higher initial build effort for lower marginal cost and full architectural control.

DP-2 Requirements: Structured extraction vs. summarization E-178

Context: Client's content team needed actionable intelligence, not summaries. Original requirement was "summarize articles."

Analysis (E-178): Requirements elicitation revealed the actual need: structured data fields (brand mentioned, sentiment, product category, competitive signal) for filtering and decision-making.

Decision: Designed Claude API prompts for structured JSON extraction with defined schema, not freeform summaries. This enabled dashboard filtering and trend analysis that summaries couldn't support.

DP-3 Architecture: 15-min batch sync vs. real-time webhooks E-178

Context: Content monitoring doesn't require sub-minute latency. Most sources update hourly at most.

Analysis (E-178): Real-time webhooks add complexity (webhook management, retry logic, connection state) for no user-perceptible benefit. 15-minute polling matches source update frequency.

Decision: Batch polling on 15-min cron. Simpler failure modes, predictable resource usage, easier debugging. Added dead-letter queue for failed extractions.

CS2

Agreement Ledger — Append-Only Contract System

Next.js · Supabase · SHA-256 hash chain · Stripe billing

Architecture

Next.js Frontend
Supabase (RLS + append-only policies)
SHA-256 Hash Chain (each entry links to previous)
Stripe Billing (subscription gate)
SHA-256
Hash chain integrity
RLS
Row-level security
JWT
Auth + RBAC
Append
Only (no edits/deletes)
DP-4 Security: Hash chain vs. simple audit log E-178

Context: Contract agreements need tamper evidence. Simple audit logs (timestamp + user) can be modified without detection.

Analysis (E-178): SHA-256 hash chain where each entry's hash includes the previous entry's hash. Any modification to historical records breaks the chain. Verification is O(n) scan — acceptable for contract volumes.

Decision: Implemented hash chain with Supabase RLS enforcing append-only at the database level. No application code can UPDATE or DELETE agreement records.

DP-5 Risk: Read-only mode after subscription cancellation E-188

Context: When users cancel their Stripe subscription, their existing agreements still have legal value. Deleting data or blocking access entirely creates liability.

Analysis (E-188): Risk assessment of three options: (1) full lockout — legal risk, (2) continued full access — no revenue incentive, (3) read-only mode — preserves data access, incentivizes resubscription.

Decision: Implemented tiered access: active subscription = full read/write, cancelled = read-only with export capability. Stripe webhook handles state transitions.

CS3

rd03-au — Systems Design for AU Market Entry

SSM (Checkland) · VSM (Beer) · Nudge Architecture (Thaler/Sunstein) · Python + FastAPI

Methodology Stack

SSM — Problem structuring, rich pictures, root definitions
VSM — Viable system diagnosis, regulatory mapping
Nudge Architecture — Choice architecture, default optimization
Python + FastAPI implementation
3
Methodology layers
AU
Target market
<3mo
Design to deployment
DP-6 Systems Thinking: SSM → VSM → Nudge layering SSM VSM

Context: AU market entry required understanding regulatory environment, competitive landscape, and user behavior patterns simultaneously.

Analysis: SSM (Checkland) for problem structuring — rich pictures and root definitions to map stakeholder perspectives. VSM (Beer) for viability diagnosis — identifying regulatory constraints and required variety. Nudge (Thaler/Sunstein) for choice architecture — designing defaults and decision flows.

Decision: Three-layer methodology stack: SSM defines the problem space, VSM validates system viability, Nudge shapes the user-facing implementation. Each layer's output feeds the next.

DP-7 Economics: Build-measure-learn vs. full spec upfront E-188

Context: New market, uncertain demand. Full specification upfront risks building the wrong thing.

Analysis (E-188): Engineering economics: cost of change increases exponentially with project phase (E-178 principle). But cost of building the wrong product is total loss. In high-uncertainty environments, information has option value — each iteration buys knowledge.

Decision: Phased delivery: SSM-validated MVP first, then VSM-guided scaling. Each phase gated by measurable criteria, not timeline. Delivered within 3 months from design to deployment.

Stack & Traceability

AI / LLM
Claude API · n8n · MCP Protocol
Backend
Python · TypeScript · Go · NestJS · FastAPI
Frontend
Next.js 14–16 · React · Tailwind
Data
Supabase · Prisma · tRPC
Infra
Docker · GCP Cloud Run
Orchestration
Temporal · Airbyte · dbt
Security
SHA-256 · JWT/RBAC · RLS
Dev Tools
Claude Code CLI · GitHub Actions

Traceability Matrix

Claim Method Evidence
Full lifecycle delivery V-Model (E-178) CS1: requirements → build → 99%+ uptime operation
Cost-conscious architecture Eng. Economics (E-188) CS1 DP-1: TCO analysis, break-even month 2
Requirements analysis SE Process (E-178) CS1 DP-2: elicitation changed output from summaries to structured extraction
Security-first design SE Process (E-178) CS2 DP-4: SHA-256 hash chain + RLS append-only
Risk quantification Decision Quality (E-188) CS2 DP-5: three-option risk assessment for subscription cancellation
Systems thinking methodology SSM + VSM CS3 DP-6: three-layer methodology (SSM → VSM → Nudge)
Engineering economics Eng. Economics (E-188) CS3 DP-7: option value analysis for phased delivery
Autonomous operation V-Model (E-178) CS1: 99%+ uptime, single operator, 15-min batch cycle

Engagement Specification

Model
Monthly retainer (contractor)
Timezone
GMT+8 (Malaysia) — 4-hour overlap with AEST
Scope
Full lifecycle: build, deploy, operate, improve
Availability
Immediate
Communication
Async-first (Slack/email), weekly sync optional
Contact
zilingteoh97@gmail.com