What exists, and what is still planned
The original Apple $100 promotional application is confirmed, but native balance, expiry, cash exposure and fees/taxes are unverified. The private R2 preparation proposal is $20 first, $50 only after review, and $30 reserve; it is not active, native-saved, or spending authority. Historic budget proposals below are dated history, not current policy.
| Work | Observed state / next step |
|---|---|
| Review gallery and short cuts | Four exact records retain chat approval: parent beta, parent GA, beta narration v3 and GA narration v2. The current exact cuts—cartoon beta v4, brown-father beta v3 and adult beta v4—are revision required. Approval remains limited to each recorded scope; QA, parity, release and destination gates remain open. Hosting does not authorize social placement, GA or paid activation. |
| Current wake-check reviews | Parent beta and parent GA retain their exact approvals; human listening, motion, caption and word-alignment QA remain open. GA also needs live iPhone-store and destination proof. Older cartoon cuts are revision-reference history. The current revision-required cuts are cartoon beta v4, brown-father beta v3 and adult beta v4. |
| Longer feature film | The full feature film remains unfinished. Beta narration v3 and GA narration v2 have exact chat approval for voice and wording in future film assembly only. Current-build footage, runtime proof, final assembly, human QA and fresh exact review remain required; GA is not verified live. |
| Customer route | The customer-page review preview exists. Its layout passed a 390px mobile check with no horizontal overflow. Release/runtime checks and the longer genuine-app feature film remain open; this does not establish full launch readiness. |
| Beta and organic distribution | An existing Facebook beta post was refreshed with the full alarms, reminders, wake-check, sync and two-route explanation; no boost was enabled. The older TikTok post is Only me. The newer pinned dual-beta card is public but has no description, so its printed routes are not claimed clickable. YouTube profile links to iPhone TestFlight and Android Google Group signup are clickable; three older July Shorts are Unlisted. A join, follower or view does not prove a completed two-phone test. |
| Branding refresh | Facebook, Instagram and YouTube now use blue/yellow avatars. TikTok’s owned-brand avatar is unverified because the current session was not confirmed as the owned account. No audience-growth result is inferred. |
| Reports and alerts | The tracking page contains dated manual snapshots. Two new exact adult-review emails were confirmed SENT; delivery/read status remains unknown. Comment-email notification delivery remains unverified. No live ad API, automatic optimizer or conversion feed is claimed. |
| Release and paid activation | The exact iOS GA listing v2 is approved via chat for wording only and further release-evidence review; it is not an App Store Connect entry, submission or GA authorization. Historical Build 19 testing, the October 8 TestFlight 21 internal/Ready to Submit observation, and public-link accounts on Build 20 are not current release evidence. At Oct 10, 14:09:16–22 UTC, official API fields verify Build 23 VALID and IN_BETA_TESTING internally. The selected enabled external public group is configured for external testing; its latest known active Build 20 is VALID and IN_BETA_TESTING externally. Its public link has an enabled configured limit of 20 and 3 group-linked records, which do not establish public-link usage, remaining slots, installs, families, active users or device behavior. Build 23 is not claimed publicly available. The public US App Store listing was rechecked on Oct 9 and still showed 1.0.3. GA and feature parity remain unverified. Meta’s owned-page Ad Center showed an empty first-ad state; Apple Ads redirected to sign-in, so neither account’s controls were fully reviewed. No campaign is active. Actual spend, outstanding exposure and revenue are UNKNOWN without billing reconciliation. |
| Android beta route | At 19:51 UTC on October 1, the Android Google Group had one member (the owner) and no pending members: zero external Android signups were confirmed then. At 13:07 UTC on October 2, the Play dashboard for com.momclock.momalarmclock showed 1 tester currently opted in and an installed audience of 0. At 13:09 UTC, the Google Group had 2 members including the owner and 0 pending members. These are distinct delayed measures; neither count establishes an acquisition, install, working two-phone functionality, or 12 concurrent opted-in testers for 14 days. On each Android phone, join the Group first, then opt into Play testing with that phone’s selected Play Store account; both links are live but account-specific. The Reddit profile’s Android/iPhone beta links and 0 followers were an initial observation, not growth. |
| Approval workflow | The public review desk presents exact review records and read-only history. Copy-to-chat is manual: Rob must paste the copied packet into the Mom Alarm marketing chat; copying does not submit or record a decision. New exact media and paid settings retain separate review requirements. |
Still open: genuine current-app/calendar footage and runtime capture; human listening, motion, caption and word-alignment QA; revisions and fresh exact review for the three revision-required beta cuts; comment-email delivery testing; community moderation; GA/live-store proof; and native paid-account controls. No further beta-video production or beta-video spend is planned while GA video work continues. Common Sense Media is only followed by Mom Alarm; no recruitment, collaboration or tester attribution is evidenced. New review hosting is separate from organic publication.
Historical iPhone beta observation: at 00:56 UTC on October 1, build 2.0.1 (18) was in external Testing, the public TestFlight link showed 1 of 20 joins, and the campaign group showed 2 total testers. This did not establish a completed two-phone test, runtime feature proof or GA release. A 2026-10-01 18:08 UTC upload-date inventory found build 2.0.1 (18) latest uploaded; a separate 18:23:19 UTC group readback found build 18 offered, with the public link, 20-person cap and feedback enabled; builds (17), (15) and (14) were also associated, and PUBLIC_LINK/INSTALLED and EMAIL/INSTALLED were each 1. Apple’s Sep 1–Oct 1 public-link report showed 7 views and 3 accepted invitations. Those interval counts do not prove current installed testers, unique households, individual installed builds, remaining capacity, completed tests or per-social attribution. A 16:58 UTC app-wide feedback read found 162 screenshot submissions and no submitted crash feedback. A later exact-build filter found one screenshot-feedback submission for 2.0.1 (18), created September 30 at 13:08 UTC; it was privately triaged as a UX-state clarity concern; engineering reproduction remains pending. The cap remains 20; any expansion to 50 and then 100 requires a filled cohort, healthy feedback and capacity. This is a dated review plan, not a live reporting integration or promised release date.
Proposed Founding 500 offer
The recommendation is to qualify the first 500 unique parent-owned family accounts that complete an eligible claim, rather than the first 500 downloads. The proposed benefit is the verified launch feature list free for the life of the app service, subject to exact published terms. Beta signups and Android Google Group signups alone do not reserve a Founding 500 spot.
Before any public claim, the team must freeze and verify the included feature list; build a server-atomic, one-per-family cap with an auditable claimed and remaining ledger; and prove Apple- and Google-store-compatible entitlement and restoration paths. A live remaining count must be truthful and come from that ledger. The exact Apple product, offer-code setup and review status still need validation; see Apple’s App Review Guidelines §3.1.1 and offer-code help.
The offer could help create early traction, while reducing later paid-conversion opportunity among qualifying families. That tradeoff needs measurement after a verified implementation; this page makes no performance prediction.
Before launch
- Verify a family can complete setup. Engineering must reproduce and resolve material pairing or alarm-creation problems with evidence. Confirm installation, pairing, parent alarm delivery, child wake-up check and the result recorded on the parent phone. Test reminder scheduling and the child/parent update separately.
- Capture the release that will be advertised. Record the exact version/build and matching screens. Give alarms and reminders equal useful examples, such as a morning alarm and taking out the trash or walking the dog. A recorded check or mark does not prove physical wakefulness or a chore being done.
- Finish and review the creative. Complete human listening, motion, caption and word-alignment QA plus current-build parity for the exact approved parent beta and GA cuts. Rework the GA cartoon story and obtain fresh exact review. Separately assemble and review the longer genuine-app film with release-matched footage, readable captions, both alarm and reminder benefits, and parent status qualified by synchronization. Historical clips are references only.
- Prove the destination and reporting. Check the store page, customer route, links and platform previews on a phone. Record report access and attribution definitions. Trial, paid conversion, revenue or refund values remain unknown when their sources show insufficient data.
- Prepare the exact paid setup while paused. Verify advertiser identity, country/device targeting, account currency/time zone, end date, native spending limits, fees and billing exposure. Keep the first test blocked if its released envelope or the overall ceiling cannot be contained when the operator is offline.
Free, accurate beta text and suitable community participation are authorized. Keep beta feedback in TestFlight’s screenshot/reporting flow, use demo details and avoid duplicate promotional posts. New media needs its exact review.
GA day: verify first, then release the reviewed work
- Open the live App Store destination and confirm the released version and advertised alarm/reminder behavior. Recheck the family setup path and customer links.
- Publish only the exact approved creative and placement. Update availability wording to what the store actually shows. Keep optional social follows separate from the primary product destination.
- If every activation condition passes, start up to $50 of funded tests with verified native limits. Check early delivery, destination and reporting; leave any unsupported experiment off.
- Record launch time, time zone, native campaign IDs, exact asset version, released amount and the first reporting window. Give delayed conversion reports time to settle before comparing outcomes.
Daily operations after launch
Listen and keep routes working
- Check native comments, relevant messages, community moderation and TestFlight feedback. Respond helpfully from the owned brand identity.
- Check destinations, current beta build availability and release wording. Confirm actual tester updates and completed tests separately from enrollment.
- Record actionable problems, responsible owner and verification status. Keep private family and tester details out of public reports.
Reconcile before adjusting
- Pull dated platform/store reports and separate reported spend from billing, fees, refunds and charges still pending.
- Compare equivalent reporting windows and account time zones. Record unknown values and reporting delays.
- Once tests are approved and active, Codex may adjust approved creative, search terms and placements within released channel and total caps. Log each change and next review; do not chase every small fluctuation.
| Channel | Useful work and current limits |
|---|---|
| Keep the featured invitation clear; check community moderation and answer caregiver questions. A submitted invitation is not a public post until approved. | |
| Maintain the correct profile destination and invitation; inspect native reach and replies. The checked desktop menus did not offer pinning. | |
| TikTok | Monitor the creator clarification and verify caption-edit eligibility. The original caption correction is unresolved; do not assume an attempted save persisted. |
| YouTube | The TestFlight profile link works. Monitor the Community invitation and comments; advanced description-link access still has an owner verification dependency. |
| X | Keep the invitation pinned, use specific caregiver questions and answer real replies. Views and outgoing follows are not incoming followers or attributed installs. |
Scheduled checks support this work; they do not guarantee real-time notification or every comment’s delivery. Keep native/manual checks until alert delivery is verified. No mass follows, repeated promotional comments, copied outreach or rating incentives.
Weekly decisions
- Report what changed, actual spend and available outcomes, with source, period, sample size and uncertainty. Separate organic reach, store downloads, activation, paid conversions and revenue.
- Review one controlled comparison at a time using approved variants that each include alarms and reminders. Compare a specific hook, format or placement with a comparable destination and audience; a newly made exact variant needs its own review.
- Keep, fix or stop an experiment using credible evidence. Weak clicks, downloads or family setup suggest different investigations, not automatic causal conclusions.
- Release small additional amounts only for a justified test or credible performer within the approved policy. New unapproved creative, platforms, increased caps or changed activation scope need review. Money may remain unspent.
Paid preparation only — no authorized activation
The table below records a historical proposal, superseded by the October 7 FREE_ONLY decision. Its amounts are inactive and cannot be funded or released. Current R2 credit planning is preparation only and supplies no spending authority.
| Stage | Release condition | Envelope |
|---|---|---|
| Initial checks | Historical inactive proposal: Apple $25 and Meta $25. FREE_ONLY supersedes this allocation; no funded experiments are authorized. | No current authorization |
| One controlled comparison | Historical inactive stage. Superseded by FREE_ONLY; no amount is released or releasable. | Historical $100 more |
| Reserve | Historical inactive stage. Superseded by FREE_ONLY; no reserve is current or releasable. | Historical $350 |
| Total | All platforms and stages combined. Actual native limits, currency, fees and billing exposure must be verified before release. | No current paid cap released |
Actual ad spend and outstanding exposure: UNKNOWN. No reconciled billing, fee total or refund report is available in this record. An empty ledger does not establish zero. FREE_ONLY authorizes no new spending; the historical ceiling is inactive.
Native controls must contain spend if Codex, the browser or a scheduled check is offline. Apple daily budgets are monthly averages and can be exceeded on an individual day; with an end date, Apple documents a maximum based on days times daily budget. Verify time zone, end date and this math for the actual account. A budget order is only available to invoiced Apple Ads Advanced customers and cannot start the day it is created; do not assume one is available. A daily budget alone is not a hard daily cap; periodic polling is not sufficient containment.
Apple Search Results uses approved App Store product-page assets. Meta clicks are not installs; campaign-link first-time downloads can be reported only if the actual source is available. TikTok, YouTube/Google and X paid tests are not initially funded.
A ledger with sources, not estimates presented as results
Open daily downloads, spend and work status. It is a dated manual reporting page. The schema below describes the required records; it does not populate fictional campaign results.
| Fields | How to record them |
|---|---|
| Identity and period | Platform, native campaign ID/name, creative version/hash, reporting date/window, account time zone, pull timestamp, report source and attribution window. |
| Currency and limits | Account/report/billing currency, any stated conversion source/date, released stage amount, native limits and end date. Do not add unlike currencies without a documented conversion. |
| Reported versus billed | Platform-reported accrued ad spend, billed/settled ad charges, applicable taxes/fees, refunds or credits with status, and possible pending charges. Reconcile overlap; do not count the same charge twice or assume a refund has settled. |
| Cumulative and remaining | Cumulative reconciled exposure across all active tests, outstanding exposure not already counted, reserved billing headroom and remaining released allowance. Historical reserve values are inactive. Actual spend, exposure and revenue remain UNKNOWN without reconciliation. |
| Delivery and acquisition | Impressions/views, taps/clicks, source-reported new downloads and redownloads. Keep Apple Ads, campaign-link and organic counts separate; overlapping attribution is not unique customers. |
| Product and money outcomes | Successful family setup, retained use, trials, paid conversions, attributable revenue and refunds only when measured. Not Enough Data, dashes and missing access mean unknown, not zero. |
| Decision and follow-up | Previous/new setting, reason, evidence window, expected diagnostic result, owner, next review and pause status. Log adjustments even when within approved caps. |
Available room is the released allowance less reconciled charged/accrued exposure and additional outstanding exposure or fee headroom, without double counting. Use conservative headroom when billing is delayed. FREE_ONLY keeps activation blocked; the historical aggregate is inactive and not a current cap.
Cost per reported new download requires nonzero attributable downloads from the same source/window. Paid-customer cost and return on ad spend require attributable paid conversions and revenue. When downstream data is unavailable, findings stay provisional; no profitable scaling claim.