01Research
Is anyone actually asking for this?
Store demand, search signals and competitive density are measured before a project is approved.
Stops here when demand is thin, or strong apps already serve it well.
Studio · Louisville & Seoul
8bit is the mobile app studio of VRAVIO Inc. A pipeline reads Google Play every day, scores what it finds, and forecasts the outcome — before a single line of code is written.
One job per app. No feature bloat.
Charts · keyword suggestions · ranking movements · review histograms
| Candidate | Demand | Supply gap | Score |
|---|---|---|---|
| PDF tools | Wide | 86 | |
| QR scanner | Medium | 74 | |
| Unit convert | Medium | 68 | |
| Step counter | Narrow | 61 |
Every score carries its reasoning, so a low one can be argued with.
The pessimistic case is the one that has to clear.
Illustrative — not live data
What the pipeline reads, every day
Public Google Play signal only — charts, suggestions and store metrics. No private data, and never another developer's assets.
01Research
An automated batch reads Google Play every day — charts, search suggestions, ranking movements, competitor install brackets, ratings and review histograms. Every record carries a reliability grade, and low-grade data is never allowed to calibrate a forecast.
Pulled on a schedule, not when somebody remembers to look.
Every record is tagged. Weak data is barred from calibration.
Leading apps taken apart — what works, and what reviews complain about over and over.
The need nobody serves becomes the specification.
Grade B and below never calibrates a forecast.
02Simulate
Before development starts, a cohort model projects installs, retention and unit economics, then runs a Monte Carlo across the uncertain inputs. We read the pessimistic case first. Projects that only work when everything goes right are dropped.
Installs and retention curves projected month by month.
Uncertain inputs sampled thousands of times, not fixed to one guess.
Revenue per user against the cost of building and keeping it alive.
Written before the run, so the result cannot be negotiated afterwards.
Day-30 retention. The bar is set before the run, not after it.
03Build & measure
The first version is deliberately small: original design, our own assets, and at least one thing the category does not already do. After launch, retention, stability and reviews are compared against the forecast, and the difference goes back into the model.
Not an accident, and not everything that fits in the sprint.
Our own name, icon, artwork and store listing. Every time.
Retention, crash rate and reviews on a schedule — fix or retire.
Every launch makes the next forecast less of a guess.
Every item is a blocker. None of them is a nice-to-have.
The gate
Nothing advances because somebody liked it. These are the points where a project dies, and what kills it.
01Research
Store demand, search signals and competitive density are measured before a project is approved.
Stops here when demand is thin, or strong apps already serve it well.
02Simulate
Installs, retention and unit economics are modelled across pessimistic, base and optimistic cases.
Stops here when the pessimistic case does not pay for the work.
03Build
A deliberately narrow first version, with at least one measurable improvement on the category.
Stops here when the scope cannot stay narrow, or the one clear improvement disappears.
04Measure
Retention, stability and feedback are compared against the forecast on a schedule.
Stops here when the real numbers miss the model and there is no honest way to close the gap.
Standards
Publishing many apps only works if every one of them is legitimate. These are the rules we hold ourselves to — the same four, on every app, with no exceptions for a good week.
Our apps use our own name, icon, artwork and store listing. We study categories and user needs — never another developer's assets, branding or copy.
We collect the minimum needed to run and improve the app. We do not sell personal data, and we say exactly what is collected in our privacy policy.
Ads are clearly labelled and kept out of critical interactions. No misleading buttons, no forced clicks, no surprise subscriptions.
Every app links to a person who answers. Support requests get a reply within two business days.
Apps
We are finishing research and the first builds. As soon as an app is live on Google Play it appears on this page automatically, with its store link, category and support contact.
Want to hear when the first one ships? Tell us.Questions
Within two business days. Louisville and Seoul cover different time zones, so a message sent overnight is usually read the same day.
Purchases in our apps are processed by Google Play, not by us. Refunds are requested through Google Play — open play.google.com/store/account, find the order, and choose Report a problem. If Google declines and you believe the charge was our error, send us a message and we will look into it.
See the data deletion page. It explains exactly what we hold, what gets deleted, and how long it takes.
Yes, and we would be grateful. Use the contact form, choose "Report a problem", and please give us a reasonable window to fix the issue before disclosing it publicly.
Contact
We are a small team and we read everything ourselves. A person replies within two business days.