MVP — My Verbal Promises

Remember the promise, not the meeting.

Comment

Inspiration

A transcript can preserve every word and still lose the commitment.

Most products in this space optimise the capture of the meeting itself. Otter transcribes the full conversation. Fireflies records, transcribes, summarises, and analyses it. Granola removes the visible bot, but still listens during the meeting to produce notes. They are meeting-intelligence products.

MVP starts with the opposite constraint: do not record the meeting at all.

The problem is not a lack of captured text. It is the friction of returning to a long transcript or summary to recover one sentence near the end:

“I will send the revised page on Friday.”
“They will confirm the colours before production.”
“We moved the appointment to Tuesday at 18:30.”

Those small commitments rarely deserve a meeting archive or a project-management workflow. They still affect trust. MVP asks for about twenty seconds immediately after the conversation, while the agreement is still clear. Then it gets out of the way.

The idea can look almost too small to be a product. That is the point.

The name carries the same tension. In product language, MVP means Minimum Viable Product: the smallest thing that works. In sport, it means Most Valuable Player: the one that matters most. Here it becomes My Verbal Promises — the minimum interaction needed to protect the most valuable part of a conversation.

What it does

MVP asks one question when a call or meeting ends: What was agreed?

The user answers by voice for about twenty seconds, or types instead. MVP immediately preserves the original recollection, then uses OpenAI to identify who committed to what, by when, and under which condition. It separates the result into You, Them, and Request, so a request does not quietly become a promise the user never accepted.

The result is stored by relationship. The home screen and semantic search surface the open promise trail for that person, without requiring folders or exact wording.

A promise is made by a person, not by a clean transcript. The user can therefore add optional private context about how they remember being in that moment — rushed, pressured, anxious, sleepless, or simply OK. MVP never infers that state and never treats it as evidence. It is there for the user's future self, because the conditions in which we said yes can matter when we return to what we promised.

MVP also supports personal plans and appointments without asking the user to choose a mode. A sentence about a groomer or coffee with a friend becomes a Personal memory; a clear date can open as a prefilled Google Calendar event, with .ics available as a fallback.

How we built it

MVP is a zero-build mobile web application with a small Node.js server.

  • gpt-4o-transcribe converts the short voice capture into text.
  • GPT-5.6 uses the Responses API and a strict Structured Outputs schema to extract the contact, context, record type, summary, clarification state, and individual commitments.
  • text-embedding-3-small enables approximate retrieval across the promise library.
  • localStorage keeps structured memories immediately available.
  • IndexedDB preserves original audio locally.
  • Responses API calls use store: false; text or audio is sent to OpenAI only after an explicit capture.
  • A service worker provides an installable, offline-capable PWA shell.

Saving does not wait for AI. The browser writes a processing receipt first, then attaches transcription and structure asynchronously to the same record. A deterministic local analyser keeps the product testable when credentials are unavailable.

How Codex was used

MVP did not exist before OpenAI Build Week. I started the concept and v1 prototype in ChatGPT Work on July 18, 2026, after receiving the event email. I then used Codex to turn it into the complete v2 application submitted here.

Codex helped turn the product principle into a working application, implement and debug the capture and persistence flows, shape the strict commitment schema, build semantic recall, create lifecycle and calendar interactions, inspect the interface in desktop and mobile browser states, exercise the live GPT-5.6 endpoint, extend tests, and prepare the final repository and submission.

As a designer, I directed every visual pass. I set the editorial hierarchy, warm paper-and-ink palette, serif display typography, coral emphasis, spacing, control proportions, and compact mobile canvas. I also kept revising what should lead and what should recede: source material had to remain available without competing with the promise; status controls had to be consistent without becoming heavy; judge-facing demo information had to sit outside the product's visual voice. Codex translated that direction into code and helped me test each decision in the live interface.

The product decisions remained mine: record the recollection rather than the meeting; retain the original words; treat requests differently from accepted promises; preserve ambiguity; organise memory around people instead of folders; keep the human context in which a promise was made without asking AI to invent it; and make the interface feel calm enough to use immediately after a real conversation.

Challenges

Recording less, without remembering less

Most meeting products solve memory by capturing the entire meeting. MVP had to recover enough structure from a short, subjective recollection without pretending that recollection was objective proof.

Saving before the model returns

A fresh memory should not disappear because a transcription request is slow or unavailable. The local receipt and background enrichment flow were designed before the success state.

Distinguishing a promise from a request

“Can you send the files?” is not the same as “I will send the files.” The schema, system instructions, UI labels, and fallback logic all preserve that distinction.

Time without false certainty

Relative dates need the capture timestamp and timezone, but “Friday at eight” may still be ambiguous. MVP resolves what is clear and leaves the rest visibly unresolved.

Accomplishments

  • A complete capture → structure → lifecycle → recall loop in a working application.
  • Immediate local persistence with asynchronous AI enrichment.
  • A strict bilateral commitment model rather than a generic to-do list.
  • Original transcript and audio retained beside every AI interpretation.
  • A coherent mobile interface that works as an installable PWA.
  • Live English extraction that turns the boutique hotel demo sentence into two owners, a dated delivery, and a dependent approval.

What we learned

The hard part was not transcription. It was deciding what the system is allowed to claim.

A useful memory product needs provenance, uncertainty, and correction as visible interface elements. It also needs a narrower unit than “meeting.” Once the unit became the promise, search, relationship history, lifecycle state, and pre-call recall all became parts of the same product rather than separate features.

What is next

  • read-only calendar integration for real post-meeting and pre-meeting triggers;
  • commitment threading and duplicate detection across repeated conversations;
  • low-confidence review prompts driven by the returned schema confidence;
  • optional confirmation-message drafts that the user can review and send;
  • broader end-to-end coverage for recording, offline persistence, and PWA updates.

Built With

  • codex
  • css
  • gpt-4o-transcribe
  • gpt-5.6
  • html
  • indexeddb
  • javascript
  • localstorage
  • mediarecorder
  • node.js
  • openai-responses-api
  • pwa
  • service-workers
  • structured-outputs
  • text-embedding-3-small
  • web-audio
Share this project:

Updates