Riyadh, Saudi Arabia · Web • Mobile • AI • Data Science • DevOps

I architect agent-driven enterprise systems — the kind where a non-technical employee approves a purchase order by speaking, instead of navigating a hundred ERP screens. I've led a cross-functional team of 15+ across engineering, QA, design and marketing, and owned platforms from service boundaries down to the Kubernetes underneath them.

I'm also founder of Haxon AI, where I ship production software solo: a live app on both stores, self-hosted API infrastructure serving it, and the model-routing layer that keeps it answering when a provider goes down.

What makes the combination rare is the span. I've written C++ inside whisper.cpp's encoder, Kotlin against AlarmManager's Doze internals, Laravel proxies routing across three model tiers, and Flutter across a codebase localized into 21 languages — then carried the release, the incident forensics and the on-call.

The pattern behind "approve a purchase order by speaking". The approval gate is deliberate — the system prepares the action, a human authorises it.

sequenceDiagram
 actor E as Employee
 participant A as Voice App
 participant S as Speech to Text
 participant R as Intent Router
 participant P as ERP Adapter
 participant M as Approver
 E->>A: Speaks request
 A->>S: Audio stream
 S-->>A: Transcript
 A->>R: Transcript plus role
 R->>R: Resolve action
 R->>P: Prepare purchase order
 P-->>R: Draft plus totals
 R->>M: Request approval
 M-->>R: Approved
 R->>P: Commit to ERP
 P-->>A: Confirmation
 A-->>E: Spoken confirmation

Problem: Islamic apps are either shallow utilities or ad-farms. None treat prayer, recitation and learning as one system that has to work offline, in 21 languages, and be correct about scripture.

A Flutter product on a Laravel backend, live on Google Play and the App Store. I own every layer — architecture, backend, mobile, native Android and iOS, infrastructure, and both releases.

Architecture highlights

• Multi-tier LLM routing with automatic fallback — primary model → secondary provider → local fallback for pre-generated content, so a provider outage degrades instead of failing
• On-device quantized Whisper for Quran recitation verification — audio never leaves the handset — alongside Groq Whisper STT for conversational turns
• Scale: 300k+ lines Dart · 28k lines Kotlin · 43 AI tools · 21 languages · 374 tests

Flutter Dart Laravel PHP Kotlin Swift PostgreSQL Redis Docker

Problem: every AI feature usually means another screen, another endpoint, another prompt to maintain.

~4,900 lines across a Laravel AI proxy and a Flutter frontend. Structured form input composes into a single query; the tool slug routes to a category-specific system prompt with its own token budget server-side; the streamed markdown is parsed back into typed UI sections in real time.

Architecture highlights

• One SSE endpoint serves all 43 tools across 6 categories — adding a tool adds no screens
• Category-specific prompts and token budgets tuned per tool class
• Streaming section parser with partial-message and reconnect handling, re-parsing idempotently on every chunk

flowchart TB
 C[Client request] --> G[Routing gateway]
 G --> H{Provider healthy}
 H -->|yes| P[Primary model]
 H -->|no| S[Secondary provider]
 P -.->|rate limit or timeout| S
 S -.->|unavailable| L[Local fallback]
 P --> R[Streamed response]
 S --> R
 L --> R
 R --> C

Adding a tool adds a config entry, not a screen.

Laravel Flutter SSE Prompt Engineering

Problem: public Quran and prayer-time APIs are rate-limited, inconsistent, and go down.

A containerised service-per-domain estate behind Nginx, built and operated end to end — content API, media delivery, application backend and a public data API, each independently deployable.

Architecture highlights

• Containerised service-per-domain behind Nginx, independently deployable
• Audio CDN serving multiple reciters at production traffic across 21 languages
• Operated, not just deployed — monitoring, alerting and the on-call are mine

flowchart LR
 F[Client form] --> Q[Composed query]
 Q --> S[Tool slug]
 S --> G[API gateway]
 G --> C[Category prompt]
 C --> B[Token budget]
 B --> M[Model]
 M --> E[Streamed chunks]
 E --> P[Section parser]
 P --> U[Typed UI sections]

Docker Nginx Linux VPS CI/CD

Problem: off-the-shelf models are wrong about scripture, expensive at scale, and useless offline.

• Fine-tuning — Qwen-family experiments on Islamic QA datasets
• RAG stack — Qdrant + BGE-M3 embeddings over Quran and tafseer corpora
• On-device inference — a quantized sub-billion-parameter model running inside Flutter
• Vendor benchmarking — STT/TTS evaluated across 21 languages at production scale

Qdrant BGE-M3 Whisper Quantization

Problem: an ANR cluster is invisible in development and lethal in the Play Console.

Diagnosed and fixed crash and ANR clusters affecting real users: exception-handler delegation · Firebase initialization deadlocks · exact-alarm scheduling on modern Android. The kind of work that only shows up when you own the release and the incident.

Android Kotlin Firebase Play Console

Not shipped — in progress. Twenty projects queued, most extracted from systems already carrying production traffic. A repository appears only when it has real code and a real README.

→ See all 20, tiered NOW / NEXT / LATER →

_{🟢 building · 🟡 designed · ⚪ planned — nothing on that page is presented as finished.}

Forty-three tools, one streaming endpoint, three model tiers — and a request that degrades instead of failing.

The tiering is the point. A single provider is a single point of failure. The day our primary provider went down the app kept answering — quietly, on the fallback tier — because the routing layer treats provider health as an expected condition, not an exception.

The system that keeps it up when I'm asleep. Every arrow here is automated; a human appears only at the kill switch.

No app update required. Remote Config lets me roll the entire AI backend from v2 to v1, rotate the app secret, or disable a paid feature — live, on devices already in users' hands.

Real-time speech recognition on a phone, with nothing leaving the handset.

1,500 encoder frames to ~250. Upstream whisper.cpp always encodes a fixed 30-second mel context regardless of input length. Sizing it from the actual sample count is what makes live transcription possible on a phone at all.

How a single user request survives a provider outage:

flowchart LR
 Q[User question] --> E[Embed query]
 E --> V[(Vector store)]
 V --> K[Top candidates]
 K --> RR[Reranker]
 RR --> G[Generator]
 G --> CV{Citation valid}
 CV -->|yes| A[Grounded answer]
 CV -->|no| D[Drop citation]
 D --> A

AI & ML — production

AI & ML — working knowledge

Production — shipped it, operate it, carry the pager

SSE streaming · LLM evaluation — Promptfoo · DeepEval · Ragas · Langfuse

Working knowledge — real, but I won't oversell it LangChain LlamaIndex LangGraph CrewAI PyTorch TensorFlow Hugging Face LoRA/QLoRA/PEFT Azure OpenAI AWS Azure Terraform React Native Swift

The split is deliberate. If it's in the first list I've run it in production and debugged it at 3am. If it's in the second, I've built with it but wouldn't claim depth in an interview.

Hafiz of the Quran. Five languages — English, Arabic, Bengali, Hindi, Urdu. Most of my engineering goes toward AI for languages and communities that the major labs deprioritize: 21 locales shipped, and a speech stack tuned for Quranic Arabic because no off-the-shelf model handles it correctly.

Open to senior and staff engineering roles, architecture ownership, and AI product collaborations.

📬 engr.hamedhasan@gmail.com · 💼 linkedin.com/in/hamed-hasan

📍 Riyadh, Saudi Arabia — transferable Iqama, no sponsorship required, immediate joiner.