What Reading.com Learned Testing Prices and Funnels — Tim Dikun, Teaching.com

Launched at $6.99/month without much research. As soon as RevenueCat Experiments came out, tested many monthly prices from $4.99 up to $19.99. $12.49 had the highest LTV lift; $14.99 was slightly higher but they chose $12.49 to keep reach broad because parent-to-parent word of mouth matters in kids apps. Ran look-backs over multiple years: some higher prices gave an early LTV boost that did not hold.

A/B test: control had monthly with a trial and annual (~50% off) with a trial; test cell had annual with a trial and monthly with no trial.

On all web funnels (not in the app), no free trial: users pay upfront with a prominent 30-day money-back guarantee. Paid ads, mostly Meta, then optimize on purchases rather than trial starts, so every conversion sent back to the ad network is a high-intent buyer.

Campaigns are separated by attribution method (scan campaigns, 'pre-lander' campaigns, web funnel campaigns). Within web funnel campaigns, each ad set points to a distinct funnel (with or without trial, different experiments running at different times).

To test if web purchase was viable at all, the existing in-app onboarding was replicated one-to-one as a web funnel and some paid traffic was sent to it.

Intentionally invested in category domains (Reading.com, Typing.com, and Flashcards.com for a future product), first for SEO value, second for instant brand trust in web funnels. Data shows people who see ads later go straight to the website instead of clicking.

Based on reading research (children must be directly instructed), every lesson requires a parent next to the child giving feedback. Committed not to add AI pronunciation feedback even when it becomes good enough, keeping parent involvement as a core value.

Onboarding includes slides hinting at why parent involvement matters; inside the app, parent-focused content explains how the program works and why the parent must be involved.

Printables (coloring sheets, small board games, each tied to a reading skill) are included in the subscription but unlocked lesson by lesson. After a user buys or starts a trial on the web, offer $9.99 to get all PDFs at once, delivered as a link to a Google Drive folder.

Users asked for physical versions of the in-app books so kids could reread without screen time. Plan to sell book sets on Amazon within 6-8 weeks, both as an LTV boost for subscribers and as lead gen for the app from people shopping for early readers.

Because kids graduate out of the app once they can read, plan to extend the curriculum from early second grade to early third grade, and build a suite of apps under the Reading.com umbrella for later stages (comprehension, even adult speed reading).

Users who read a first storybook retain far better, but the first book comes at lesson 10. Working on a book-like experience early, ideally in lesson 1, so parents see what their child will be able to do.

Apple's kids-app rules block third-party analytics and attribution SDKs (Amplitude, Google Analytics). Built an in-house first-party analytics tool, cleaned and anonymized the data, then forwarded it to Amplitude.

After in-house generalist marketing hires didn't work, contract one expert per channel: Meta ads, Google ads, Apple Search Ads, lifecycle marketing. Started with consultant Sylvain (Growth Gems), introduced by RevenueCat, who brought in other experts. Contractors sit in Basecamp and post a weekly report with numbers; the COO and founder review them weekly and decide what to change.

Basecamp for almost everything, with all notifications disabled at onboarding so people check it between blocks of deep work. Free Slack (90-day history) with notifications on, reserved strictly for urgent unblocking; policed heavily.

Tried Scrum early in scaling engineering (product owner training, a Scrum master). It turned creative engineers into ticket takers, so it was dropped. Now developers can challenge designs while building; 11th-hour changes are encouraged and months of work are not shipped if not right. Hire 'product developers' over pure software engineers.