The app factory.
An honest assessment.

Audit date: 6 September 2026. This report assesses the proposed business: discover underserved needs in Google Play and the App Store, build useful niche products, publish them on both stores, and automatically improve them using platform and customer feedback.

Verdict: we have a substantial prototype of the production machinery, but we have not demonstrated the business or a reliable unattended production cycle. The limiting factors are integration, truthful completion criteria, account operations, and evidence of customer demand. Another app generator or another model will not fix those by itself.

The immediate recommendation is to finish one existing product through both stores, including an update driven by feedback, while validating demand for the next product. Then run the next selection and release without routine owner decisions. Stop expanding the catalogue until that works repeatedly.

This is an audit and implementation proposal. It does not claim that the proposed system has been built, that an app has been published during this audit, or that platform approval can be guaranteed.

1. What the evidence supports

I inspected the worktree at 5bc2577b4ae3530e9634cb5548ff5693bd66357a, checked GitHub's current main, inspected relevant unmerged work, read the operating records in /var/lib/ship-game, checked the installed service, and queried GitHub Actions. I also checked current primary documentation from Apple, Google, Expo, and AppTweak.

There are three different sources of truth, and they currently disagree:

The operating catalogue contains seven apps, five active pipelines, no stages recorded as running, six stages awaiting people, and three blocked stages. All seven manifests use manual release mode. The committed Studio snapshot reports zero live apps. Neither these records nor the available receipts establish a complete autonomous release to both public stores.

That is “no verified end-to-end success,” not a claim that I independently proved every app unavailable in every territory today. Fresh authenticated store verification was not available through the deployed configuration: the control process has Apple API credential variables, but lacks the Play service-account path and both required store API proxy variables. I did not bypass those restrictions or change accounts to obtain a result.

The dated, sanitized audit evidence records the counts, configuration presence, source hashes, branch state, CI results, and test totals. No credential values are included.

2. What we have already done

Discovery and research, beginning in August

The original idea was a factory for small, legitimate utilities targeting specific searches with weak competition. We built a concept site, a real-results page, an ASO workbench, comparisons with commercial data products, and a set of experiments testing the research assumptions.

The collection method evolved materially. The earlier version asked agents to invent search stems. The next version traversed autocomplete prefixes, reducing dependence on the vocabulary agents happened to invent. The saved v3 corpus contains 228,966 unique queries, with prefix-tree collection for Russian and US English; the wider report also carries earlier seeded results from other locales. It should not be described as equally exhaustive research across 17 markets.

The saved report, generated on 16 August, contains:

The work includes caching, rate limits, resumable collection, lexical matching, incumbent size and beatability, metadata checks, competitor review analysis, rank snapshots, and explicit distinctions between measured and estimated numbers. These are reusable assets. The collected dataset is a dated snapshot; there is no evidence here of a continuously refreshed discovery-to-revenue learning loop. Sources: repository overview, saved report, ASO research, experiments.

Product creation and delivery experiments

We moved from the older Android App Factory approach into tracked React Native apps, then developed a shared design contract, browser previews, remote Android interaction, iPhone capture and signing, and a multi-app scheduler layered on Chief. More recently we added an Expo/EAS reference app.

The later iOS work deserves explicit credit. GitHub confirms that PR #72's commit e418c91524bbe7ff609f46ffa68af19afb4fc2d8 successfully ran on a self-hosted Mac, produced iPhone evidence and store screenshots, and exported an IPA. The signing job has a non-expired artifact of about 9.4 MB compressed; the capture job also has non-expired artifacts. This is stronger evidence than an architectural plan. It is still a build/export result, not a submission or public release.

Product evidence: Tire research, Tiny Triumphs Play receipt, EAS build records, artifact custody, and the runtime extract linked above. The updated Tire internal-testing account is in commit 9043552, which is not in audited main.

3. What we did right

1. We questioned the search method. Replacing invented stems with broader discovery was a meaningful correction. Keeping raw observations, provenance, and resumable stages makes the research reusable.
2. We separated evidence from estimates in much of the ASO layer. Ordinal autocomplete signals should not be sold to ourselves as monthly search counts. The experiments also preserve criticisms of their own conclusions.
3. We built real native products and exercised difficult delivery steps. Persistence bugs, device rendering, signing, upload processing, and Xcode compatibility were addressed through actual work. This is not merely a collection of mockups.
4. We introduced product-specific design and device evidence. Authored assets, semantic tokens, interaction feedback, and explicit states raise the quality floor. The design contract is worth keeping, with category-appropriate flexibility.
5. We added useful operational safeguards. Resource serialization, retries, checkpoints, credential hygiene, signer checks, and separate platform branches are sound foundations. They protect expensive account and signing assets.
6. We started moving toward supported interfaces. Apple REST upload, GitHub macOS builds, and Expo/EAS can reduce bespoke operational work. Android and iPhone development can proceed independently.

These assets justify finishing the current system. They do not justify increasing app production before the final stages work.

4. What is preventing the intended outcome

A. “No exact competitor” has become a substitute for “a valuable unmet need”

Search terms are not businesses. A general app can satisfy a narrow need without using its exact phrase in the title. A poorly rated incumbent can still have distribution, data, or workflow advantages we cannot cheaply reproduce. A query can be empty because demand is tiny, because users use a website or spreadsheet, or because the task does not justify an installed app.

The App Store is mainly used as a cross-check for Play-selected opportunities. That misses Apple-originated opportunities and assumes demand transfers across platforms and territories. The code also deliberately falls back to the US storefront for some unmapped countries; a Russian-language query checked in the US is weak evidence about its original market. Sources: cross-check selection, country mapping.

Change: define an opportunity as an audience, recurring or high-value task, current workaround, specific dissatisfaction, differentiated solution, acquisition route, and payment hypothesis. Use search gaps as one input. Investigate both stores independently, then reconcile by user need and actual geography.

B. Our strongest research headline evaluates the wrong outcome

The fifth experiment reports demand AUC 0.4205, search-result AUC 0.8888, and only 0.0011 improvement from a constructed frequency signal. Those calculations concern our own definition of an empty, beatable niche.

In the experiment code, the label depends on gap class and beatability. The search-result ranker uses beatability, incumbent installs, and lexical freedom—the ingredients of that label. It is unsurprising that it recovers the label well. Lifetime incumbent installs are also not an oracle for current, query-specific buying intent.

The adversarial review already noticed this circularity and the sensitivity of the supposed frequency ceiling. So the failure was partly not converting an acknowledged caveat into a different decision standard. These experiments do not establish that paid market data is useless or that our top-ranked niches will produce revenue.

Change: evaluate against outcomes unavailable to the scorer: observed acquisition, activation, repeat use at the task's natural cadence, conversion, refunds, and contribution margin. Use later time periods and different concept clusters as holdouts; avoid splitting near-identical keywords across train and test.

C. We have little commercial learning infrastructure

Tiny Triumphs and Launch Lantern explicitly have no purchases, advertising, analytics, or external service. That is a reasonable privacy-first prototype choice. It cannot, by itself, validate a profitable app factory. I found no implemented portfolio loop joining niche selection to acquisition cost, cohort usage, payment, support cost, and subsequent selection.

Store-provided metrics can preserve much of the privacy benefit. Where additional product events are needed, collect a minimal, accurately declared set. Keep the original promises for existing builds; a new analytics or monetization SDK requires corresponding privacy and listing changes. Sources: Tiny Triumphs listing, Launch Lantern product description.

Change: treat technical publication and commercial validation as separate milestones. A free pilot can prove delivery; it must not count as proof of willingness to pay. Do not invent subscription value for an occasional calculator.

D. The workflow was deliberately designed to stop for people

Main's stage definitions include owner concept selection, a pinned art worker, a pinned console worker, and explicit store approvals. The scheduler turns worker completion into a merge checkpoint. Even releaseMode: auto does not remove concept and merge decisions.

PR #72 improves this: art and Play preparation become dispatchable pool work, and a constrained runner executes store actions after fresh authorization. It still retains concept selection and merge checkpoints. Existing runtime manifests remain manual. Turning on one flag does not create unattended operation.

Change: define standing, machine-enforceable authority for routine releases within a portfolio policy. Automatically select eligible concepts, validate worker artifacts, merge through a protected queue, and execute authorized submissions. Keep account/legal exceptions explicit. No routine art, merge, or “click publish” task should need the owner's attention once that policy is configured.

E. Canonical code, installed code, and operational state diverge

Concrete examples from this audit:

• Four of seven runtime manifests lack the nested Android and Apple identifiers expected by StoreRails. Some have older flat fields; one has no metadata. Their records can look progressed while the current adapter cannot use them.
• Setpoint remains at a merge checkpoint despite its source being on main.
• Launch Lantern's runtime says no usable Mac runner, while newer GitHub jobs demonstrate successful Mac work.
• Main's Tire handoffs still discuss the old key and inactive testing; an unmerged recovery branch records the later state.
• The service is healthy as a process, yet the deployed configuration cannot support the store API monitoring it advertises.

Change: add explicit manifest migrations and a reconciler that compares database state with GitHub, artifact storage, and store observations. Deploy immutable revisions with a recorded source SHA. Service health must report blocked capability and stalled progress, not just whether Node is running.

F. “Live” can be wrong even when the code succeeds

Both platform adapters fall back to another release when the requested version is absent. I reproduced this offline: request version 2, return only version 1, and the Apple adapter reports live: true; Play selects version 1's completed track. Apple pre-order readiness also counts as live in the current code. See reproductions and adapter.

This can turn an old release into false evidence that a new fix shipped. The done status validator only requires artifact strings and passing check records; that alone does not verify artifact existence, identity, freshness, or completeness. Source: status handling.

Change: bind every claim to package/bundle, platform, version/build, source commit, artifact hash, store record, track, territory, and observation time. Missing exact versions stay unknown or pending. Pre-order is separate. Public availability must include an independent storefront observation and an eligible-device install/run check; upload and review acceptance remain separate milestones. Stores may repackage or re-sign delivery artifacts, so verify their identity and provenance rather than expecting downloaded bytes to equal the uploaded binary.

G. The feedback loop mostly routes states; it does not yet repair from evidence

S6 is marked done when a rejection is classified and downstream stages are reset. That is routing, not successful repair and resubmission. General Apple rejection state lacks the reviewer's full explanation; keyword-based routing cannot reliably distinguish a missing screenshot from a minimum-functionality rejection.

The Play customer-review adapter discards the review text, retains ratings and timestamps, and the monitor requests 20 records without following further pages. Apple customer feedback, production health, and product economics are not joined into this monitor. S7 initially waits for both stores to be live, and its Promise.all lets one store's failure prevent the combined observation. Sources: store adapter, Play review extraction, rejection handling.

Change: separate platform review messages, build-processing errors, customer reviews, beta feedback, and crash/ANR telemetry. Retain the original evidence, classify the cause, reproduce the defect, generate a constrained patch, rerun affected acceptance tests, submit a new identified attempt, and reconcile the actual result. Monitor each platform as soon as it has a build or submission.

H. Visual evidence is valuable but narrower than full behavioral QA

The newer iPhone work captures actual native screens and checks their text with Apple Vision. However, the workflow bundles index.screenshots.js; its screenshot host cycles fixtures and uses no-op handlers. Even a frame named “back-return-navigation” does not prove someone successfully navigated back in the production app.

Keep that lane for visual inspection and store assets. Add a separate lane that launches the real app entry point and performs actual user actions, persistence/relaunch, permission, keyboard, offline, and upgrade scenarios. Test the release candidate and its store-installed form. Sources: screenshot host, PR #72 workflow.

I. Durability was added after a preventable loss

The original Android upload key was created in a disposable worktree and lost when that tree was removed. The recovery and custody documents describe the reset and preservation work. The 2 September custody inventory still records a single-machine backup risk; I did not independently establish the current off-machine backup state.

Change: use managed secret custody, an encrypted off-machine backup and tested restoration, and durable object storage for source-bound release artifacts and evidence. Worktrees and temporary CI artifacts are execution space, not custody. A signed app and its future updates must remain recoverable after losing any one worker or machine. Sources: key incident, custody inventory.

J. Product polish and infrastructure variety can hide a lack of progress

We now have several polished utilities, multiple preview routes, custom store automation, a local Mac path, hosted CI, and EAS. These solve real problems, but each introduces maintenance. A branded loader and four screens do not establish sufficient utility or differentiation. The factory should be measured by accepted, installable, useful releases and their economics—not screen count, app count, commits, or agent activity.

Change: preserve proven components, retire duplicate paths after replacement is proven, and make every new infrastructure task identify the specific release blocker or customer outcome it removes.

5. Current platform capabilities change the proposed solution

Some older assumptions should be corrected before writing more browser automation.

I additionally fetched Google's public discovery document, revision 20260902, and verified that release summaries and Data Safety appear in its schema. This is current documentation/schema evidence, not proof that our account has the credentials and grants to call them. The release-summary method returns up to 20 non-obsolete releases; persist observations rather than assuming it is a complete historical audit log. Method contract

Do not confuse customer review APIs with platform reviewers' rejection explanations. Apple status notifications and Google's release summaries tell us that something changed. Full reasons, attachments, console-only setup, and some reviewer correspondence still require verified additional access. Build a tested capability matrix for our accounts. Use browser automation only for remaining authorized UI operations; authenticated official documentation does not imply a universal API for every console action.

6. Can this run with absolutely no humans?

Routine product execution can be designed to run unattended. A promise of zero human involvement across every account event, legal change, review dispute, and future platform change would be dishonest.

Apple assigns legal agreement acceptance and some account changes to the Account Holder, and updated agreements can block access. This is an accountable organizational role, not another code-generation task. An employee with the appropriate authority can reduce founder involvement, but that is still human involvement. Apple roles, agreement requirements

Google's 12-testers-for-14-days requirement applies to personal accounts created after 13 November 2023; it is not a universal requirement to impose on every organization account. The repository historically records organization accounts, but eligibility and verification should be freshly checked. Genuine required testing cannot be replaced by a fabricated tester count. Google testing requirements

The repository also records an Apple distribution constraint associated with its prior DSA declaration. Revalidate the actual account status and intended territories before using that account for a commercial portfolio; do not blindly inherit old account declarations. Apple DSA guidance

The useful operating contract is:

• Account foundation: verified ownership/authority, roles, agreements, payments, territory policy, recovery, and initial credential setup.
• Unattended ordinary work: research, selection within policy, implementation, tests, artifact generation, eligible merges, store setup where automatable, submission, observation, ordinary repairs, and resubmission.
• Explicit exceptions: identity verification, legal acceptance, lost access, ambiguous policy/account action, or a new platform requirement the automation cannot truthfully satisfy. The affected lane pauses with evidence; unrelated work continues.

If “no human under any circumstances” is non-negotiable, the system must sometimes stop or abandon a candidate. Count those as failures to achieve publication, not as successful autonomous runs. Money can fund reliability and expertise; it cannot guarantee discretionary approval by two independent platforms.

The account-separation work also needs the right rationale. Use legitimate, controlled publisher identities and least-privilege credentials. Stable networking can be an operational requirement. Preventing platforms from associating publishers is not a substitute for truthful ownership or a durable business model. Do not build the scaling strategy around account replacement or concealment.

7. The operating architecture I recommend

Use one production system with explicit contracts, while keeping specialized workers replaceable. Start by repairing ship-game around one release; do not delay the first proof for a wholesale rewrite. For the longer-lived coordinator, prefer a managed durable-workflow service, with Temporal as the first candidate to evaluate. Its persistence helps with multi-day waits and process recovery; external store operations still require idempotency and reconciliation. Temporal documentation

flowchart TD
  Sources[Both stores, licensed data, customer evidence] --> Opportunity[Opportunity dossier and evidence gates]
  Opportunity --> Decision{Portfolio policy}
  Decision -->|Insufficient evidence| Retire[Reject or gather more evidence]
  Decision -->|Eligible| Product[Product specification and acceptance scenarios]
  Product --> Build[Source, review, protected merge, signed artifacts]
  Build --> Android[Android QA and Play submission]
  Build --> Apple[iPhone QA and Apple submission]
  Android --> Observe[Independent store observers]
  Apple --> Observe
  Observe -->|Actionable failure| Repair[Reproduce, patch, test, new release attempt]
  Repair --> Build
  Observe -->|Public and installable| Outcomes[Acquisition, use, payments, support]
  Outcomes --> Opportunity
  Observe -->|Account or legal exception| Exception[Evidence-backed exception queue]

The durable records should include:

Workers propose work; validators establish facts; the coordinator advances state. External messages are untrusted inputs, not instructions to change account permissions, reveal secrets, or bypass checks. Give code workers no production signing credentials, and give release workers only the privileges needed for identified artifacts.

Submissions need a lock per app/store and a persisted intent before execution. After a timeout, read the platform before repeating the action. Handle duplicate webhooks, delayed events, concurrent metadata changes, and worker death explicitly. A retry counter is not an idempotency strategy.

Standardize selectively. Keep the existing React Native apps long enough to finish the pilot. Evaluate Expo/EAS as the default for new compatible products, with one documented exception path for native capabilities it cannot satisfy. Do not silently send the newer Expo app through legacy scaffolding hard-coded to React Native 0.76.9. Preserve existing signing identities and package IDs through any migration.

8. A better niche-selection and learning process

1. Collect from multiple directions. Keep prefix discovery, add independent App Store research, licensed competitor/rank history, review complaints, and evidence of existing workflows. Treat unsupported countries, stale observations, missing metrics, and vendor floors as unknowns—not zero demand.
2. Cluster by user task. “Tyre comparison” and “tire comparison” may be one opportunity; different professions using the same calculator may be distinct if the workflow and value differ. Inspect functionality, not just titles.
3. Require a differentiated product thesis. State who benefits, why the existing options fail, and the specific behavior our app does better. Validate that thesis against actual competing products or reliable demonstrations.
4. Measure intent before expensive expansion. Run truthful landing-page or prototype experiments with identifiable audiences. A click measures interest, not willingness to pay. Paid acquisition for a live pilot provides a distribution experiment, not proof of organic search demand. Keep those cohorts separate.
5. Model contribution, including upkeep. Estimate a range for revenue net of platform/payment costs, refunds, acquisition, support, infrastructure, and maintenance. Include review failure and account concentration risk. Measure actual cash outcomes once available.
6. Learn from failures as well as winners. Persist abandoned candidates, insufficient demand, rejections, repair costs, and unprofitable apps. Otherwise the next ranker learns only from survivors.

With money available, buy data access and test its incremental value instead of continuing an ideological argument about subscriptions. AppTweak is a sensible first integration candidate because its current documentation separates its modeled volume from Apple's raw search popularity and provides history. Its revenue estimates also have coverage limits; apparent zeros outside covered chart positions are not proof of no revenue. Keyword methodology, app metric limitations

Run a paid-data pilot on roughly 100 shortlisted concept/territory combinations plus controls. Measure coverage, freshness, repeatability, and whether decisions improve against later real outcomes. Buy a second source if it tests a meaningful disagreement. Do not call correlated vendor estimates independent confirmation. Version metric definitions: AppTweak's current changelog itself notes a Google acquisition-reporting comparability issue. API changelog

The correct business objective is approximately:

expected portfolio contribution = probability of approval and adoption × net contribution if successful − validation/build cost − expected ongoing failure and maintenance cost

Use ranges and observed cohorts, not invented precision. For a daily habit app, week-to-week use matters. For a tire calculator, completing the occasional task and converting when needed may matter more than daily retention. A generic D7 benchmark should not select the product strategy.

9. Avoid turning micro-niches into store spam

A narrow audience can justify an app. A separate binary for every keyword spelling, location, or cosmetic variant often cannot.

Apple's minimum-functionality and spam provisions require meaningful utility and differentiation; its template-service rule is not a blanket prohibition on AI-written code. Google likewise rejects repetitive experiences and suggests aggregation where small apps are highly similar. Product-specific artwork does not cure interchangeable functionality. Apple review guidelines, sections 4.2–4.3, Google repetitive-content policy

Make portfolio similarity a release gate. Where several discovered needs belong to the same audience and workflow, prefer one stronger product with relevant localization and positioning. Separate products need a defensible user or domain distinction. Keep truthful support pages and privacy statements because customers need them; removing “factory” branding from a URL is not evidence of policy compliance.

For the initial unattended portfolio, choose simple, useful domains with manageable policy exposure. Do not optimize purely for “fewest features”; optimize for the smallest product that fully solves the task. Add regulated claims, children, social/UGC, or complex financial features only when the corresponding expertise and operational controls exist.

10. What to implement, in order

The following timing is a planning proposal after staffing and account access are available. Store review and verification dates remain outside our control.

Launch Lantern should remain a useful integration/QA fixture until independent customer evidence justifies treating it as a business. Do not publish deliberately weak or broken apps merely to provoke reviewer feedback for testing.

Specific engineering tickets the audit supports

11. What I would fund, and what I would stop funding

For a focused 90-day effort, staff one accountable technical/product lead, two mobile/release engineers, one workflow/integration engineer, one QA automation engineer, and one growth/data operator, with fractional design and platform-policy/account expertise. Their job is to build an unattended production system; permanent people clicking through every app would not meet the automation objective.

As an allocation example, not a vendor quote: six specialists × three months × $20,000 fully loaded is $360,000. Add $60,000 for data, managed infrastructure, device testing, recovery, and specialist help, plus $30,000 of bounded acquisition experiments: $450,000 over 90 days. Adjust for actual staffing and quotes. Spend more if it shortens a demonstrated bottleneck; spending more on unvalidated app volume will mainly increase maintenance and account exposure.

The repository does not provide a consolidated spend or revenue ledger, so this audit cannot honestly give historical cash burn, cost per published app, or return on investment. Start recording those now, including agent usage, failed jobs, manual exception time, and maintenance—not just cloud invoices.

12. The proof required before calling it end-to-end

The acceptance demonstration must cover the whole requested chain:

1. Discover and select: a freshly evaluated opportunity from both-store research is chosen automatically under standing policy, with raw evidence and rejection reasons for alternatives.
2. Create: a clean worker produces the niche-specific product, source, assets, support/privacy pages, metadata, and executable acceptance scenarios.
3. Build and verify: both platforms build from identified source; real interactions, persistence, release identity, and required declarations pass independent checks.
4. Submit: the system provisions the supported per-app records, fills remaining authorized setup, uploads, selects the intended build, and submits both store versions without ordinary human intervention.
5. Wait and reconcile: restarting workers during a multi-day review neither loses progress nor causes duplicate submissions. Pending review stays pending.
6. Repair: an authentic platform or user issue is ingested, reproduced where applicable, fixed, verified, and followed through a new release attempt. Use recorded incidents and injected local failures to test this before a natural live incident occurs; do not claim a replay proves live reviewer correspondence or acceptance.
7. Verify publication: exact intended versions are available to eligible users in the intended territories and are installed and exercised through both store distribution routes. A development APK, TestFlight upload, pre-order, or draft does not satisfy this step.
8. Learn and maintain: gather acquisition, usage appropriate to the task, health, payments where applicable, and support outcomes; automatically choose an improvement, another opportunity, or termination. Continue monitoring each platform independently.

Before scaling, require one complete pilot, three consecutive routine update cycles without per-release operator actions, and evidence that the next product can be selected and delivered through the same mechanism. These are proposed reliability gates, not achievements already made. A finite demonstration still does not establish immunity to future legal/account exceptions.

Track elapsed time to public availability, active engineering time versus platform waiting, unattended completion rate, human minutes per release, first-pass review results, recurrence of rejection causes, source-to-artifact mismatches, crash/ANR trends, task completion, payment conversion, and contribution after support and maintenance. At low volumes, show denominators and uncertainty rather than impressive percentages.

The central management decision is to make one verified release-and-improvement loop the unit of progress. The existing work can support that. What it cannot support yet is a claim that producing more apps will automatically produce an autonomous, profitable business.

Audit validation and limits

I reran the relevant local checks on the audited worktree:

232 tests passed. These are local module/fixture tests, not proof of a live autonomous publication. The wrong-version and pre-order behaviors were separately reproduced with clearly labeled offline responses. No app source changed, so this audit did not rebuild every native app or repeat Android/iPhone screenshot passes.

Report-local links and evidence JSON were validated. The repository secret audit scanned the current included text files, 2,984 historical blobs, and canonical key-directory metadata. It found no matches in the current worktree, including these deliverables. Its overall exit status was nonzero because two historical unit-test proxy URLs match its credential-URL rule; inspection confirmed reserved test hostnames in a pure proxy-validation test. These inherited findings were recorded rather than suppressed. No private key contents were read for that directory check.

GitHub API observations verify specific external jobs and available artifacts. Stored runtime upload receipts and historical console captures are weaker than a new authenticated store read. Current store credentials/grants, complete rejection correspondence access, all-territory availability, backup restoration, real customer outcomes, and the account's present legal/monetization readiness remain unverified where explicitly described above. They are implementation acceptance work, not facts to assume away.