Skip to content
Looph

Use case

Feature voting and roadmaps for mobile app teams

Collect feature requests and bug reports from iOS and Android users in one place, and close the loop with changelog updates that notify voters.

Start freeSee recommended setups
Steps in the loop
4
Members
Unlimited
To first board
< 10 min
To start
Free

The problem

What this usually looks like today

App Store and Play Store reviews are a terrible backlog: no threading, no voting, no way to notify a reviewer when you fix their complaint. Feature requests get buried in one-star reviews and support emails, and you ship blind to what your actual power users want next.

The loop

How Looph handles it

Four moves, one workspace — no re-entry between them.

  1. 01Give users a real feedback board to request features and report bugs instead of venting in a store review.
  2. 02Separate bug reports from feature requests with their own boards, each with its own posting, voting and approval settings, so triage doesn't mix the two. Tags work across both.
  3. 03Publish a changelog entry per release, labelled New, Improved or Fixed and categorised by app, linked to the posts it ships so their voters are notified.
  4. 04Link the board from inside your app in an in-app browser or webview; users sign in with email or Google. An in-product widget is coming soon.

A worked example

An app team replacing store reviews as the backlog

An illustrative team, not a customer story. Every step uses features described in the docs.

A mobile team ships an iOS app, an Android app and a small web app. Store reviews carry its feature requests, with no threading, no votes and no way to reply when something is fixed.

The team runs one board per platform plus a separate bug board, so a bug never competes with a feature for votes. The apps open the board in an in-app browser, where users sign in with email or Google; signing them in straight from the app is coming soon with the in-product widget.

Each release gets a changelog entry labelled New, Improved or Fixed and linked to the posts it resolves. Publishing marks those posts Complete and notifies their voters, instead of hoping a reviewer rereads the store listing. Four public boards need Growth: $59/mo, with 10,000 tracked voters.

Questions

Frequently asked

Yes. Boards are standard web URLs you can open in an in-app browser or webview. Users sign in there with email and password or Google; passing your app's signed-in user through automatically isn't supported yet and is coming soon with the in-product widget.

Yes. Create separate boards per app or platform (iOS, Android, web). The roadmap can be filtered by board, and each changelog entry can carry a category, such as the app it belongs to.

Give bugs their own board alongside the feature request board, with its own rules for who can post, vote and comment, and use tags such as crash, UI or sync for area and severity. Statuses are one set across the workspace, which you can rename and reorder; custom fields aren't available.

More use cases

Other teams running the same loop

Related

Features and templates for this workflow

Product

Templates

Start collecting feedback in five minutes

Free forever on one board, with unlimited members and a 14-day Business trial. No credit card, no sales call.

Start freeSee pricing

Unlimited members · Published prices · Cancel anytime