--- title: "Choose Your Next Book by Taste" date: "2026-08-16" canonical: "https://raytally.com/en/ideas/2026-08-16-idea-91a40471/" generator: "RayTally · dev-prompt-v4" signal: query: "i wish there was a reliable database to find books and broadly reliable ratings for them (ala Letterboxd) because GoodReads obviously isn’t shit coffee (@eventualforever) August 14, 2026" observed_at: "2026-08-16T00:34:12.603Z" sources: - url: "https://x.com/eventualforever/status/2088407418044825767" boundary: "Published at 2026-08-14T23:28:23.000Z. Observed at 2026-08-16T00:34:12.603Z." - url: "https://www.thestorygraph.com/" boundary: "No publication timestamp is present in the source record." - url: "https://www.goodreads.com/review/guidelines" boundary: "No publication timestamp is present in the source record." - url: "https://openlibrary.org/developers/api" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-08-16-idea-91a40471/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Choose Your Next Book by Taste A book-discovery service that uses head-to-head choices and reading-completion data from people with similar tastes to help readers choose their next book. ## Product concept When readers are about to buy a book or start a long novel, the hardest signal to trust is often a blended five-star average: some people rate a classic for its historical standing, some dislike the genre, and others have only seen the screen adaptation. Rather than asking users to write long reviews first, the product presents two books of similar genre and length and asks: “If you could recommend only one to someone with similar tastes, which would you choose?” After a user has made a small number of choices, each book page prioritizes how readers with similar reading histories compare that title. It reports completed reads, mid-book abandonments, and adaptation-only experience separately, and separates “enjoyed reading it,” “would reread,” and “culturally important” into distinct measures. Readers can see whether a book’s low rating comes from pacing, prose style, or simply a mismatch with their expectations. To find their next book, users select a recent favorite and an acceptable length. The system identifies high-win-rate candidates from similar readers’ head-to-head choices, then shows similarities to books they have read and potential pitfalls. Users can also state whether they are choosing a book for research, entertainment, or rereading, so recommendations stop pretending every reading goal is the same. The initial launch can cover common fiction and nonfiction subgenres, with an emphasis on building explainable pairwise choices. Author interviews, social review feeds, and an all-category encyclopedic database are not essential. First, make every book page answer: “Why would readers like me choose this?” ## Why now (backed by facts) On August 14, an X post directly asked for a reliable book database similar to Letterboxd. As recorded on August 16, it had accumulated “193 likes / 2 reposts / 10,805 views,” giving visible discussion to the problem that blended ratings do not make it easier to choose a book. ## Direction (model inference, not independently verified) Target user: The core user is about to buy or begin a long work and does not want to rely on an average rating alone. The cost of a bad choice is high: it can waste several evenings of reading. They already have a few books they clearly loved or abandoned and can quickly make a binary choice. Genre-fiction readers, book-club members, and rereaders will feel the value earliest because they often hesitate between similar candidates. Minimal entry point: Start with the Open Library Search API to populate titles, authors, editions, ISBNs, page counts, and covers. A local database groups editions under a single work while retaining the edition each user actually read. The comparison pool includes only books in the same subgenre and of similar length, preventing meaningless matchups. Rank books with a Bradley-Terry model and initially show overall win rates. Once enough data is available, calculate separate results by completion status and reading purpose. The first version should not generate long summaries; it should show comparison samples, common reasons, and sample sizes. Clearly label books with limited data, and prioritize pairings with higher information value. The strongest case against: Pairwise choices require enough overlap in reading histories, so obscure works can easily go without results for a long time. If pairings cross genres or differ too much in length, genre preference will dominate win rates. Users may also vote based on covers, author names, or impressions from adaptations, contaminating actual reading judgments. Separating completed reads, abandonments, and adaptation experience makes every group sparser. If explanations rely on free text, moderation and classification costs will keep rising. Incorrect “similar reader” labels would also erode trust. Before investing further, validate whether popular subgenres can generate stable, repeated comparisons. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) The first users are most likely to come from genre-fiction communities, book clubs, and annual reading-list discussions. Create shareable head-to-head pages where participants vote and immediately see results from like-minded readers. Build focused comparison pools around popular series, award nominees, and books behind adaptations, so communities can start discussions directly. Each share brings in new pairwise choices, making data accumulation easier than with generic recommendation lists. ## Competitors & gaps (model inference) - The StoryGraph: StoryGraph already offers personalized recommendations filtered by mood, pacing, and genre. It also supports DNF status, content warnings, and more granular star ratings. These features answer what kind of book a reader wants at a given moment, and users can build a fairly complete reading history. Its public pages still center on individual-book ratings, tags, and algorithmic recommendations. It does not make head-to-head choices between similar books the primary unit of evaluation, nor does it prominently split recommendations by reading purpose. The judgments of finishers and non-finishers are still not directly comparable. This product can differentiate through explainable pairwise win rates. - Goodreads: Goodreads collects reader opinions through individual star ratings and written reviews. Its rules require raters to have read or attempted to read the book. That means both completed and abandoned books can enter the ratings. Written reviews add context, but demand more effort from users. Star ratings also blend enjoyment, willingness to reread, and cultural importance. Readers must sift through reviews themselves to understand what drove a low score. The platform does not ask users to choose directly between comparable books. The opportunity is to reduce input effort and show the basis for segmented comparisons. ## How it makes money (model inference) Use a freemium model with a paid membership. Free users can compare books, log reading, and view basic results; monthly members unlock narrower audience filters, full mismatch analysis, and deeper personalized recommendations. ## Source context Theme: Demand for a trustworthy book ratings and discovery database Trigger Web Trend observation: X @eventualforever — i wish there was a reliable database to find books and broadly reliable ratings for them (ala Letterboxd) because GoodReads obviously isn’t shit coffee (@eventualforever) August 14, 2026 Source metric: 点赞 193 / 转发 2 / 浏览 10805 (发布后累计) This is one observation bounded by its publication and capture times. It is not evidence of market size or a broad trend and only explains “why now.” ## Sources - i wish there was a reliable database to find books and broadly reliable ratings for them (https://x.com/eventualforever/status/2088407418044825767) - The StoryGraph | Because life's too short for a book you're not in the mood for (https://www.thestorygraph.com/) - Rating and Review Guidelines (https://www.goodreads.com/review/guidelines) - APIs | Open Library (https://openlibrary.org/developers/api) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.