This portfolio is being built as direct evidence of AI Product Engineering. Behind its simple public experience is a production-oriented architecture for governed content, RAG, ML routing, agent orchestration, evaluation and voice under strict cost limits. Development follows ordered milestones, with planned capabilities clearly separated from features already implemented and verified.
The Engineering Challenge
Mahad's career combines nearly six years of product design and UI/UX experience with more recent hands-on AI engineering. A conventional portfolio could show screenshots and list tools, but it would not prove the ability to connect product thinking, data, models, software architecture, evaluation and operations.
Adding a generic chatbot would not solve that problem. A résumé pasted into a system prompt would be difficult to maintain, easy to hallucinate from and nearly impossible for visitors to inspect. The real challenge was to design a portfolio that remained useful as a normal website while also serving as a credible technical system.
The product therefore needs to answer four questions: Can visitors understand Mahad's work quickly? Can deeper visitors inspect how the system works? Can the assistant ground claims in approved sources? Can the application remain safe and usable without uncapped infrastructure spending?
System Architecture & Topology
Target architecture for an inspectable, cost-bounded portfolio assistant. Sanity owns authored content, PostgreSQL owns canonical operational data, Qdrant acts as a rebuildable vector index, and LangGraph coordinates the assistant workflow.
The architecture separates content, operational truth and retrieval. Sanity owns authored portfolio content. An offline ingestion pipeline will normalize approved documents, preserve structure, generate deterministic hashes, create heading-aware chunks and embed only changed content. Neon PostgreSQL will store canonical documents, chunks, versions and operational records. Qdrant will store the rebuildable vector index, with point IDs mapped back to PostgreSQL chunks.
FastAPI will expose the AI service. An in-process query router will classify requests before expensive generation. The plan begins with deterministic rules and TF-IDF, then compares a compact transformer and ONNX deployment only if evaluation justifies it. LangGraph will coordinate classification, retrieval, context checks, answer generation, citation validation and bounded recovery using typed state.
MLflow will track classifier datasets, experiments, metrics and model releases. LangSmith will trace prompts, retrieval, tools, latency and LLM evaluation. The web client will receive streamed events through SSE. Voice uses the same text assistant path, with transcription and synthesis isolated so voice failures do not affect chat.
Trade-offs, Failures & Mitigations
The project deliberately accepts additional architecture because demonstrating the lifecycle is part of the product goal. However, complexity must earn its place. PostgreSQL and Qdrant are both included because they have different responsibilities, not because two databases look impressive. A transformer router will not replace TF-IDF unless it materially improves the chosen evaluation metrics. Voice is delayed until text chat is reliable.
The first frontend implementation also exposed the value of milestone gates. Missing data connections, premature links, placeholder facts and incomplete validation meant the Phase 1 gate could not honestly be approved even though much of the interface existed. Those findings are treated as remediation work, not hidden as polish.
Engineering Lessons Learned
A portfolio can demonstrate engineering only when claims are connected to inspectable evidence.
Content governance must exist before RAG ingestion.
Agentic workflows should combine deterministic and model-driven steps instead of making everything autonomous.
A passed checklist is not a substitute for a passing build and manual review.
Cost limits, service sleep and fallbacks are architecture requirements, not deployment footnotes.
Strategic Architectural Decisions
Decision 1: Key Trade-off↓
Separate authored content, canonical operational records and vector search instead of treating the vector database as the source of truth.
Decision 2: Key Trade-off↓
Use offline, deterministic and idempotent ingestion rather than embedding content during visitor requests.
Decision 3: Key Trade-off↓
Benchmark rules and TF-IDF before training a transformer router; export the selected model to ONNX only if it earns the added complexity.
Decision 4: Key Trade-off↓
Use LangGraph for explicit typed state and bounded recovery, not open-ended agent conversations.
Decision 5: Key Trade-off↓
Use MLflow for the ML classifier lifecycle and LangSmith for LLM and agent observability.
Decision 6: Key Trade-off↓
Keep voice in a separate failure domain and preserve text chat as the core interface.
Decision 7: Key Trade-off↓
Design around hard free-tier limits and graceful degradation so the portfolio remains usable when AI services are unavailable.
