After 147 comments, which feature should a life-log app build next?
An existing public summary describes Meiyiji combining check-ins, plans, item records and important dates, with Android, to-do and note requests among 147 comments. Feedback can reveal questions; it is not a user count, order total or payment validation.
What to consider
Distinguish people who cannot access the app from those who can enter but cannot finish a task, then improve one recurring workflow. The public summary says Meiyiji combines check-ins, plans, item records and important dates; among 147 comments were requests for Android access, to-dos and notes. That is a reported comment count, not 147 unique users or paying customers. Establish the intended tasks and whether the current entry point works before expanding into an all-purpose app.
Access requests and feature requests need different answers
Someone asking for Android access may not have used the current product. A to-do or note request needs clarification about where it belongs in a task. Separate access problems, friction in existing features and missing capabilities instead of placing every comment into one development backlog.
The summary gives no counts by request type, downloads, activity or sales, so it does not establish a majority preference. Ask people willing to elaborate about the actual situation. No such interviews were conducted for this article, and the summary is not treated as a complete user study.
Complete one workflow among the existing record types
For item records, for example, ask a trial user to add, find and edit one record, checking whether it is saved and retrieved correctly. This is a proposed acceptance task, not a description of Meiyiji’s implementation. Assess repeatable use of the existing purpose before adding another entry point.
Repeated page switching for one task may justify simplifying the information path. Requests for richer categories or appearance can be prioritized separately when the task already works. Use observed task behavior rather than the appeal of a feature name in a comment.
Treat monetization ideas as hypotheses until tested
The summary proposes possibilities such as cross-platform subscriptions and template packs; it does not report sales of those offers. Define the buyer, continuing value and unresolved need after a free trial. Interest in discussing features supports further inquiry, not a revenue forecast.
This case is a lead for investigating life-log products. The article uses only the existing public summary, without reading the paid post, trying the app or verifying comments, availability or pricing. Completing one useful workflow and expanding from observed usage and payment feedback is a proposed approach that still needs testing in your product.
Source links
The links below were supplied with the collected records. This article offers independent analysis of their summaries; we have not individually checked the original sources or tested the products.