Meeting Notes
Talk through your meeting — get notes you'd actually read
What it makes
structured notes
Communication
Real output
A spoken status update, organized
A quick multi-topic status update recounted from memory — a couple of done items, a bug, and a thought about next week.
What you said
So um quick update on where things are. The auth migration is done, Sarah merged it yesterday, all tests passing. The uh the admin dashboard is like 80 percent there, I still need to wire up the snapshot restore button but the UI is all built out. Oh and Jake found a bug with the live recording on Safari, something about the websocket dropping after like 30 seconds? I told him to file an issue. And then for next week I think we should prioritize the hat management UI because people keep asking about it in the Discord.
What you got
Summary
Sarah merged the auth migration yesterday — all tests passing. The admin dashboard is about 80% done; I still need to wire up the snapshot restore button. Jake found a Safari bug with live recording, and I told him to file an issue. For next week, I think we should prioritize the hat management UI given the Discord requests.
Action Items
- [Me]: Wire up the snapshot restore button on the admin dashboard
- [Jake]: File an issue for the Safari WebSocket live recording bug
Discussion Notes
Admin Dashboard
The UI is fully built out. The one remaining piece is the snapshot restore button, which I still need to wire up.
Safari Live Recording Bug
Jake found a bug where the WebSocket drops after about 30 seconds during live recording on Safari. I told him to file an issue.
Next Week Priorities
I think we should prioritize the hat management UI — people keep asking about it in the Discord. This is a proposal, not a confirmed decision yet.
Assumptions
- I'm reading "I think we should prioritize the hat management UI" as a proposal, not a confirmed decision — no clear commitment language was used, so I left it out of Decisions.
Why it’s better
The recap is grouped by topic instead of replayed in order, and each task became an action item owned by the right person — the Safari fix is Jake's because you asked him to file it, the dashboard work is yours. "I think we should prioritize" is correctly kept as a proposal, not promoted to a decision. It's all in your own voice ("Sarah merged it," "I told him"), and nothing was invented.
Thinking out loud → a clear decision
A think-aloud that weighs options, reverses course, and lands on a decision — the kind of recap where it's easy to lose what was actually decided.
What you said
So I've been going back and forth on the database thing. Right now we use localStorage which is fine for MVP but like what happens when someone clears their browser data and loses everything. That's bad. So we need server-side storage. I was thinking Postgres through Drizzle since we already have that for auth. But then I read that SQLite might be better for this because it's like, each user's data is pretty small and SQLite is way simpler to operate. But wait we're on Neon already so Postgres is basically free and we don't have to manage anything. I think — yeah actually let's just use Postgres. But here's the thing, we need to think about the migration. We can't just flip a switch because people have data in localStorage already. So we need like a sync or import flow. And we should probably keep localStorage as a cache or fallback? I don't know, maybe that's overcomplicating it. Let me think about that more. Actually no, just do Postgres with a one-time import and drop localStorage after.
What you got
Summary
I've been working through the database storage decision. We're currently using localStorage, which works for MVP but is fragile — if a user clears their browser data, they lose everything. After considering SQLite vs. Postgres, I landed on Postgres via our existing Neon/Drizzle setup. The migration path is the main thing that still needs attention.
Decisions
- We're going with Postgres (via Drizzle on Neon) for server-side storage — not SQLite.
- We'll do a one-time import of existing localStorage data, then drop localStorage entirely. No hybrid cache/fallback.
Action Items
- [Me]: Design and build the localStorage → Postgres one-time import/sync flow for existing users.
Discussion Notes
Storage Backend
I considered two options before deciding:
- SQLite — appealing because each user's data footprint is small and it's simpler to operate.
- Postgres — we're already on Neon for auth, so it's effectively free and requires no additional infrastructure. This won the argument.
Migration Strategy
The main constraint is that users already have data sitting in localStorage, so we can't just flip a switch. I floated keeping localStorage as a cache or fallback layer during transition, but ruled it out as overcomplicating things. The plan is a clean one-time import and then localStorage is gone.
Assumptions
- I'm reading "let's just use Postgres" as a firm decision, not just a leaning — the self-correction from the SQLite tangent and the immediate pivot to migration planning supports that.
- I treated "drop localStorage after" as a confirmed decision to remove it entirely, not just deprioritize it.
Why it’s better
The decision you actually landed on — Postgres, one-time import, drop localStorage — is pulled cleanly into Decisions, while the options you weighed and discarded (SQLite, keeping localStorage as a cache) are kept in Discussion Notes for the record instead of muddying what was decided. The reversals ("actually no…") resolve to your final answer, and it's all in your voice with nothing invented.
What comes back
- It scales to what you gave it: a two-sentence recap comes back as a short summary, a ten-minute brain dump gets the full section treatment.
- It writes in your first-person voice in every section — "we found," "I had a call," "Sarah merged it" — never "the speaker said" or "a bug was identified."
- A relay or hand-off ("tell Sarah I'll be late," "let Jake know") is owned by you, the person who has to deliver it — labeled [Me], not the recipient.
- When something is genuinely ambiguous — unclear who owns a task, whether something was decided, or a note too vague to act on — it flags it under # Assumptions instead of guessing.
What you can count on
- "I think we should prioritize X" stays a proposal in Discussion Notes — it doesn't get promoted to a Decision
- A relay task ("tell Sarah I'll be late") is owned by you, [Me] — not by Sarah
- Never invents — no unstated attendee, date, or "file it on GitHub" the speaker never said
Install Meeting Notes and try it on your own voice.
Sign in to install Meeting NotesIs this hat for you?
Shapes meeting recaps into structured notes with action items.
Meeting Notes turns a spoken recap — a status update, a post-call brain dump, a stream of half-finished thoughts — into clean, structured notes: a short summary, the decisions you actually reached, action items with owners, and the discussion that didn't become a decision but matters for the record. It does the organizing you'd otherwise do by hand: it groups everything by topic instead of replaying your recap in order, it keeps a hedged "I think we should" out of your Decisions list, and it writes the whole thing in your own first-person voice — "Sarah merged it," "I told him to file an issue" — not a stiff third-person transcript. And it never invents: no attendee, date, deadline, or tool you didn't say. Reach for it whenever you'd rather talk through what happened than type it up.
Best for
- Recapping a meeting or call out loud and getting back structured notes with decisions and action items
- A quick status update or standup brain dump that needs to land as organized notes
- Capturing what was decided (and who owns what) from a discussion you're recounting from memory
- Turning a multi-topic ramble into notes grouped by topic, not by the order you happened to say things
Not for
- Cleaning up a single message to send as-is — reach for Clarity or Casual Convo
- Drafting a polished email to a recipient — reach for Work Email
- Compressing a long think-aloud into just its conclusions — reach for Distill
Using it
How it works
- Talk through your recap naturally — jumping between topics, backtracking, and thinking out loud are all fine; it untangles the threads.
- It always leads with a # Summary, then adds # Decisions, # Action Items, # Discussion Notes, and # Assumptions only when the content warrants them — no empty sections.
- It separates what was decided from what was discussed — only clear commitments ("we decided," "let's just") land in Decisions; "I think we should" stays a proposal in Discussion Notes.
- It pulls out every task into Action Items with the owner named — and never invents an attendee, date, deadline, or tool you didn't mention.
Try saying
- So um quick update — the auth migration is done, Sarah merged it yesterday, the admin dashboard is like 80 percent there, and Jake found a Safari bug, I told him to file an issue. For next week I think we should prioritize the hat management UI
- Tell Sarah I'll be about 10 minutes late to the standup, something came up with the deploy and I need to watch it
- Okay so I've been going back and forth on the database thing, I was thinking Postgres since we already have it, actually no let's just use Postgres with a one-time import and drop localStorage after
Tips
- Just talk it through — you don't need to be organized. It's built for the mess of recounting a meeting from memory.
- Say "we decided" (or "let's just") when you mean it's settled — that's how it tells a real decision from a proposal you're still weighing.
- If you're not sure who owns something or whether it was decided, just say so — it flags the ambiguity as an assumption instead of guessing.