Build vs Buy: The Real Cost of DIY Review-Reply Automation

You can build review-reply automation in a weekend. Keeping it alive is the part nobody quotes you for. A working prototype — pull reviews, ask an LLM to draft a reply, POST it back — is genuinely a Saturday of work. The gap between that demo and something you'd trust to answer a 1-star review in Portuguese, unattended, on a busy launch week, is where the real cost lives.

This is a straight build-vs-buy breakdown for the person who actually could build it. No hand-waving about "leveraging synergies." Just the concrete parts you'd own: the two store APIs (which are not one API), the two different auth schemes, the polling you can't avoid because there's no webhook, the 7-day window that quietly eats your history, grounding so the model doesn't invent a refund policy, multilingual coverage, and the maintenance tax that arrives every time Apple or Google changes something. Then the honest verdict on when each path wins.

The demo is three steps. The product is about fifteen. Before you estimate the effort, it helps to see the whole surface at once, because the LLM call (the part everyone thinks is the hard bit) is maybe a fifth of the work.

Here's the full parts list you're signing up to own and operate:

The single biggest surprise for people who scope this as "reviews API integration" (singular) is that you're building two integrations that barely rhyme. Apple's Reviews endpoints live in App Store Connect and speak JSON:API; you read with `GET /v1/apps/{id}/customerReviews` and answer with `POST /v1/customerReviewResponses`. Google's live in the Play Developer API as a `reviews` resource with three methods — `reviews.list`, `reviews.get`, `reviews.reply`. Different envelopes, different pagination, different error shapes.

Auth is where they diverge hardest. Apple makes you generate an API key, download a `.p8` private key exactly once, and sign a fresh ES256 JWT for each burst of calls, capped at a hard 20-minute lifetime with the audience string `appstoreconnect-v1`. Google makes you create a service account in Google Cloud, grant it access in the Play Console, and exchange its key for a short-lived OAuth access token. Neither is hard on its own. But you're now maintaining two credential rotations, two failure modes, and two sets of "why is this suddenly 401" debugging sessions. We wrote the full working references for each, the [App Store Connect Reviews API](/blog/app-store-connect-reviews-api-reference) and the [Google Play Reviews API](/blog/google-play-reviews-api-reference), and the deltas between them are exactly the parts a DIY build has to reconcile by hand. The [reply rules differ per store](/blog/reply-rules-for-every-app-store) too, so your logic can't be one-size-fits-both.

This is the constraint that reshapes the whole architecture, and it catches nearly everyone. Neither Apple nor Google will call you when a new review comes in. There is no "new review" event to subscribe to. If you want to know a 1-star review landed at 2am, you have to keep asking. We dug into [why there's no webhook for new app reviews](/blog/no-webhook-for-new-app-reviews) and the practical upshot is the same on both stores: you run a scheduled poller, you diff against what you've already stored, and you accept some latency between a review appearing and you seeing it.

Polling forces two more things you didn't budget for. First, quotas: Google Play meters you (community testing puts it around 200 GETs per hour and 2,000 reply POSTs per day), so a naive "poll every app every minute" plan hits the ceiling and starts throwing 429s. You need per-app scheduling and backoff. Second, and worse:

Calling an LLM to write a friendly reply is trivial. Getting it to write a reply you'd actually publish is not. An ungrounded model will cheerfully promise a refund you don't offer, cite a feature you killed two versions ago, or apologize for a bug that was the user's misconfiguration. Every one of those becomes a public, permanent, screenshotted reply under your app's name. Grounding — retrieving your real policies, your known-issues list, and your past approved replies, then constraining the draft to them — is the difference between a toy and something you'd let run unattended.

Then there's language. Reviews arrive in whatever language the customer speaks, and replying in that language measurably helps: the research on reply effectiveness (Srisopha et al., EASE 2021) ranks fit and effort above raw politeness. So you need reliable language detection, translation that doesn't read like a translation, and character-limit enforcement that survives the round trip (a reply that's 320 characters in English can balloon past Google's 350-char cap once translated). We go deeper on [replying in any language](/blog/reply-to-app-reviews-in-any-language), but the build cost is: another model in the loop, another failure mode, and per-language testing you'll never fully finish. And speed matters: the [faster you reply, the more it moves the rating](/blog/how-fast-should-you-reply-to-app-reviews), which puts pressure back on that poller you now have to keep healthy 24/7.

That reply looks effortless. Producing it reliably requires: detecting Spanish, knowing your real refund path (grounding), knowing 4.2 ships this week (grounding again), staying under 350 characters in Spanish (enforcement), and not inventing a policy (constraint). Miss any one and you've published a mistake. Multiply by every review, every language, every night.

If you're still estimating, here's the honest shape of a production build — not the demo, the thing you'd actually run for a year.

A build isn't a project, it's a subscription you pay in engineering hours. Store APIs shift. Auth schemes get deprecated. A new store behavior, say a change to how replies render or a fresh quota, lands with no warning and breaks your poller silently. Because there's no webhook, a silent break can go a week before anyone notices the queue stopped moving, and by then the 7-day window has erased the reviews you missed.

This is the number that flips most build-vs-buy math. The API integration is a one-time cost you can size. The maintenance is a recurring cost you can't, and it competes directly with your actual product roadmap. Every hour spent chasing an App Store Connect auth change is an hour not spent on the thing your users pay you for.

There's a real case for building. If review replies are your core product — you're a review-management platform yourself — you have to own this. If you have exactly one app, English-only, low volume, and an engineer who enjoys it, a small internal script is defensible. And if you have hard compliance reasons every byte must stay in your own infrastructure, build.

Buy when review replies are a means, not the product. If you'd rather ship features than babysit two store APIs, if you have more than one app or more than one language, if you want grounded drafts without building a retrieval system, or if you simply don't want a silent 7-day data-loss risk sitting in your stack — a tool pays for itself the first time it catches a 1-star review you'd otherwise have missed. Worth remembering why this matters at all: Google's own I/O 2019 data showed apps that respond to reviews gain about +0.7 stars on average. The automation exists to capture that lift consistently, not to be a fun weekend project.

Here's the clean split. Build it yourself and you own every row on the left. Use ReplyArgus and every row is handled for you — you keep control of voice and approval, we keep the plumbing running.

The math is usually clear once the maintenance tax is on the table. A weekend prototype is cheap. A reliable, grounded, multilingual, two-store, always-on reply system is a product — and it already exists. Start on the [Free plan](/pricing) (one app, 100 replies a month, no card), connect a store, and watch it draft your first grounded reply before you'd have finished writing the JWT signer. If it earns its keep, Indie is $29 and adds the knowledge base, roadmap board, and auto-publish.