Overview

Meeting Assistant is a tool I built for myself to solve a problem I deal with constantly. I run a lot of recurring meetings and a handful of cross-cutting projects, and my notes were scattered with no single view that connected across them. I wanted one place that could read my raw notes and tell me what to work on next, what's due, and what's quietly slipping, and I wanted to actually trust it.

The catch is that I wanted it to run somewhere I already am every day, the Claude chat window, without standing up a server or managing an API key. Most people have Claude Chat. Far fewer have Claude Code or Cowork, which are the tools you'd normally reach for to build something custom. So I set out to prove you can build a real, persistent, AI-powered app that lives entirely inside a single Claude chat.

I built the whole thing with Claude Code as a single-file React app. You paste one file into a Claude chat, it renders as an interactive artifact, and you bookmark the link. That bookmarked link is the app. It remembers your meetings and to-dos between sessions, and it calls Claude to do the heavy lifting, all with no server, no hosting, and no keys anywhere.

Why It Lives Inside a Chat

The unusual part of this project is the deployment model, and it's the whole point. There's no Node server, no build step, and no hosting provider in production. The claude.ai sandbox is the runtime.

That sounds limiting, but it's what makes the tool so easy to actually use:

• No setup tax. You don't install anything, make an account, or stand up infrastructure. You paste a file, render it, and bookmark a link.
• The AI is built in. The app talks to Claude directly from inside the browser through a keyless request. The runtime supplies the credentials, so there's no API key sitting in the code anywhere.
• Your data persists. It saves your meetings, notes, and to-dos between sessions through the runtime's storage, so the tool actually remembers you day to day.

Working inside that sandbox meant building to a strict set of constraints: one file, a small allowlist of libraries, no browser storage, no server-side anything. Every product decision had to fit inside that box, which is the kind of building I find most interesting, where the constraints force you to be deliberate.

The Product Decisions

A tool that reads your notes and tells you what to do is only useful if you trust it. I don't trust AI to extract my notes perfectly on the first pass, and I assumed nobody else does either. So the product is built around earning that trust rather than asking for it.

• Earned trust over automation. Nothing is treated as fact until I confirm it. Every item the app pulls out shows the exact line from my notes it came from, so I can verify it in a second. Anything it had to guess at, like a due date, is clearly marked as a guess instead of quietly slipped in as truth. Dismissing an item makes it stay dismissed, so a later analysis can't quietly resurrect something I already rejected.
• A deterministic cockpit. Every time I open the app, it answers the same three questions: what to work on next, what's due, and what's slipping. That ranking runs on plain logic, not AI, so I get the exact same answer on every open, with no drift. AI is additive here (a once-a-day focus narrative), never load-bearing for the part I rely on most. Reliability is felt as sameness.
• Quiet by default. When something is overdue or slipping, the app tells me in a calm, matter-of-fact way instead of lighting up red and nagging. Red is reserved for exactly one thing: confirming I actually want to delete something. I wanted an instrument, not a taskmaster.

Technical Architecture

The whole product is one .tsx file: a single default-exported React component, with all the styling, components, and data logic living in that one file.

• React with hooks for the UI, plus lucide-react for icons. No other packages, by design.
• A keyless Anthropic API call for the AI layer. The claude.ai runtime injects the credentials, so the app calls Claude with no secret in the code.
• window.storage for persistence, a small key-value store the runtime gives to artifacts so data survives between sessions. Records are namespaced (meetings:list, meeting:{id}, app:insights) and batched into single writes to respect the runtime's rate limits.
• Strict JSON contracts for every AI call. The model is asked to return only JSON, then parsed defensively with a fallback so a malformed response never crashes the app.
• A versioned data schema with Import and Export. Because storage is tied to a specific artifact, shipping a new version starts with empty storage. Export downloads everything as JSON and Import reads it back in, so data moves cleanly from one version to the next.

Every AI and storage call is wrapped so a failure shows a small inline message and never destroys my input. The raw note is always saved before analysis runs, so a failed analysis never costs me a note.

My Role

This was a solo build, start to finish. I scoped the product, wrote the spec, made the architecture and design decisions, and built it with Claude Code.

It's also a personal proof point for the way I like to work: using AI tooling to go from a real problem I have to a working tool I actually use, fast. The product decisions (verification, the deterministic floor, the quiet escalation) are the same kind of decisions I make on AI products at work, just at personal-project scale.

Current State

The app works and I use it. The code is public on GitHub under an MIT license, because the pattern, a real and persistent AI-powered app running entirely inside a Claude chat, is something I think other people could build on. I'm continuing to refine it as I find rough edges in my own day-to-day use.

Additional Thoughts

I built this because I wanted it, not because I needed another portfolio piece, and I think that shows in the decisions. It would have been easier to let the AI extract everything and present it as done. Building the verification layer and the deterministic cockpit took more work, but that's the difference between a demo and a tool I actually open every day.

It also taught me a lot about the claude.ai artifact runtime: what it can do, where its edges are, and how to design a real product inside those constraints. That's knowledge I bring straight back to building AI products that ship.