The Backlog Your Users Write

A bug button, a feature board, and a coach that can file tickets on your behalf

April 2026

The most useful page in the Alma app is not the food logging screen, the coach chat, or the dashboard. It is two buttons, tucked near the bottom of the settings view:

Report a bug. Request a feature.

They used to be a link to a contact form. Then a Google Form. Then a Typeform. For most of Alma's life, user feedback arrived as a trickle of emails to a shared inbox, where it sat until someone felt heroic enough to triage it. The loop from "user notices something broken" to "engineer opens the relevant file" was measured in weeks.

It is now measured in minutes, and most of the time there is no human in the middle of it. This post is about how we got there, and where I think it goes next.

What a User-Filed Bug Actually Does

When a user taps "Report a bug" in settings, a sheet slides up. They type what happened. Maybe they attach a screenshot. They hit send. That's the whole experience.

Behind the scenes:

The iOS app posts the report to our backend, which writes a row to the bug_reports table with the user ID, message, and context.
A watcher, a Python daemon polling the database every three minutes, picks up the new row.
The watcher spawns a headless Claude Code process with access to the production database, our source code, and our observability traces.
The agent pulls the user's recent chat logs, finds the relevant food items, follows the processing trace through our systems, reads the source code, and writes an investigation markdown file explaining what went wrong.
If the fix is straightforward, a bad reference ratio, a corrupted nutrition value, a simple data bug, the agent fixes it in production and commits the change.
The user gets an email acknowledging the report. Often, by the time they read it, the issue is already fixed.

I've written about the watcher infrastructure in more detail here. The point for this post is that the hard part was not the autonomous agent. The hard part was the button. The button is what makes the user feel like reporting the bug is worth thirty seconds of their time. The rest is plumbing.

What a Feature Request Does

The "Request a feature" flow looks similar, but it routes to a different system.

Every submission lands on what we call the Alma Insider board. It's a list of every feature users have asked for, with vote counts, statuses (open, planned, shipped), and the original descriptions. Users can see the whole board, vote on each other's requests, and comment.

When a new request comes in, the backend does a quick dedup pass. If the title is semantically similar to an existing open or planned request, the new submission becomes an upvote on that request, plus a comment if the description adds new context. If it's genuinely new, a new entry is created.

This is boring and important. The default shape of a feature request system is "inbox of duplicates nobody reads." The dedup pass is what turns it into a signal. When an engineer or designer opens the board, they don't see five variations of "please add hydration tracking." They see one entry with 47 votes. The signal rises to the top automatically.

Once a week, a skill called insider-board-review pulls the whole board, groups requests by theme (Tracking Expansions, Wearable & External Integrations, AI Coaching & Insights, and so on), flags suspected duplicates or already-shipped items, writes a dated summary doc, and drafts an email to the team. We review it on Sundays. Items move to "planned." Items move to "shipped." The flywheel runs.

The Part That Surprised Me: The Coach Files Tickets Too

This is the part I didn't expect to work as well as it does.

Alma's coach is an agent. Users talk to it in natural language. They ask it questions about their nutrition, their goals, their day. Most of the time, the coach can answer directly using the data it has and the tools in its toolbelt.

But sometimes a user tells the coach something like "my HealthKit calories aren't showing in the daily total." The coach pulls the data. It's there. It checks the display layer. Something is off. The coach cannot fix a display bug. But it has a tool.

The tool is called file_support_request. Its instructions to the agent:

Use this when the user reports a bug you cannot fix (display issues, sync problems, data not showing); when a tool call returned an actual exception or empty response; when the user is experiencing a technical problem. Do NOT use this for nutrition questions, coaching disagreements, or feature requests.

When the coach decides to call it, the tool writes to the same bug_reports table the in-app button writes to. Same pipeline downstream. Same watcher picks it up. Same investigation runs. The user, having done nothing but describe a problem in conversation, gets an email saying their report has been filed.

There's also a sibling tool called submit_feature_request. If a user tells the coach "I wish Alma could also track how much water I drink," the coach can file that directly to the Insider board. Same dedup logic. If someone else already asked for hydration tracking, their description becomes an upvote.

The coach tells the user what it did. "I've submitted that to our feature request board. You can see it and vote on others in Settings → Request a feature." The loop closes in the conversation they were already having.

Why This Works

A few things had to be true for this pattern to feel good rather than creepy:

The coach has to be conservative. The system prompt explicitly tells the agent not to fabricate a technical failure to justify using the tool, and not to escalate coaching disagreements as bugs. We had early versions where the coach would panic-file a ticket every time a user sounded frustrated. The current system has a high bar: the tool only fires when the agent can articulate a specific, objective technical failure.

The coach has to tell the user what it did. No silent escalation. The response always names the action: "I've filed this with our team" or "I've submitted that as a feature request." Users who want to see the result know exactly where to look.

The pipeline has to be the same. Bug reports from the in-app button, bug reports from the coach, and bug reports from a user emailing support all go through the same bug_reports table and the same watcher. There is no second-class path. A user who prefers typing a bug description gets the same treatment as a user who casually mentions it mid-conversation.

Deduplication has to be aggressive. The feature request dedup uses Jaccard similarity on meaningful word tokens to merge submissions. We tuned the thresholds against real data. The goal was to be generous about merging, because false negatives (five duplicate entries for hydration tracking) destroy the signal faster than false positives (one merge that should have been two).

How to Build This in Your Product

If you're a founder or PM building an AI product, here is the minimum viable pattern:

Put a bug button and a feature button somewhere visible. Settings is fine. The friction to tap is the biggest variable in how much feedback you get. Even a plain textarea beats a link to a contact form.
Give the feature side a public-ish board. Votes. Statuses. Dedup. It doesn't need to be fancy. Ours is a single React page backed by two database tables. Users seeing their requests on a board, with votes climbing, is a surprisingly strong engagement mechanic on its own.
If you have an agent, give it a filing tool. Two tools, actually: one for bugs, one for features. Same underlying table as the buttons. The tool prompt should be strict about when to use it and when not to. Give the agent a way to tell the user what it did.
Automate the triage. Even without a full watcher system, a weekly skill that pulls all open bug reports and feature requests, groups them, and drafts a team summary is a massive lift. Our weekly review takes an hour of human attention instead of a day.
Close the loop in the product. When you ship something that came from the board, mark it shipped. Users who submitted it get a notification. This one small move has outsized effects. People start seeing the board as something that actually moves, so they bother filling it out.

Where This Goes: Collaborative Product Building

I want to zoom out for a moment, because I think what we're doing at Alma is a small, early version of something much bigger.

The traditional model of building a consumer app goes roughly like this. A small team decides what to build, based on some mix of their own intuition, a handful of user interviews, analytics dashboards, and the CEO's Twitter replies. They ship something. They watch it. They iterate. The loop from user desire to shipped feature runs on human bandwidth at every step: someone has to notice the signal, interpret it, write the spec, build the thing.

I don't think that model survives the next few years.

The pieces of a different model are already sitting in our codebase. A user can file a feature request by talking to a coach. The coach dedupes it against every other request ever submitted. A watcher can investigate a bug without human involvement. A weekly skill groups requests by theme and surfaces the signal. An agent can go from "user describes a problem in chat" to "committed fix in production" without anyone's pager going off.

What's missing is the next step, which is an agent that can look at the top of the Insider board, read the product requirements, draft the implementation plan, spawn a coding agent to build it behind a feature flag, roll it out to the users who requested it, collect their reactions, and iterate. Each of those steps is a tool we already have. They just aren't wired together yet.

When they are, and I don't think this is very far off, the shape of product development changes. The role of a founder or PM is not to write specs. It is to set taste, curate which user requests actually align with the product vision, and decide which ones to green-light. The community does the feature ideation. The agent does the implementation. The founder does the judgment.

This isn't a world where product teams disappear. It is a world where the bottleneck moves from "can we build it" to "should we build it." The judgment gets more important, not less. But the execution layer between a user saying "I wish Alma tracked hydration" and that feature being in their hands next Tuesday gets collapsed into something very close to a straight line.

The prerequisite for all of it is the boring infrastructure. The bug button. The feature board. The dedup. The clean pipeline where every source of user feedback lands in the same place. That is what you build first, because none of the interesting stuff works without it.

The backlog your users write is already there. The question is whether your product is set up to listen to it.

Building Alma, an AI nutrition coach with the tagline "Eat well, feel well." The Insider board lives inside the app at Settings → Request a feature. alma.food