Faris
Khaleel

The Problem

Shory needed to bring Motor, Health, and Travel insurance online across two markets fast — but each insurer used a completely different API structure: different authentication (API keys, OAuth, mutual TLS), inconsistent field naming, and error codes with no standard. Government integrations in UAE and KSA added regulatory schema requirements on top. Manual onboarding took weeks per partner, was error-prone, and had no repeatable validation process to catch failures before they reached production users.

Integration Architecture

Built a structured integration pipeline: translated raw partner specs (REST, SOAP, PDF) into normalised internal schemas, then ran every integration through a validation suite covering auth, payload structure, edge cases, and error handling before any partner went live. No integration reached production without passing the full validation suite.

Sample Integration Payload (sanitized)

{
  "request_id": "req_xK9mP2qL7nR",
  "insurer_code": "INS_[REDACTED]",
  "product": "MOTOR_COMPREHENSIVE",
  "applicant": {
    "id_type": "EMIRATES_ID",
    "dob": "1990-01-01",
    "nationality": "AE"
  },
  "vehicle": {
    "make": "Toyota",
    "model": "Camry",
    "year": 2021,
    "chassis_no": "[REDACTED]"
  }
}

// Validated: auth header, required fields, date format, enum values
// Expected: 200 OK with premium breakdown + quote_id

Business Impact

• 160+ API integrations across Motor, Health, and Travel — every one validated before production deployment
• 17 insurers onboarded end-to-end across UAE & KSA, and 7 government entities
• Reusable validation suites meant each new insurer onboarding re-used existing test coverage rather than starting from scratch
• Partner-facing integration guides allowed insurers to self-serve through the integration process with minimal back-and-forth

The Problem

Every insurance application required verified identity and residency documents — Emirates IDs, labour contracts, visas, and residence permits. Reading these manually to extract fields like name, ID number, expiry date, and employer was a slow, error-prone process that created a bottleneck at every customer onboarding step. A misread field meant application delays or rejected submissions. I built a two-stage automated pipeline to eliminate this: first, an OCR layer to extract raw text from document scans regardless of layout; then a locally-hosted LLM (Ollama) to semantically understand the extracted text and return only the specific structured fields the backend needed — no hallucinations, no ambiguity, deterministic JSON output.

Pipeline Architecture

Built a two-stage pipeline in Python. Stage 1 used OCR to extract raw text from scanned documents regardless of layout — handling a variety of document formats, orientations, and print qualities across Emirates IDs, labour contracts, visas, and residence permits. Stage 2 passed that raw text to a locally-hosted LLM running via Ollama, prompted to identify and extract only the specific fields required by the backend (name, ID number, expiry, nationality, employer, etc.) and return them as a deterministic structured JSON object. No external API calls — the LLM ran locally, keeping all document data on-premise.

Sample Structured Output

{
  "document_type": "emirates_id",
  "full_name": "[REDACTED]",
  "id_number": "784-[REDACTED]",
  "nationality": "[REDACTED]",
  "date_of_birth": "[REDACTED]",
  "expiry_date": "[REDACTED]",
  "confidence": "high"
}

// LLM prompted with field schema — returns only required fields
// Ollama running locally — zero external data exposure

Business Impact

• 4 document types fully automated — Emirates IDs, labour contracts, visas, and residence permits
• Eliminated manual document reading from the onboarding workflow — zero human transcription needed for standard documents
• Two-stage design (OCR → LLM) handled layout variation and print quality issues that single-step extraction could not
• Local Ollama inference kept all customer document data on-premise — no third-party API exposure for sensitive PII

The Problem

Skyloov was shipping high-risk releases with no test coverage and no performance data, across a platform handling 120K+ property listings. Bugs were reaching production users regularly. There was no definition of what "good performance" looked like, and no way to catch regressions between releases. I was hired as the only QA engineer in a ~12-person engineering team to change this — from day one.

Testing Pipeline Architecture

Built two parallel testing tracks that ran every release cycle. Functional track: Postman collections covering 500+ backend endpoints, executed automatically via Newman in Jenkins CI. Performance track: Gatling simulating 1,000 concurrent users across 200+ APIs with p95 latency, TPS, and error rate metrics exported to Grafana dashboards. For the first time, the team had a performance baseline they could compare against after every deployment.

Business Impact

• 500+ endpoint regression suite running on every deployment — regressions caught before reaching 120K+ property listings users
• Platform launched successfully across 3 apps (web, iOS, Android) with established pass/fail gates at every release
• First-ever performance baselines defined: p95 latency, max throughput, error rate thresholds enforced per release
• AI-powered property search chatbot fully validated across search, support, and lead generation flows before launch
• ElasticSearch relevance and Kafka async event processing validated under real workload conditions

The Problem

The team anticipated high-traffic periods, but lacked confidence in how the system would perform under load. Existing performance testing was limited, with no clear targets or sufficient observability into system behavior under stress. Microservices were tightly coupled, increasing the risk of cascading failures. I was brought in to evolve and scale the performance testing program, strengthening coverage, defining benchmarks, and improving visibility ahead of peak periods.

Performance Testing Architecture

Wrote Gatling scripts in Scala covering hundreds of endpoints across all microservices. Designed three scenario types: ramp-up (gradual user growth), sustained load (steady-state at target TPS), and spike (sudden 3,000 VU burst). Monitored CPU, memory, p95 latency, throughput, and error rates simultaneously using Grafana dashboards and New Relic APM traces. Automated test report generation and publishing to GitHub Pages — so the team had full results immediately after every run without any manual steps.

Business Impact

• 3,000 concurrent virtual users generating millions of API requests per hour — revealing real bottlenecks before any traffic event hit production
• Multiple microservice-level bottlenecks identified and fixed before peak periods — preventing cascading failures in production
• System performance baselines established for the first time: latency targets, max throughput, memory ceilings per service
• Automated report pipeline meant the entire team had access to test results instantly — no manual reporting overhead

The Problem

WeightWatchers ran analytics and reporting across a multi-cloud data stack — Snowflake, BigQuery, and Oracle — feeding business dashboards and user-facing reporting features. ETL pipelines moved data between these environments, but there were no automated checks to verify correctness after each run. Schema drift, duplicate records, and reconciliation mismatches were only discovered reactively — often after bad data had already surfaced in reports. The team was also mid-migration from DSS Reporting to Looker Studio, with no validation framework to confirm the migrated dashboards matched source truth. I was brought in to build the validation infrastructure from scratch.

Data Validation Pipeline Architecture

Wrote Python-based ETL validation scripts that ran automated checks across Snowflake, BigQuery, and Oracle after every pipeline execution: schema drift detection, row count reconciliation between source and destination, duplicate record identification, and field-level data type checks. For the BI migration from DSS Reporting to Looker Studio, validated that every dashboard metric matched its source dataset — ensuring the migration produced no regressions in reported figures.

Business Impact

• 3 database environments covered — Snowflake, BigQuery, and Oracle — under a single automated validation framework
• Shifted ETL quality assurance from reactive (catch issues in reports) to proactive (catch failures at the pipeline boundary)
• Schema drift, duplicate records, and reconciliation mismatches caught before reaching analytics dashboards or end-user reports
• DSS → Looker Studio BI migration validated end-to-end — confirmed dashboard metrics matched source data after full migration