I built an embedded AI assistant from scratch—no libraries, no frameworks, no AI-powered app-generation vibe coding tools—that lets users explore case studies in a conversational, on-demand way. It's currently available for the Pulse Energy Engagement Dashboard, with plans to expand to others soon.

Try it now

The system handles everything end-to-end—from chunking and embedding with OpenAI to a Flask backend and static-site integration—revealing design decisions that screenshots can't capture.

System architecture

Snapshot of how it's all stitched together

All product names, logos, and brands are property of their respective owners. All company, product, and service names used in this diagram are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.

1. Rough project notes and reflections are captured in freeform documents in ChatGPT and Google Drive.
2. Notes are converted to .txt files—one per case study—which serve as the input for downstream processing.
3. A Python script breaks the content into structured JSON chunks and generate vector embeddings via FAISS indexing.
4. The JSON chunk files and FAISS index are committed to GitHub, keeping the embedded data version-controlled and co-located with the frontend.
5. Using Cursor as a development environment and OpenAI for inline code assistance, the static site is built using:
   • → Pug as the HTML templating engine
   • → SASS for modular styles
   • → vanilla JavaScript for client-side functionality
6. All front-end assets are compiled and bundled via Prepros, producing clean, deployable static files.
7. The site is hosted on Netlify, which serves both the case studies and the embedded assistant UI.
8. The backend logic runs on a Flask app written in Python, hosted on Render, which exposes an API for handling user queries.
9. The assistant backend references the JSON and FAISS files directly from the GitHub repo, keeping content and logic decoupled but tightly aligned.
10. Queries are routed from the static site to the Flask API, which fetches relevant chunks and sends them—along with the user's question—to OpenAI's LLM API.
11. The LLM's response is returned to the static UI, completing the query cycle and surfacing context-aware answers drawn from your original project thinking.
12. Submitted queries are logged to Airtable, allowing me to track usage and gather feedback. The assistant is then trained on the logged queries and feedback, allowing it to improve over time.

• →Traditional case studies are not great at showing a designer's real impact, especially in systems thinking and cross-functional alignment
• →Building something from scratch provides valuable product context you can't get from just laying it out in Figma or Sketch.
• →I wanted hands-on experience with custom-trained LLMs, and I learn best by applying knowledge in practice

This is a living project, still evolving as I refine the UI, strengthen the system, and expand functionality across case studies.

• →AI-driven tools can add immense value, but need to be applied thoughtfully and deliberately
• →Prompt engineering is product design: framing directly impacts outcomes
• →Even small tools benefit from clear architecture and modular design
• →Building for yourself speeds clarity: you can skip discovery, not design thinking

• →Cleaner UI and interaction flow including dismissable disclaimers and surfaced example questions
• →Spam prevention and reliability improvements with basic abuse protection, improved error handling, and fallback states for failed queries
• →Richer user experience with question history, feedback, and context-specific assistant views based on the case study
• →Expanded functionality for multi-case study queries and portfolio-wide Q&A
• ✓Feedback and improvement loop via Airtable + OpenAI analysis for continuous refinement [Added Jul 31, 2025]
• ✓Loading state messages to keep users informed during answer generation [Added Aug 3, 2025]