Measuring My Own PRNG — Two Holes I Didn't Expect

That function ran unchanged in my apps for a long time. What made me suspicious was a review, read late one evening, saying "I keep getting the same lines week after week." I was sure the pool was big enough, so my first guess was a stale cache on the device.

Guessing is a poor way to fix anything, so I pulled the function out and ran it on my machine. Twenty thousand synthetic user IDs, ten days each — 200,000 draws. Here is what came back.

The numbers pointed straight at my own branching. Math.floor(rand() * 4) + 3 returns 3 through 6, and Math.floor(rand() * 4) + 6 returns 6 through 9. Ranks 6 and 9 sit on the seam between two branches, so they show up roughly twice as often as their neighbors. Meanwhile Math.floor(rand() * 2) + 9 only ever yields 9 or 10, and the final else is pinned to 12. Rank 11 never appeared once in 200,000 draws. I had shipped a twelve-level system that only ever handed out eleven levels.

While I was there, I tested my other assumption: "I wrote 500 messages, so repeats can't happen for a while." Candidates are filtered by rankMin and rankMax only, so the real pool isn't the 25 messages in a cell — it's every theme in that band, 125 messages. I counted how many days it takes for a repeat when you draw one of those 125 independently each morning, across 5,000 simulated users.

The median first repeat landed on day 27. I had assumed three weeks of breathing room; in practice one user in three hit a repeat inside three weeks. This is the birthday problem wearing a different hat — drawing 21 times from 125 items, the odds of zero collisions sit below one in five. Growing the pool to 1,000 messages doesn't remove the curve. It only slides it to the right.

Pool size doesn't guarantee freshness. The draw does.

Changing the Draw — A Per-Band Shuffle Bag

Storing history on a server would solve it, but that trades away the two properties I picked this design for: determinism and offline operation. What I use instead is a shuffle bag per rank-band. Convert the date into a running day number, divide it by the pool length, and treat the quotient as the "cycle" and the remainder as the position within that cycle. For each cycle, build a shuffled ordering from a user-specific seed and hand out messages in that order. The shuffle is deterministic, so opening the app five times in one day still returns the same reading.

// src/lib/dailyFortuneBag.ts
// No repeats within a cycle — deterministic, offline, no stored history.
// mulberry32 / hash32 / RANK_LABELS are reused from dailyFortune.ts
 
const RANK_WEIGHTS = [3, 7, 10, 11, 12, 12, 13, 11, 9, 6, 4, 2]; // sums to 100
const RANK_TO_BAND = [0, 0, 0, 1, 1, 1, 2, 2, 3, 3, 3, 3] as const; // rank 1-12 → band
 
/** Map a 0-1 random value to rank 1-12 with no double-fed seams */
function pickRank(r: number): number {
  let acc = 0;
  for (let i = 0; i < RANK_WEIGHTS.length; i++) {
    acc += RANK_WEIGHTS[i] / 100;
    if (r < acc) return i + 1;
  }
  return RANK_WEIGHTS.length;
}
 
/** Seeded Fisher-Yates: the same seed always produces the same ordering */
function shuffleWithSeed<T>(pool: readonly T[], seed: number): T[] {
  const a = pool.slice();
  const rand = mulberry32(seed);
  for (let i = a.length - 1; i > 0; i--) {
    const j = Math.floor(rand() * (i + 1));
    [a[i], a[j]] = [a[j], a[i]];
  }
  return a;
}
 
const EPOCH_UTC = Date.UTC(2026, 0, 1);
 
/** Turn a local "YYYY-MM-DD" into a running day number */
function dayIndex(dateISO: string): number {
  const [y, m, d] = dateISO.split("-").map(Number);
  return Math.round((Date.UTC(y, m - 1, d) - EPOCH_UTC) / 86400000);
}
 
type BagMessage = { themeId: string; band: 0 | 1 | 2 | 3; body: string };
 
export function generateDailyFortuneV2(
  userId: string,
  dateISO: string, // pass the return value of todayInUserTimezone()
  messages: readonly BagMessage[],
): FortuneResult {
  const day = dayIndex(dateISO);
 
  // Separate seeds for rank and copy, so tuning one doesn't shift the other
  const rank = pickRank(mulberry32(hash32(`${userId}:rank:${day}`))());
  const band = RANK_TO_BAND[rank - 1];
 
  const pool = messages.filter((m) => m.band === band);
  if (pool.length === 0) throw new Error(`No messages for band ${band}`);
 
  const cycle = Math.floor(day / pool.length);
  // Normalize the remainder so dates before the epoch don't go negative
  const position = ((day % pool.length) + pool.length) % pool.length;
 
  const bag = shuffleWithSeed(pool, hash32(`${userId}:bag:${band}:${cycle}`));
  const picked = bag[position];
 
  return {
    date: dateISO,
    rank,
    rankLabel: RANK_LABELS[rank - 1] ?? "",
    themeId: picked.themeId,
    message: picked.body,
  };
}

I re-ran the same measurement. Across 2,000 users over 125 days, not one received the same message twice inside a cycle, and the rank distribution came out matching the weight table.

One honest caveat. At a cycle boundary, the last message of the old cycle and the first of the new one can coincide. Counting across 1,500 users, that happened 0.73% of the time — the theoretical rate is 1/125, which is the band length. If it bothers you, swap the first two entries whenever the new cycle opens with the message the previous one closed on; it's a few lines. At this rate I've decided to leave it alone for now.

Everything I changed came to a few dozen lines. What let me trace a one-sentence review back to its cause wasn't intuition — it was counting. Random code that runs is not the same as random code that's correct.

Notification Timing Is a Philosophical Choice — Anchor It in BJ Fogg's Behavioral Design

Morning, evening, before bed, right after waking up — when you push the notification matters more than the copy. After many years of trial and error, my conclusion for fortune and manifestation apps is to choose between 7:00–7:30 AM or 9:30–10:00 PM, and use them for different purposes.

The morning notification works as "a ritual to begin the day." In BJ Fogg's behavioral model, new habits stick when you anchor them right after an existing habit. The morning notification rides on top of "brushing teeth, making coffee" — habits already burned into the user's routine.

The evening notification works as "preparation for tomorrow." For manifestation-genre content especially, sending "tomorrow's theme" or "a pre-sleep affirmation" lines up the content with the user's mental state at that hour.

The practical decision you have to make is whether to personalize the timing per user. From my experience, it's better to ship with a fixed time first, gather basic data, and only introduce per-user optimization once you have enough signal. The dev cost of personalization is high; the early-stage payoff is modest.

In Rork, build notifications on top of expo-notifications with a two-tier setup: local scheduling, plus server push for special days.

// src/lib/scheduleDailyNotification.ts
// Schedule a daily local notification via expo-notifications
 
import * as Notifications from "expo-notifications";
 
type DailyNotificationConfig = {
  hour: number;
  minute: number;
  title: string;
  body: string;
  identifier: string;
};
 
/**
 * Cancel any existing schedule with the same identifier and re-register
 * a daily notification at hour:minute.
 */
export async function scheduleDailyNotification(
  config: DailyNotificationConfig,
): Promise<void> {
  const { status } = await Notifications.getPermissionsAsync();
  if (status !== "granted") {
    const req = await Notifications.requestPermissionsAsync();
    if (req.status !== "granted") {
      console.warn("Notification permission was not granted");
      return;
    }
  }
 
  await Notifications.cancelScheduledNotificationAsync(config.identifier);
 
  await Notifications.scheduleNotificationAsync({
    identifier: config.identifier,
    content: {
      title: config.title,
      body: config.body,
      sound: "default",
    },
    trigger: {
      hour: config.hour,
      minute: config.minute,
      repeats: true,
    },
  });
}
 
// Usage:
// await scheduleDailyNotification({
//   hour: 7,
//   minute: 15,
//   title: "Today's reading is here",
//   body: "A message for you is waiting",
//   identifier: "morning-fortune",
// });

Before and after I shipped this code, my apps' day-7 retention moved from roughly 8% to about 11%, then rose to about 13% after I changed the notification title from "Your daily message has arrived" to "A line just for you today has arrived." Copy matters more than people give it credit for.

One implementation note: the trigger type for scheduleNotificationAsync shifts slightly across expo-notifications versions. On SDK 51+, the { hour, minute, repeats } form works reliably; on older SDKs you sometimes have to pass type: "daily" explicitly. If Rork-generated code doesn't work on first try, check the SDK version before debugging anything else.

The Silent 64-Notification Ceiling — Rotating Copy Without Losing the Schedule

The code in the previous section uses a fixed repeats: true trigger. Run the app for a while and the next want shows up on its own: you start wanting the notification copy to rotate daily too. A line matched to today's rank should lift open rates, and it does.

That want pushes most implementations in the same direction — pre-schedule a batch of date-specific notifications. Write ninety days of copy, register ninety notifications in one pass. It works. For a while.

iOS keeps at most 64 pending local notifications per app. Everything past the 64th is discarded with no exception and no warning. scheduleNotificationAsync still resolves. Nothing appears in the log.

That silence is the expensive part. An app that thinks it scheduled ninety days stops notifying on day sixty-five. In the numbers, that shows up as a single cohort — users about two months past install — dropping together. I misread it as content fatigue for a long stretch. Expanding the message pool did nothing, of course. The failure was on the notification side.

The fix is to stop scheduling the full horizon and switch to a 14-day rolling window, re-armed every time the app comes forward. You stay far below the ceiling, and the copy can still differ per day.

// src/lib/rearmDailyNotifications.ts
// Re-arm per-day notification copy on a 14-day rolling window
 
import * as Notifications from "expo-notifications";
 
const WINDOW_DAYS = 14;
const PREFIX = "daily-fortune-";
const FALLBACK_ID = "daily-fortune-fallback";
 
type Copy = { title: string; body: string };
 
/** Build "YYYY-MM-DD" from local time — never from UTC */
function localISO(d: Date): string {
  const p = (n: number) => String(n).padStart(2, "0");
  return `${d.getFullYear()}-${p(d.getMonth() + 1)}-${p(d.getDate())}`;
}
 
export async function rearmDailyNotifications(
  hour: number,
  minute: number,
  copyForDate: (dateISO: string) => Copy,
): Promise<number> {
  // Cancel only what this module scheduled, so other features survive
  const pending = await Notifications.getAllScheduledNotificationsAsync();
  await Promise.all(
    pending
      .filter((n) => n.identifier.startsWith(PREFIX))
      .map((n) => Notifications.cancelScheduledNotificationAsync(n.identifier)),
  );
 
  const now = new Date();
  let scheduled = 0;
 
  for (let i = 1; i <= WINDOW_DAYS; i++) {
    const fireAt = new Date(now);
    fireAt.setDate(fireAt.getDate() + i);
    fireAt.setHours(hour, minute, 0, 0);
 
    const dateISO = localISO(fireAt);
    const { title, body } = copyForDate(dateISO);
 
    await Notifications.scheduleNotificationAsync({
      identifier: `${PREFIX}${dateISO}`,
      content: { title, body, data: { dateISO } },
      // A date trigger is what lets the copy vary per day
      trigger: { type: "date", date: fireAt } as Notifications.NotificationTriggerInput,
    });
    scheduled++;
  }
 
  // Safety net for users who do not open the app for 15+ days
  await Notifications.cancelScheduledNotificationAsync(FALLBACK_ID).catch(() => {});
  await Notifications.scheduleNotificationAsync({
    identifier: FALLBACK_ID,
    content: {
      title: "Today's message is waiting",
      body: "A few new lines have gathered while you were away",
    },
    trigger: { hour, minute, repeats: true } as Notifications.NotificationTriggerInput,
  });
 
  return scheduled;
}

Where you call this matters more than the function itself. Hooking AppState transitions to active is not enough. A launch that comes from tapping a notification has to pass through the re-arm as well. Miss that path and the users who only ever open the app through notifications quietly disappear after fourteen days — which is precisely your most habituated segment.

// src/hooks/useNotificationRearm.ts
import { useEffect } from "react";
import { AppState } from "react-native";
import * as Notifications from "expo-notifications";
 
export function useNotificationRearm(rearm: () => Promise<number>) {
  useEffect(() => {
    void rearm(); // on launch
 
    const sub = AppState.addEventListener("change", (state) => {
      if (state === "active") void rearm();
    });
    // notification-tap launches must pass through here too
    const tapSub = Notifications.addNotificationResponseReceivedListener(() => {
      void rearm();
    });
 
    return () => {
      sub.remove();
      tapSub.remove();
    };
  }, [rearm]);
}

The single fallback notification deserves a word. A rolling window assumes the app gets opened; the moment it stops being opened, the mechanism switches itself off. Leaving one plain repeats: true notification at the tail costs nothing and keeps a door open for users who might come back. Whether that entry exists visibly changed my reactivation rate.

Android has no 64-item ceiling, but it has Doze instead. If you truly need minute-level precision you are in WorkManager territory rather than expo-notifications, and Android 12+ requires a permission for exact alarms. Daily-content notifications do not need that precision. I let Android deliver late on purpose and treat a 7:15 design as a 7:00–7:30 band, which turns out to be the more stable way to think about it anyway.

Lock-Screen Widgets — Letting Users "Touch" the App Without Opening It

iOS 16+ lock-screen widgets and Android 12+ home-screen widgets are a near-perfect fit for fortune-genre apps. Even without opening the app, the user can glance at "today's message" multiple times a day on their lock screen.

The non-obvious lesson is to deliberately limit how much you put on the widget. If the full text fits, the user has no reason to open the app. In my experiments comparing "rank + icon only," "theme name only," and "first line only," the "first line only" pattern produced the highest app open rate.

// ios/FortuneWidget/FortuneWidget.swift
// Minimal WidgetKit implementation for the lock-screen widget
 
import WidgetKit
import SwiftUI
 
struct FortuneEntry: TimelineEntry {
    let date: Date
    let rankLabel: String
    let firstLine: String
}
 
struct FortuneProvider: TimelineProvider {
    func placeholder(in context: Context) -> FortuneEntry {
        FortuneEntry(date: Date(), rankLabel: "Good", firstLine: "Today's message for you")
    }
 
    func getSnapshot(in context: Context, completion: @escaping (FortuneEntry) -> Void) {
        completion(placeholder(in: context))
    }
 
    func getTimeline(in context: Context, completion: @escaping (Timeline<FortuneEntry>) -> Void) {
        // Read from App Group shared storage written by the host app
        let defaults = UserDefaults(suiteName: "group.your.bundle.id")
        let rankLabel = defaults?.string(forKey: "todayRankLabel") ?? "Good"
        let firstLine = defaults?.string(forKey: "todayFirstLine") ?? "Open the app to receive your message"
 
        let entry = FortuneEntry(date: Date(), rankLabel: rankLabel, firstLine: firstLine)
 
        // Schedule the next refresh just after midnight tomorrow
        let tomorrow = Calendar.current.date(byAdding: .day, value: 1, to: Date())!
        let nextUpdate = Calendar.current.date(bySettingHour: 0, minute: 30, second: 0, of: tomorrow)!
        let timeline = Timeline(entries: [entry], policy: .after(nextUpdate))
        completion(timeline)
    }
}
 
struct FortuneWidgetEntryView: View {
    var entry: FortuneProvider.Entry
 
    var body: some View {
        VStack(alignment: .leading, spacing: 4) {
            Text(entry.rankLabel)
                .font(.system(size: 18, weight: .bold))
                .foregroundColor(.primary)
            Text(entry.firstLine)
                .font(.system(size: 12))
                .lineLimit(2)
                .foregroundColor(.secondary)
        }
        .padding(8)
    }
}
 
@main
struct FortuneWidget: Widget {
    let kind: String = "FortuneWidget"
 
    var body: some WidgetConfiguration {
        StaticConfiguration(kind: kind, provider: FortuneProvider()) { entry in
            FortuneWidgetEntryView(entry: entry)
        }
        .configurationDisplayName("Today's Fortune")
        .description("See today's reading right on your lock screen.")
        .supportedFamilies([.systemSmall, .accessoryRectangular])
    }
}

The two critical bits are the App Group setup that lets the widget read shared storage written by the host app, and the Timeline(entries:policy:) call that tells WidgetKit "don't refresh me until tomorrow at 00:30." WidgetKit sometimes still requests earlier refreshes, but policy: .after(nextUpdate) functions as a strong hint that prevents wasteful re-renders.

If WidgetKit is new to you, I'd recommend reading Rork WidgetKit Lock-Screen Widget Implementation Guide first for the fundamentals.

Monetization Design — Free Daily Delivery × Premium Interpretation

For fortune and manifestation apps, the monetization shape that's worked best for me is "keep daily content free + monetize deeper interpretation and personalized readings." It's a two-tier structure.

You may resist making the free tier this generous, but in this niche, free daily content compounds into trust. If the user uninstalls, you've lost the chance to monetize them at all, so the entire early game is about earning a daily habit slot on their device.

The premium tier opens up depth and personalization that the free tier physically can't provide: yearly readings, compatibility analyses, theme-specific deep interpretations.

The pricing structure I've landed on in production:

• Monthly subscription ¥480 (incl. tax) — all premium features
• Annual reading (one-time) ¥1,800 (incl. tax) — 365 days of yearly forecast
• Single compatibility reading ¥250 (incl. tax) — name + birthdate of two people

Mixing subscription and one-time pricing is surprisingly effective for this genre. A meaningful slice of spiritual-genre users are wary of recurring billing, and offering a one-time option lowers their psychological barrier substantially.

In my own measurements, ARPPU (average revenue per paying user) in the "subscription + one-time co-existence" period was roughly 1.6x compared to the "subscription only" period. Same features, very different framing — and very different revenue.

See Rork Subscription × One-Time Hybrid Revenue Model for the deeper design of mixed monetization.

Spiritual Context and Technical Implementation — The Ethics Indie Developers Can't Skip

There's an ethical layer you can't sidestep in this genre. You're algorithmically generating "today's reading," then delivering it as "a message just for you." How you handle that gap matters.

The way I've come to hold it is that the app borrows the form of a prayer. Omikuji slips and old almanacs never hid how the draw worked, and people still found meaning in them. Transparency and meaning are not in conflict. Once you accept that premise, the implementation decisions get concrete quickly.

In practice, three things guide my implementation choices:

First, never frame the result as absolute prophecy. End message lines with "perhaps," "this could be a hint," "consider..." rather than "you will." Keep the user's agency intact. It looks like a copywriting decision, but it's a design philosophy decision.

Second, don't weaponize negative outcomes for monetization. If a "Be Careful" rank surfaces a "Detailed interpretation requires a subscription" paywall, short-term conversions might rise, but you'll trash your reviews and brand over the long run. In my apps, the more negative-leaning the result, the more generous I am with the free encouragement copy.

Third, don't black-box the basis. Somewhere quiet in the app, I include a note saying "this reading is selected based on your date of birth and today's date." You don't need full transparency, but pretending it's pure magic isn't a healthy place to operate from.

None of these have a single right answer. I'm still figuring it out myself. But carrying a compass into implementation is, in my view, the condition for sustaining a serious app in this genre over the long term.

Supporting International Users from a Single Codebase — Localization, Timezones, Currency

A pleasant property of fortune and manifestation apps is that you can pursue a reasonable degree of international expansion at low marginal cost. Divination cultures vary enormously by region, so you can't truly adapt deeply to every market, but English, Traditional Chinese, and Thai are usually reachable from a single codebase if the design supports it.

In my experience, the first decision criterion for international expansion was not "can we translate the messages" but "can we preserve the user's sense of timezone and weekday rhythm." A 7 PM notification in Japan and a 7 PM notification in Taiwan operate on roughly the same emotional register, but a notification arriving at 3 AM Vietnam time will get the app deleted. The same todayInUserTimezone trick from earlier applies to notification scheduling: derive the timing from the user's local clock, not from your home timezone.

Currency display is a surprisingly common stumble. Rork-generated code sometimes hardcodes yen display, and showing "¥480/month" to a user in Bangkok creates a small but real friction. Swapping to Intl.NumberFormat for localized currency formatting is a change with direct impact on conversion.

// src/lib/formatPrice.ts
// Format prices using the user's locale
 
export function formatLocalizedPrice(
  amountInJpy: number,
  locale: string = Intl.DateTimeFormat().resolvedOptions().locale,
): string {
  // Store transactions are JPY-denominated, but display can show
  // a localized approximation. The store handles actual FX at checkout.
  const fmt = new Intl.NumberFormat(locale, {
    style: "currency",
    currency: "JPY",
  });
  return fmt.format(amountInJpy);
}

The cleanest operational pattern I've found is: keep prices in App Store Connect / Google Play Console's price tier auto-conversion, and frame in-app displays as approximations. "The exact amount will be shown at checkout" is honest, and it cuts down on complaints when exchange rates shift.

A subtler localization concern is the message content itself. Fortune content has cultural specificity that doesn't always translate gracefully. I generally write a fresh message pool per language rather than literally translating the Japanese pool. Letting the Thai pool follow Thai sensibilities about fortune (which lean differently than Japanese sensibilities) is what makes the app feel native rather than transplanted.

Treating Store Reviews as Part of the Content Layer

A surprisingly effective practice for fortune-genre apps is to treat store reviews as part of the content surface, not just as feedback. Reviews are both quality signals and public content that future users will read.

In my own apps, the rule was: any 3-star-or-lower review gets a reply within 48 hours. The reply acknowledges the issue, separates "what we can fix now" from "what we plan for the next version," and uses concrete language about timing. "Thank you for the feedback. Customizable notification times are planned for the next release." When that next release ships, you can update the reply to say "the requested feature is now live as of v1.4." Each touchpoint compounds into a sense of "this app is being cared for."

This communication pattern subtly shifts how new users perceive the app when scanning reviews. Fortune and manifestation apps suffer from "machine-feeling" perception more than other genres, and visible human stewardship counters that. The numerical rating goes up too, but more importantly the brand context around the rating shifts.

The time investment is real — a few minutes per reply, several replies per week. For a solo developer, it's not nothing. But measured against the cost of acquiring new users to replace those lost to bad reviews, it's a strong return on attention.

Three Pitfalls Indie Developers Walk Into

To wrap up, here are three pitfalls I've personally stepped on.

Pitfall 1: "Daily" content secretly cycles — and the user notices

If you only have 100 messages and pick with a flat Math.floor(rand() * 100), your user will recognize repeats within 3–4 weeks. Encountering the same content twice tanks satisfaction more than you'd expect. The fix is straightforward: expand the message pool to at least 300–500 entries and keep a 30-day local history of shown themes to suppress repeats.

// src/lib/avoidRecentRepeats.ts
// Avoid repeating themes seen in the last 30 days
 
import AsyncStorage from "@react-native-async-storage/async-storage";
 
const HISTORY_KEY = "fortune-history-v1";
const HISTORY_DAYS = 30;
 
type HistoryEntry = { date: string; themeId: string };
 
export async function pickNonRepeating(
  candidates: { themeId: string; body: string }[],
  rand: () => number,
  today: string,
): Promise<{ themeId: string; body: string }> {
  const raw = await AsyncStorage.getItem(HISTORY_KEY);
  const history: HistoryEntry[] = raw ? JSON.parse(raw) : [];
 
  // Drop entries older than HISTORY_DAYS days
  const cutoff = new Date(today);
  cutoff.setDate(cutoff.getDate() - HISTORY_DAYS);
  const recent = history.filter((h) => new Date(h.date) >= cutoff);
  const recentThemes = new Set(recent.map((h) => h.themeId));
 
  // Prefer candidates not seen recently
  const fresh = candidates.filter((c) => !recentThemes.has(c.themeId));
  const pool = fresh.length > 0 ? fresh : candidates;
  const picked = pool[Math.floor(rand() * pool.length)];
 
  recent.push({ date: today, themeId: picked.themeId });
  await AsyncStorage.setItem(HISTORY_KEY, JSON.stringify(recent));
 
  return picked;
}

Pitfall 2: No recovery path for users who deny notifications

Once a user denies notification permission, they won't come back unless they manually re-enable it in Settings. For this segment, the realistic answer is to ship an in-app screen with annotated screenshots showing exactly how to flip the switch. Expo gives you Linking.openSettings() to open the system settings directly — but framing why notifications matter before that link makes the difference in opt-in rates.

Pitfall 3: The morning notification becomes a paywall

A frequent complaint in store reviews is "I tapped the notification and got a paywall instead of my reading." If a daily-content app puts the subscription pitch ahead of today's free content, it loses trust quickly. The deep link from the notification has to land squarely on the free reading for today. The premium funnel comes after the user is satisfied, never before.

Message Copy and the Temperature of Words

Stepping briefly away from implementation: in this genre, the prose style of the messages themselves moves retention more than most developers realize. Same content, different voice, very different daily-habit formation.

A few patterns I've found effective:

First, avoid over-deploying "you." Lines like "Today, you will..." or "Your day brings..." applied to every message start to feel mechanical. Mixing in openings like "Today's current is..." or "The theme rising today is..." reduces the pushy quality and lets the message land as observation rather than command.

Second, avoid imperative voice. "Do this," "Try that" overstate the authority of fortune content. Soft-suggestion forms like "It may be worth..." or "Consider turning your attention toward..." preserve the user's agency and feel more honest about the nature of the genre.

Third, avoid forced positivity. Messages like "An amazing day is coming" or "The best encounter awaits" trade credibility for short-term lift. When the prediction doesn't materialize — which is most days, statistically — trust erodes. I've settled on patterns that stay close to the user's actual experience: "You may notice..." or "This is a day that holds hints about..."

Codifying the voice into a one-page style guide is worth the effort if you're going to expand the message pool over time, especially if you outsource any of the writing. When I built up a 500-message pool, I wrote the first 50 entries myself to define the voice, then briefed external writers using those 50 as samples for the remaining 450.

The temperature of the words ultimately reflects what kind of relationship you want with the user. Heavy-handed prediction language sets up an authoritative dynamic that doesn't age well. A quieter, more inviting voice scales differently — it stays sustainable past month six, which is where most fortune apps die.

Onboarding Without Friction — Letting Users Reach the Content in Under 30 Seconds

One last design point that compounds with everything above: the path from "first install" to "first message received" needs to be as short as possible. Asking for a date of birth, gender, name, and email before showing anything is a guaranteed way to lose half your day-one installs.

The pattern I've converged on is to let users see the day's reading immediately after a single optional input (date of birth). Notification permission gets requested only after the first reading is shown, framed in context: "Want to receive tomorrow's reading at a time that works for you?" Permission opt-in rates roughly doubled when I made this change in one of my apps — from around 40% to about 78%.

Account creation, if it exists, comes much later. For a daily-content app, anonymous local UUIDs work fine for the core experience. Push the account creation gate to the point where the user wants to back up their reading history or sync across devices.

Indie developers often over-build the onboarding flow, mostly because the templates and tutorials online assume a SaaS-style account-first model. Fortune apps are closer to media apps in their user expectations: arrive, consume content, decide if you want to come back. Match the genre's pacing instead of fighting it.

A Concrete Content-Stock Plan for Your First 500 Messages

If you're starting from scratch, the most common mistake is to launch with too few messages and try to grow the pool reactively. By the time you notice users complaining about repetition, you've already burned the trust of your most loyal day-30 cohort. Front-load the work.

The decomposition I recommend is to split your 500 messages across roughly five themes (love, work, health, money, relationships) with about 100 messages each, then further split by rank tier. A practical balance is 25 messages per (theme, rank-band) cell where rank-bands group the 12-level rank into "strong positive (1–3)," "mild positive (4–6)," "neutral (7–8)," and "cautious (9–12)." Twenty-five messages per cell gives you the stock you need — but as the measurements above show, stock alone doesn't prevent repeats when each day is drawn independently (35.6% of users hit one inside three weeks). Build the stock, then hand it out with the shuffle bag.

Writing 500 messages sounds daunting until you sit down for a focused four-hour session. With a tight voice guide and the rank-band buckets pre-defined, I've drafted 80–100 messages in a single sitting. Three or four such sessions gets you to launch quality. Outsource the final polish if writing isn't your strength — but write the first 50 yourself to lock in the voice.

Storage-wise, ship the message pool as a versioned JSON file bundled with the app, and use silent server pulls to refresh the pool periodically. Bundling means the app works fully offline (a meaningful retention factor for travelers and users with spotty connectivity), and silent updates let you fix typos or add seasonal messages without forcing the user through an app store update.

Measuring What Matters — A Minimal Analytics Setup

Before tuning anything, set up enough analytics to know what's actually happening. For this genre I rely on five events at minimum:

• app_open — every cold start, with a property for "is_via_notification"
• reading_viewed — when the day's reading is shown, with rank and theme
• widget_added — when the lock-screen widget is configured
• notification_opted_in — when the user grants notification permission
• paywall_shown and paywall_purchased — both with a property for which premium feature triggered them

That's enough to compute the four numbers that drive every decision: day-N retention (n=1, 7, 30), notification opt-in rate, widget adoption rate, and ARPPU. Anything beyond these five events is bonus until those four numbers stabilize.

I prefer to keep this stack lightweight — Firebase Analytics or PostHog with self-hosted ingestion both work fine. Avoid the temptation to install half a dozen analytics SDKs at launch; they slow cold start time, which itself hurts day-1 retention. Pick one and stick with it.

Before / After — What Actually Happened in My Own App

Some real numbers from one of my manifestation-genre apps. This predates the Rork migration, but the underlying design lessons carry over identically.

Before (initial release, around 2024)

• 100-message pool, flat random pick
• No push notifications
• No widget
• Subscription pitch immediately after the user sees the result
• Day-7 retention ~8%, day-30 retention ~2%, ARPPU ~¥180/month

After (after design overhaul, mid-2025)

• 480-message pool, seeded PRNG + 30-day repeat suppression
• Fixed 7:15 AM daily notification
• Lock-screen widget showing the first line
• After the free content, CTA shown at most twice per day
• Day-7 retention ~19%, day-30 retention ~6%, ARPPU ~¥430/month

The two changes that moved the needle most were expanding the message pool and tuning the notification copy. Neither is glamorous, but the cumulative effect of small genre-aware adjustments is what produced this gap.

Rork Onboarding: Designing Against Day-One Churn pairs well with this article if you want a continuous retention story from day 1 through day 30.

Price Experiments That Actually Tell You Something

Pricing in this genre rewards experimentation, but most "A/B tests" indie developers run don't have enough volume to draw real conclusions. Before running a price test, count your daily paywall impressions. If that number is under 200, the test will take months to reach statistical confidence — better to skip the test and decide based on prior beliefs.

When you do have enough volume, the most informative test isn't price level, it's price structure. Comparing "¥480/month only" against "¥480/month + ¥1,800 yearly one-time" tells you whether the buy-once option is bringing in users who would otherwise have churned without paying. In my experience, the answer was yes — by a meaningful margin — and that finding generalized across multiple apps in the genre.

A related lesson: avoid testing pricing during major spiritual or seasonal events (year-end, Chinese New Year, Setsubun, equinoxes). User behavior shifts so dramatically during those windows that any test data you collect will be misleading. Run your structural tests during steady-state weeks and use seasonal periods for amplitude tests (does a limited-time promotion lift baseline conversion?).

What to Try Tomorrow

After all of this design talk, the single concrete thing worth trying tomorrow is to add one line of logging to your delivery code and count how many days it takes for the same message to come back to the same user. That's where I found out my own three-week assumption was wrong. Growing the pool can wait until after you've counted — and counting tells you how far you actually need to grow it.

I still wrestle with the same design problems every time I ship a new app. There's no finished playbook here — just a long sequence of small hypotheses, tested in production. I'd be glad to keep learning alongside you. Thanks for reading.