MY logo
Solution Architect

Mohamed Yasser

I design systems that hold under pressure, scale with intent, and respect constraints.

Two decades across domains: enterprise platforms, government infrastructure, AI-driven operations. The measure is whether it keeps running.

Clarity in thinking Depth in building Scale with purpose

Mohamed Yasser
MY | Solution Architect logo
Systems Solution Architect building AI, edge, and public-sector platforms.

Identity

Systems thinker. Builder. Operator.

I design systems end to end, from constraint analysis to operational handoff. My focus is not technology selection. It is whether the system behaves correctly when the conditions are not ideal.

  • Design systems under real-world constraints
  • Build AI pipelines that integrate into operations
  • Architect control planes and data planes
  • Translate business problems into working systems

Execution

Building under constraints is the work.

  • 20+ years building production systems, enterprise and government
  • Designing architectures and making deliberate trade-offs
  • Integrating AI into operational workflows, not prototypes
  • Debugging real production failures
  • Optimizing for latency, reliability, and maintainability

Systems > components  ·  Constraints > assumptions  ·  Production > prototype

Core Philosophy

Failure first.
Scale second.
Features last.

Mohamed

See Architecture
01

Failure Handling

A system is only as good as its failure handling. I design the failure path first. The happy path is easy. Failures are where the real architecture lives.

02

Scale Exposes Flaws

Scale exposes every design decision made under assumptions. What works for ten requests breaks at ten thousand. I design for scale before it is required.

03

AI Needs Integration

AI without integration into operations is a demo. Value comes from where the AI connects to the rest of the system, not from the model accuracy on a benchmark.

04

Reliability Is Designed

Reliability cannot be added after the fact. It is a design decision made before the first line of code. Systems that were not designed to be reliable are not reliable.

What I Build

SYSTEMS
THAT POWER
THE REAL
WORLD.

Discuss a Project

AI Systems

  • Vision-based detection systems
  • Vision-Language Model integrations
  • Automated classification and decision pipelines
  • Real-time inference workflows

Edge / Local-First

  • On-device inference pipelines
  • Offline-first processing systems
  • Low-latency architectures
  • Edge + central validation models

RAG Architectures

  • Knowledge retrieval systems
  • Semantic search pipelines
  • Vector database integration
  • Context-aware AI assistants

Government & Public Sector

  • Municipality AI systems
  • Automated complaint generation from images
  • GIS-integrated monitoring systems
  • Smart city infrastructure solutions

Featured Work

Systems built for the real world.

Three representative builds spanning AI detection, edge document processing, and enterprise knowledge retrieval.

Discuss Work
DETECT ● REC LIVE MUN-AI v2.4 · DETECTION ON

Municipality AI System

AI-enabled system for detecting city infrastructure issues using vehicle-mounted cameras. Includes edge detection, central validation, and automated complaint generation.

AIVisionEdgeGIS
EDGE PROCESSOR DOC_1.pdf EXTRACTED Fields: 24 / Match: 98% VALIDATED Confidence: HIGH STORED db.local → queue OFFLINE

Edge Document Intelligence

Offline-first document processing system designed for environments with limited connectivity. Focus on accuracy, performance, and reliability at the edge.

Edge AIOCROffline-first
EMBED INDEX RANK QUERY CTXT RESP VEC RAG KNOWLEDGE RAG KNOWLEDGE GRAPH

RAG Knowledge Assistant

Enterprise-grade retrieval system for structured knowledge access. Combines vector search, context retrieval, and LLM-based responses.

RAGVector DBLLM

Architecture Thinking

I don't build features. I design systems that survive scale.

Systems are not defined by their components, but by how those components behave under load, failure, and change.

My approach:

  • Understand the full flow from input to outcome
  • Design for constraints, not assumptions
  • Ensure observability and control
  • Build for long-term maintainability
Mohamed Yasser

System Flow

Every system I design follows a structured path from captured input to validated action under real operating conditions.

Input Processing Validation Action

Inputs

  • Image / Text
  • Signal / Data
  • Devices
  • Services

Outcomes

  • Automation
  • Accuracy
  • Efficiency
  • Action

Architecture Patterns

Patterns used.
Not frameworks followed.

Each pattern comes from a problem that could not be solved another way.

Tested.

01

Control / Data Plane Split

Separate what makes decisions from what moves data. Use when a system needs to scale operations without coupling control logic to data throughput.

02

Event-Driven Architecture

Kafka and queue-based pipelines for systems where components must evolve independently. Use when coupling would kill maintainability at scale.

03

Edge + Cloud Hybrid Inference

First-pass inference at the edge, central validation in cloud. Use when latency matters at capture but accuracy requires central verification.

04

Observability-First Design

Instrument before optimizing. Tracing, metrics, and alerting are architecture decisions. Use when operating a system you cannot afford to debug blindly.

AI System Thinking

AI IS A
COMPONENT.
NOT THE SYSTEM.

Models Are Replaceable

  • Pipelines are not
  • Design the interface, not the model
  • Build so any model can be swapped in
  • The system outlives the model version

Data Quality Over Model Size

  • Better data beats bigger models
  • Garbage in, garbage out. Always.
  • Clean pipelines over clever models
  • Validate inputs before trusting outputs

Latency Over Benchmarks

  • A 99% accurate model that times out is useless
  • Production SLAs define acceptable accuracy
  • Optimize for real conditions, not test sets
  • Measure what the user experiences

Human-in-the-Loop

  • Not a fallback: it is architecture
  • Design validation checkpoints intentionally
  • Escalation paths are part of the system
  • Confidence thresholds route, not decide

Open Source & Engineering

Code that ships problems others keep building around.

Published on GitHub and Hugging Face. Focus on small models, edge inference, and practical AI systems.

barq-web-rag

Browser-Native RAG

Runs retrieval-augmented generation entirely in the browser. No server. No API calls. Embeddings and inference run locally using ONNX and Web Workers.

Why it matters: RAG without infrastructure dependency. Works offline. Keeps data local.

SEMBRA Pipeline

Embedding Streaming System

Streaming-first embedding pipeline for large document corpora. Handles chunking, embedding, and indexing without loading full datasets into memory.

Why it matters: Makes vector search viable on constrained hardware. Edge-deployable.

Model Distillation Work

Small Models. Real Performance.

Domain-specific distillation and quantization. Reducing model footprint without losing accuracy on targeted tasks: Text2SQL, medical AI, safety classification.

Constraint is the design brief, not the obstacle.

Published Models

Deployable. Documented. Used.

  • Text-to-SQL generation models
  • Medical triage and symptom classification
  • Arabic language safety classifiers
  • Quantized models for edge deployment

Engineering Focus

Efficiency Over Scale

The assumption that more compute solves every problem is wrong. I work on the opposite: doing more with less. Quantization, distillation, streaming inference on constrained hardware.

Recognition

Some work is visible through code. Some through systems that continue to operate. Some through people who start building after a conversation.

Professional Experience

0 Years in Production Systems
  • Enterprise and government environments
  • Cross-domain architecture work
  • Systems still running years after design

Government & Innovation

  • Municipality AI detection: deployed
  • WhatsApp complaint automation: operational
  • Smart parking advisory: in production
  • Innovation showcase participation
  • Public sector AI architecture work

Open Source & Community

  • Multiple AI models on Hugging Face
  • AI community leadership, UAE
  • CodersHQ AI/ML involvement
  • Mentor in national AI challenges
  • Certificate: Decoding Data Science

How I Approach Problems

Constraints first.
Solutions second.

Most systems fail because they were designed for the happy path. I design for the edges first, the center second.

01

Understand Constraints

Latency, budget, data availability, team capability, compliance. Constraints define the solution space before any design begins.

02

Identify Failure Points

Where will this break? What happens when the model is wrong? What happens when the network drops? Map failures before mapping features.

03

Design Minimal System

Smallest system that handles the constraints and survives the failures. No premature optimization. No hypothetical scale. Correctness first.

04

Scale, Observe, Optimize

Add scale mechanisms and instrumentation deliberately. Optimize what the production data shows, not what the assumptions suggested before it was built.

What Makes My Approach Different

I start with what breaks.
Not with what works.

Most engineers design for success. I design for failure. That difference changes every decision in the architecture.

  • I start with constraints, not tools
  • I design for failure, not the happy path
  • I build integrated systems, not isolated AI
  • I stabilize before optimizing
  • I build for operators, not just architects
Mohamed Yasser

Technical Stack

  • Rust  ·  .NET  ·  Python
  • Kafka  ·  Redis  ·  ClickHouse
  • vLLM  ·  ONNX  ·  Transformers
  • Edge + cloud hybrid deployments
  • Streaming-first pipelines

What I Don't Build

  • Demo-only systems
  • AI without a real use case
  • Over-engineered architectures
  • Systems that cannot be operated
  • Stacks chosen before problems are understood

Constraints → Tools

Most engineers select tools first. I select constraints first. The tool follows the problem definition, not the trend cycle. This is the reason my systems behave differently under pressure.

Integration Mindset

AI that does not integrate into operations is a prototype. Systems that cannot be operated by someone other than the builder are not finished. Integration is part of the architecture.

Mentorship & Community

I work with engineers who want to shift thinking from tools to systems.

Mohamed Yasser

Not about stacks. Not about frameworks. About how you think about a problem, structure a solution, and build something that holds under real conditions.

0 Years in Production Systems

Enterprise and government environments. Systems still running years after the initial design.

  • System design thinking
  • Real-world architecture decisions
  • AI integration into operations

Community Involvement

  • CodersHQ AI/ML community, UAE
  • ACE AI Club, member & contributor
  • UAE | MENA Software Engineers & QA Professionals
  • Nirant Gen AI community
  • Mentor in national AI challenges
  • AI community leadership in the region
  • Speaker and judge in tech events

Who I Work With

Engineers and teams ready to think beyond the tool and build something that behaves correctly when conditions are not ideal.

  • Builders moving from prototype to production
  • Teams adopting AI in real systems
  • Architects questioning their own assumptions

Let's Build

If it needs
to hold.

If you are building something real: something that needs to scale, something that must work under constraints, or something that cannot afford to fail. We should talk.

Not interested in demos. Interested in systems.

Sharjah, UAE