Add reviews and ratings to an AI-built app

Three decisions determine whether a review system is useful or a liability, and none of them is the star widget. Who is allowed to review, how you compute the score shown, and what happens to a review you would rather not publish. Settle those and the build is a day. Skip them and you get a product page with one angry five-star-average outlier and a legal question about whether you are allowed to delete it.

A practical build, in the order the decisions actually arrive.

Decision one: who can review

Three options, in increasing order of trust and friction:

Verified interaction is the right default for almost everything, and it has a schema consequence worth getting right up front: the review points at the order line, not just at the product.

reviews
  id, product_id, order_item_id,   -- the proof of purchase
  user_id, rating (1..5), title, body,
  status,                          -- pending | published | rejected
  created_at, published_at,
  helpful_count, reported_count
  unique (order_item_id)           -- one review per thing bought

-- not unique (user_id, product_id): a customer who buys
-- the same item twice is entitled to review it twice.

That unique constraint is the whole anti-spam strategy for the verified model, and it is one line. A reviewer cannot outrun it without buying again.

Decision two: the score you display

The naive answer is a mean, and the naive answer is wrong in a specific, visible way. A product with one five-star review shows 5.0 and outranks a product with 200 reviews averaging 4.6. Every customer can see that is nonsense.

The fix is to pull small samples toward the global average, weighted by how many reviews exist. In plain terms, a new product starts near the site average and earns its way to its own score:

-- m = how many reviews before we trust the item's own mean
-- C = the average rating across all published reviews
score = (n * item_mean + m * C) / (n + m)

-- with m = 10 and a site average C of 4.3:
--   1 review  at 5.0  ->  (1*5.0 + 10*4.3) / 11  = 4.36
--  50 reviews at 4.8  ->  (50*4.8 + 10*4.3) / 60 = 4.72
--   3 reviews at 1.0  ->  (3*1.0 + 10*4.3) / 13  = 3.54

Display the raw mean and the count to the customer, because that is what they expect to read. Sort and rank on the weighted score. Those two numbers serve different jobs and conflating them is the bug.

Store the aggregate rather than computing it on every page load. A rating column and a count on the product row, updated when a review is published or removed, is the difference between a product page that loads and one that scans your reviews table.

Decision three: moderation, before you need it

Review systems attract content you did not want: abuse, personal data about staff, competitor spam, and the occasional legitimate complaint you would rather hide. Decide the policy while nothing is at stake.

The approach that holds up:

• Publish verified reviews immediately, queue unverified ones. Delay on a real customer is itself a bad experience.

• Never delete, set status. A rejected review stays in the table with a reason. Deletion destroys your ability to show you were even-handed.

• Reject on conduct, never on rating. Abuse, personal data, off-topic, obvious spam. A one-star review that follows the rules gets published. Filtering by score is the thing that turns a review system into a liability, and customers detect it quickly.

• Give yourself a public reply field. One good reply under a bad review does more for a buyer than removing it would.

An automated first pass is cheap insurance here. Content moderation in an AI-built app covers wiring a classifier into the queue so a human only sees the ambiguous ones.

The build order

1. Schema with the order_item_id link and the unique constraint. Everything else depends on it.

2. Submission form, with the rating required and the text optional. Forcing prose halves your response rate.

3. Aggregate columns on the product, updated on status change rather than recomputed on read.

4. Moderation queue. A list with approve and reject, plus a reason field. Twenty minutes of work.

5. Display, with raw mean and count, sorted most recent first.

6. Invite email after fulfilment, which is what actually produces reviews.

The invite is the step teams skip and the only one that determines volume. A review request sent a sensible interval after delivery, with a one-click rating in the email, outperforms any amount of on-site prompting.

Photo reviews, and what they cost you

Customer photos lift conversion more than text does, and they are the single biggest increase in moderation burden you can choose. A text review needs reading. An image needs looking at, and the failure cases are worse: faces of people who did not consent, documents with addresses visible, and the occasional thing nobody wants in a moderation queue.

If you add them, three rules keep it manageable. Cap the count per review, because five photos per review across a thousand reviews is a job rather than a feature. Strip EXIF on upload, since holiday photos carry GPS coordinates and publishing a reviewer's home location is a real harm you caused. And never auto-publish an image, even from a verified purchaser, whatever your text policy is.

Sorting, once you have volume

Most recent first is correct until roughly the fiftieth review, and wrong after it. Past that point the top of the page is whatever arrived yesterday, which is not the same as what a buyer needs to read.

Helpful votes are the usual fix and they have the same small-sample problem as ratings do: a review with two helpful votes out of two should not outrank one with 180 out of 200. Rank on the lower bound of the proportion rather than the raw ratio, or more simply, require a minimum vote count before a review can reach the top slots. The cheap version that works surprisingly well is to show the most helpful review and the most recent critical review side by side, which is what buyers are actually looking for when they scroll to this section.

The structured data payoff

Published reviews can make your product pages eligible for star ratings in search results, which is one of the few on-page changes with a visible effect on click-through. Google's review snippet documentation sets out the required properties and, importantly, the rules: the reviews must be visible on the page, must be about the specific item, and self-serving reviews about your own business do not qualify for the markup. Adding aggregateRating markup for ratings a visitor cannot see on the page is a policy violation rather than a shortcut.

Common questions

Should I require a purchase before allowing a review?

For most products yes. Linking the review to an order item gives you a one-line anti-spam rule and a verified badge that readers trust. Open reviews mean ongoing moderation work.

How do I stop one five-star review showing as a perfect score?

Pull small samples toward the site-wide average with a weighted score, and rank on that. Show the plain mean and the review count to readers, because that is what they expect.

Can I delete negative reviews?

You can, and it is a bad idea. Reject on conduct rather than on rating, keep rejected reviews with a reason, and reply publicly instead. Suppressing by score is detectable and, in some jurisdictions, a consumer protection problem.

Where should the average rating live?

Denormalised onto the product row and updated when a review changes status. Computing it on read works until you have traffic, and then it is the slowest query on the page.

Do reviews help SEO?

They can, through review snippets in search results, if the reviews are genuinely visible on the page and the markup follows Google's rules. They also produce the long-tail phrasing real buyers use, which is useful on its own. For the wider build, see the guide to building an app with AI, adding user accounts for the reviewer identity, and prompting AI to summarise customer feedback once you have enough reviews to read in bulk.