Aug 29, 2026
How Feature Requests and Bug Reports Work in IGNITE AI
How to send useful feature requests and bug reports in IGNITE AI—what details help engineering, what to skip, and why in-app reports beat vague store reviews when logging breaks at night.
Product teams cannot fix what they cannot reproduce. A one-star review that says “AI sucks” teaches nothing; a tight bug report with device, steps, and a screenshot of the broken estimate does. IGNITE AI includes in-app paths for feature requests and bug reports so real logging pain reaches the people shipping the app.
The best feedback usually comes from people mid-workflow: camera failing on a dim plate, barcode mismatch at the shelf, a Friends share that did not post. That context is gold. Capturing it in-app beats hoping a social comment finds the right inbox.
This guide shows how to write reports that get traction, how to separate bugs from taste preferences, and how to request features without writing a second product roadmap. It is not a promise that every idea ships.
Bug versus feature: label it honestly
A bug is something broken relative to expected behavior: crash, blank screen, wrong save, sync failure, UI that traps you. A feature request is something new or improved: another export, a smarter default, a workflow shortcut.
Mislabeling slows triage. If Snap Track saved the wrong meal after you confirmed edits, that is a bug. If you wish the editor had a one-tap “add tablespoon oil,” that is a feature request—even if it feels urgent.
The minimum useful bug report
Include what you were doing, what you expected, what happened, and whether it repeats. Add OS version, app version if visible, and the screen name. Attach a screenshot or screen recording when privacy allows—blur calories if you must, keep the error chrome visible.
Note timing: right after update, on Wi-Fi versus cellular, after a long background. Intermittent bugs need frequency (“3 of 10 photo logs”). Vague anger without steps gets parked; precise reports get queued.
Reproducing photo and scan issues
For Snap Track problems, say which mode: meal photo, label, barcode, drink, or describe/voice-style input. Mention lighting, whether you edited before confirm, and if the bad data appeared only after save.
For barcodes, include brand and product name and whether the physical label disagrees. Database mismatches are often fixable when the product identity is clear—not when the report only says “scan wrong.”
Writing feature requests that survive review
State the job to be done in one sentence: “I need to re-log the same meal-prep box five days without rebuilding it.” Then describe your current workaround and why it fails. Skip mock UI lectures unless you are illustrating a real dead end.
Prioritize with your week, not the internet’s wishlist. Requests tied to adherence—faster edits, clearer servings, coach exports—usually matter more than cosmetic themes.
What not to put in a report
Do not paste passwords, recovery codes, or full payment details. Do not include other people’s private meals from a Friend feed. Do not threaten; it does not accelerate triage and can get the thread ignored.
Avoid bundling ten unrelated issues into one blob. Split crashes from wishlist items so each can close independently.
Store reviews versus in-app channels
Store reviews influence downloads; they are a poor bug database. Use them for high-level sentiment after you have already filed a reproducible report in-app. If you only review, engineering may never see the stack trace path you hit at 10 p.m.
If support follows up, answer once with the same structure. Echoing the original steps beats rewriting the novel each time.
How feedback shapes a photo-first app
Vision logging, label OCR, and social sharing fail in edge cases by nature. Field reports from real kitchens and gyms teach more than lab demos. Your boring edge case—steam on the lens, glossy takeout, multipack yogurt—may be tomorrow’s fix.
That does not mean every request ships next sprint. It means high-quality signal compounds. Low-quality noise slows everyone, including the features you actually want.
Where IGNITE AI wants the signal
Use the in-app feature request and bug report flows from Profile or help surfaces so metadata can travel with the ticket. Keep logging with Snap Track while you wait; workarounds like describe mode or saved meals often unblock the day even when a camera path misbehaves.
Premium users hitting AI capture bugs should say so—those paths are compute-heavy and worth precise reports. Honesty about Premium gates in feedback also helps: “blocked behind paywall unexpectedly” is different from “estimate wrong after I paid.”
Bottom line
Good reports are short, reproducible, and labeled as bug or request. Screenshots and mode names beat vague one-star essays.
When something breaks mid-log, file it in IGNITE AI’s in-app channels with steps—then keep the diary moving with a fallback capture path while the team uses your signal.