Short answer
Bright App Data offers four services: a private ASO and technical audit, app repair for crashes and payment or login failures, security and source-code review for owners and buyers, and React Native and Node.js development. Every engagement starts from a free public audit, so scope is agreed on evidence rather than guesswork.
First, the free public audit at /app-audit. It reads the live listing and a sample of public reviews, then produces a permanent report with an ASO score, recurring complaint clusters backed by review excerpts, update history and an indicative value range. That report is yours whether or not you hire anyone.
Second, scoping. We agree what the public evidence cannot answer and what private access it needs — console analytics, crash reports, the repository, support tickets. This is the step that turns "users report payment failures" into a defect with a cause.
Third, the work itself, prioritised by what costs you most. Recurring complaint clusters usually come before feature requests, because a user who cannot pay does not care about the roadmap.
You can compare audited apps in your own category at /app-reports, and the scoring method is written out in full at /methodology.
Clear answers
We start from the free public audit, because it costs you nothing and it tells us where the evidence already points. Only then do we agree what private access is needed and what the work actually is. Nobody quotes a repair before seeing what is broken.
The public report is free and permanent. Private work is quoted per project after scoping, because a listing rewrite and a payments rebuild are not the same job. We do not publish a fixed price list for work we have not scoped.
Almost always. Most of what we do is inherited code: an app whose original developer is gone, or one that shipped fast and is now expensive to change. The audit exists precisely to make that inheritance legible before anyone commits.
Sometimes, and it depends on why it was removed. Policy removals need the violation resolved before resubmission; abandonment removals usually need the target API level raised first. Both start with reading the removal notice, which only the account owner can see.
Yes. Both stores raise platform requirements on a rolling schedule, so an app with no maintenance plan drifts toward removal regardless of how good it is. Ongoing work is usually the cheaper shape once the first round of repair is done.
Yes, and we do. 47.4% of audited apps have never answered a review, which is often a sign the owner has already moved on. If the honest answer is "rebuild" or "walk away", that is the answer you get.