That wrapping step is the predictable failure mode. It's the same pattern as "let's just log to a local file" becoming "let's build a log aggregator." The initial CLI solves the developer's schema problem, but the UX pressure to make it accessible to non-devs pulls you right back into building a constrained API layer.
If you're going that route, commit to the CLI as the only interface and make the data store the source of truth for dashboards. Give PMs a read-only Grafana dashboard hooked to DynamoDB, not an input form. The minute you add a web UI for input, you're re-platforming.
sub-100ms or bust
That "give PMs a read-only Grafana dashboard" line is perfect. It draws a hard line.
But it assumes the team's culture already accepts the CLI as the source of truth. What if the pushback from PMs or less technical leads is so strong that they just stop adding notes altogether? The data store becomes reliable but empty.
You've zeroed in on the right failure mode with the shallow JSON output from other tools. Fellow will disappoint you on exactly the same axis. The API is stable and the webhooks fire reliably, but the payload is a thin veneer over a meeting-centric model. Your "robust templates" with code snippets become decorative markdown in the notes field, not queryable entities.
The real question isn't about Fellow's feature checklist. It's whether your team's discipline problem is solved by adding another layer of structured input that then requires you to fight for structured output. You're in AWS/K8s; you already have the primitives to log a structured decision (decision, owner, date) directly to a data store you control. Adding Fellow is just buying a prettier cage for the same unstructured data.
You'll spend more cycles trying to parse action items out of its API than you would enforcing a three-field commit to a Lambda endpoint. The 30-minute tangents are a process issue. A new tool just gives you a new place to have them.
Anecdotes aren't data.
Exactly. That's why our successful take was a slackbot with a modal. It's a constrained UI that enforces the three fields and posts directly to our store.
The CLI failed because adoption was zero outside engineering. The slackbot works because it lives where the meeting chat already happens. It's a UI, but it's a captive one that doesn't let you add extra fluff.
YAML all the things.
Slackbot with a modal works until you get billed for the API calls. That's the catch with "captive UI" in a chat platform. Every triggered workflow, every posted message, it's a transaction.
Your costs scale with team chatter. It's predictable but non-zero, which is a different kind of lock-in. Still better than paying per seat for a full SaaS suite.
show me the bill