I Decided My Portfolio Should Be the Project

Most portfolios are wrappers around the work.

You build a few projects, take some screenshots, write case studies, add an About page, and put everything inside a polished website. The portfolio points toward the interesting things, but the portfolio itself is usually not one of them.

I wanted to try something different.

Instead of building a website that says I understand AI products, I am building a website that has to prove it.

The final portfolio will have a conversational assistant that knows my work, retrieves evidence from approved content, explains why it chose an answer, and eventually speaks in something close to my own conversational style. Behind that relatively simple interface will be a complete RAG pipeline, a trained query-routing model, LangGraph orchestration, evaluation, observability, voice input and output, and a content system I can update without rebuilding prompts.

It is intentionally over-engineered. That sentence normally sounds like a confession. In this project, it is the point.

This is an update-based build series. I am not committing to a daily streak or inventing a weekly update when nothing meaningful has happened. I will write when a phase produces something worth explaining: a decision, experiment, failure, benchmark or working part of the system.

How I got here

My route into AI engineering has not been linear.

I spent nearly six years in product design and UI/UX, much of it on enterprise SaaS. I worked across discovery, user flows, information architecture, design systems, complex dashboards, implementation handoff, and the less glamorous parts that appear after a clean prototype meets a real business.

Busyfile was one of the projects that shaped how I think. I joined as its founding designer and worked on a system that evolved from a consumer business-formation product into a larger white-label platform for accounting firms. The work eventually covered more than 500 screens, multiple entity types, state-specific flows, operations tools and more than twenty services.

That kind of product teaches you that the interface is never the whole system. Every apparently simple screen connects to rules, data, permissions, failure states and operational work. I became increasingly interested in those connections. I wanted to understand not only what a product should do, but how it could actually do it.

At Techomatrix, I worked on AI automation workflows and LLM-powered features using Python, FastAPI, n8n, Groq, databases, APIs and prompt workflows. Independent projects pushed me into RAG, agents, LangGraph, vector databases, machine learning and deep learning.

CardioScan AI pulled me further into applied ML. Our team worked with paired stress and rest myocardial perfusion images, compared VGG16, ResNet50V2 and DenseNet121, and built a full-stack research prototype around the models. The results were not magically perfect, which was useful. Limited medical data makes it difficult to pretend that a larger architecture automatically creates a reliable model.

Somewhere in that transition, “product designer learning AI” stopped describing what I was trying to become. AI Product Engineering fits better: understand the user and business problem, design the interaction, build the system, measure whether it works, and deal with the operational reality after the demo.

Why a normal chatbot was not enough

I could have pasted my résumé into a system prompt, connected an LLM and called the portfolio AI-enabled. But that would demonstrate very little.

The interesting questions start after the API responds. How does the assistant know which source is trustworthy? What happens when the answer is absent? How can I update knowledge without manually rebuilding prompts? How should documents be chunked? What belongs in PostgreSQL and what belongs in a vector database? Which requests need an LLM at all? How do I evaluate retrieval, cost and latency? What happens when a free provider is sleeping or rate-limited?

Those questions changed the concept from a portfolio with an AI feature into an AI product that happens to be my portfolio.

The centerpiece is called Talk to Mahad. Visitors should eventually be able to ask what I did on Busyfile, which projects used RAG, why I moved into AI engineering, or why the portfolio architecture uses both PostgreSQL and Qdrant. The system should respond from approved sources, show citations and admit when the evidence is insufficient.

“I do not have enough evidence to answer that” is a feature, not a failure.

The target system

Sanity will manage projects, case studies, articles, experience, architecture decisions and approved style examples. Publishing something publicly will not automatically make it eligible for the assistant. Each document includes RAG, audience, sensitivity, review and publication controls.

An offline ingestion pipeline will normalize approved content, preserve headings and source paths, create deterministic hashes, divide documents using heading-aware chunking and embed only changed material. PostgreSQL will store canonical documents, chunks, versions and operational records. Qdrant will hold the derived vector index used for similarity search. A retrieved vector points back to canonical content in PostgreSQL, and the index can be rebuilt if it disappears.

Before calling an LLM, a compact query router will classify the request. The experiment starts with rules and TF-IDF before comparing a small transformer. MLflow will track datasets, runs and model releases. If the selected model earns deployment, it will be exported to ONNX and run inside FastAPI.

LangGraph will coordinate classification, retrieval, context validation, answer generation, citation checks and bounded recovery. MLflow will cover the traditional ML lifecycle; LangSmith will trace the LLM and agent workflow. Text chat remains the core interface, with voice isolated as a separate failure domain.

What exists today

The repository currently contains the foundation, not the finished AI system.

The scope is locked. Personas, success criteria and architecture decisions are documented. A pnpm monorepo separates the Next.js web app, Sanity Studio, FastAPI API, voice service, shared packages and offline pipelines. The first minimal portfolio pages exist, along with unit, Playwright, accessibility, Lighthouse, dependency and secret-scanning foundations. Sanity schema and integration work is now being completed.

The AI backend, ingestion pipeline, Qdrant retrieval, trained router, LangGraph workflow and voice service remain future milestones. They should not be described as implemented until their gates pass.

The frontend is deliberately plain: white, near-black, neutral gray, Plus Jakarta Sans and enough whitespace to breathe. I have a design background, so I could easily spend the first month polishing cards and transitions. I am refusing to do that. The first job is to make the content, navigation, citations, state and failures understandable.

What comes next

The immediate task is to finish the Sanity content layer and verify that approved content updates the public website without a code change. After that comes FastAPI and PostgreSQL, followed by deterministic ingestion, Qdrant retrieval, the custom router, LangGraph, evaluation, chat, voice and deployment.

The order matters. It is difficult to evaluate retrieval without trustworthy source documents. It is difficult to debug agents before their tools behave deterministically. It is difficult to claim MLOps without reproducible data and training runs. And it is difficult to build a reliable voice assistant before text chat works.

The portfolio is currently more blueprint than machine. That will change one verified milestone at a time.

Repository: https://github.com/mahadbaig2/mahad-ai-portfolio