Should I vibe code
Agendas, notes, action items, recordings, and meeting analytics
A one-to-one notes page is an HR file in a nicer font. Get the visibility rule wrong and it reads itself aloud.
?
Their verdict, the Business price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Eight entries here already argue about microphones, so skip that: assume you never record anything. What is left of Fellow is a shared document attached to a calendar event, a list of things people said they would do, and a private one-to-one space that two people co-own — and one of those two people is usually the other's manager. That is not a note-taking app, it is a small HR system with a nicer name. A one-to-one page accumulates the reason someone was off in March, the conversation about whether they are ready for the next level, and a manager's private line written under a heading the report can also see next week when a permission rule changes. Meanwhile the action-item ledger becomes the organisation's memory of who committed to what and when, which is useful right up to the week it is read back to somebody in a performance review or, eventually, by a lawyer. The build is genuinely easy — a calendar integration, a collaborative document and a checkbox — and the permission model on that document is the entire product.
What actually breaks
not "if". the specific failures.
- The one-to-one visibility rule, which is the only thing standing between a manager's private note and the person it is about, and which will be re-evaluated by your code every time someone changes team
- The calendar OAuth scope, which is almost always granted org-wide because it was easier, and which now means your app can read every meeting title in the company — including the ones named after an acquisition or a person
- Recurring events, which are a genuinely nasty data model: an instance edited out of a series, a series moved after some instances have notes attached, an attendee added to one occurrence only
- Attendee resolution, because the invite list is a historical artefact containing people who left, an external contractor added in March, and an alias that expands to forty people
- Action items, which get assigned to someone who was not in the room and never agreed to it, then chased by an automated reminder in their inbox
- The share link, which is usually a long URL that works for anyone holding it for as long as the document exists
- The audit question, which arrives the day someone asks who read their one-to-one page and when — and which you can only answer if you built read logging on day one
- Deletion, which has to reach the note, its revision history, the action items derived from it, the search index and the summary email that went out on Friday
The reorg lands on a Tuesday and four people change managers in the directory sync. Your visibility rule was written the obvious way: a one-to-one page is visible to the two participants and to the current manager of the report. Overnight the sync flips the manager field, and one of the new managers opens the page she has just inherited — eighteen months of her new report's one-to-ones with the previous manager, including the notes about a formal warning, the conversation about a health issue that was the reason for a period of reduced hours, and a line about whether he was worth keeping. Nobody exploited anything. The rule did precisely what it said. You find out because the previous manager, who wrote those notes believing they were his, notices that his access is gone and asks who else can see them now.
Is that you?
the verdict is a default, not a law
- It is a shared agenda for a team of peers, with no one-to-one space and no manager relationship encoded anywhere
- Visibility is set once, at document creation, by the people in the room, and never recomputed from an org chart
- Nothing is recorded or transcribed, so the page contains only what somebody chose to write down
- It is your own scratchpad, synced to your calendar, that nobody else can read
- It holds one-to-ones between managers and their reports
- Access is derived from a reporting line that changes underneath the document
- It is the system of record for commitments people will be assessed against
- You granted it org-wide calendar read access because the narrower scope was fiddly
If you build it anyway
the checklist, then the prompt that enforces it
- Design the permission model first, on paper, and show it to somebody who has managed people. Everything else in this project is CRUD; this is the product.
- Grant visibility to identities at the moment a document is created and never recompute it from the org chart. A note written for two people stays visible to those two people when one of them changes team, is promoted, or leaves.
- Request the narrowest calendar scope that works — the specific calendars you need, not the directory. Org-wide read is a decision you cannot quietly walk back once it is in the consent screen.
- Log reads on any page containing one-to-one content, and surface the log to both participants. If you cannot answer 'who has seen this', you are not running a private space, you are running a shared one you have not tested.
- Model recurring events honestly before writing the UI: series versus instance, edited exceptions, moved occurrences, per-instance attendees. Retrofitting this is a migration over other people's notes.
- Never assign an action item to somebody who was not present, and never let an automated reminder be the first time a person hears about a commitment attributed to them.
- Give share links high-entropy tokens, an expiry, and an identity check. A URL that works forever for whoever holds it is not access control.
- Make deletion one operation covering the note, its revision history, derived action items, the search index and any emailed copy — then test it by searching for the deleted phrase.
I am building a meeting agenda and action-item tool: shared notes attached to calendar
events, including one-to-ones. Treat access control as the product, not the plumbing.
1. Before any feature, write the permission model down and show it to me. Answer these
explicitly: who can read a one-to-one page, what happens when the reporting line
changes, and what happens when a participant leaves the company.
2. Bind visibility to specific identities at document creation. Never derive access from a
live org chart or a directory field. If I ask for "the manager can always see it",
refuse and describe the reorg that hands eighteen months of private notes to somebody
new.
3. Request the narrowest calendar scope that works. Do not ask for org-wide or
domain-delegated calendar read, and tell me what each scope actually exposes.
4. Build read logging for anything one-to-one before building the editor, and make the log
visible to both participants. "Who has seen this" must be answerable on day one.
5. Model recurring events properly before the UI exists: series versus instance, edited
exceptions, moved occurrences, per-instance attendee lists. Write tests for an instance
detached from its series.
6. Resolve participants from who actually attended, not from the invite list. The invite is
a historical artefact with departed staff and stale external addresses on it.
7. Action items may only be assigned to people present in that meeting. No automated
reminder may be the first time somebody hears about a commitment in their name.
8. Deletion is one operation across the note, its revision history, derived action items,
the search index and any emailed copy. Prove it with a test that searches afterwards.
9. Share links use CSPRNG tokens, expire, and are bound to an identity.
10. Do not build recording, transcription or per-person meeting analytics. If I ask, tell me
that turns this into a monitoring system with consent and employment-law duties
attached, and make me ask twice.
11. Out of scope: sentiment scoring, engagement metrics, cross-org search, CRM sync.
12. Close by telling me what $23 a seat buys that I am choosing to build myself.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment a manager and their report are both in the document. Twenty-three dollars a seat a month buys a permission model that has already survived reorgs at companies larger than yours, retention and redaction controls, an audit log that answers who read what, and a vendor to point at when somebody asks how their one-to-one notes were handled. That last question is not one you want to be answering about code you wrote on a Sunday.
$23/mo is cheaper than your weekend.
Export per meeting as markdown — agenda, notes, decisions, action items with assignee and due date — in a folder tree keyed by date and meeting title, plus a CSV of open action items. Do the export early, because the format is trivial while the schema is young and awkward once revision history and recurring-series exceptions exist. One-to-one content deserves separate treatment: export it to each participant individually rather than into a single archive somebody inherits, since a shared dump of private notes is the same failure as the permission bug, only slower.
Self-hosted team knowledge base with real-time collaborative editing and per-document permissions.
Collaborative markdown editor that covers the shared-agenda half without any calendar integration.
Questions
There are already eight meeting-notes entries here. Why does this one score differently?
Because the risk is in a different place. The others turn on a microphone: consent, per-state recording law, what the bot captured before the meeting started. Fellow's differentiator is the agenda and the action items, so its dangerous artefact is a document with two owners and an asymmetric relationship between them. You can build this without recording a single second of audio and still end up holding notes about somebody's performance and health that the wrong person can open.
Isn't the agenda part genuinely trivial?
The agenda is trivial and that is exactly the trap — an agent will hand you a working version in an afternoon, which is why buildEase sits above six here. What is not trivial is recurring-event modelling, attendee resolution from stale invites, and a visibility rule that survives a reorg. Those three are boring, unglamorous, and the entire difference between a weekend project and something colleagues can safely write in.
What is the smallest version that is actually fine?
A shared agenda for a team of peers with no one-to-ones in it, visibility set explicitly at creation, no recording, and a markdown export from the first commit. That is a good weekend and genuinely useful. The line is the manager-report relationship: cross it and you are storing employment records, with everything that implies about access requests, retention and who gets to read them after a reorg.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 88 — processing in the context of employment (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Talk-time and sentiment scores on named colleagues, kept forever and auto-emailed. That isn't notes, it's monitoring.
A transcript of a call someone didn’t know was recorded isn’t a side project. It’s evidence.
It never records you. It scrapes the captions — and the entire product hangs on a CSS class Google can rename.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice