Forem: Charlie Brinicombe

How We Built SaaS Calculators in Next.js (And Kept Them Shareable)

Charlie Brinicombe — Wed, 25 Mar 2026 15:51:13 +0000

When we built our calculator suite, we wanted more than "a form that outputs a number."

We wanted calculators that were:

fast and SEO-friendly,
easy to extend,
mathematically auditable,
and shareable via URL.

This post breaks down the architecture, design patterns, and trade-offs behind that implementation.

Motivation (and a bit about Trophy)

Trophy is a product aimed at helping teams make better decisions about growth and retention. In our space, the same few questions come up constantly:

What does our churn imply about retention over time?
If we reduce churn, what’s the revenue impact over the next 6–12 months?
Given ARPU and churn, what’s a reasonable LTV and customer lifespan?

We could have answered those with spreadsheets, PDFs, or one-off blog posts but those formats don’t travel well inside a team. We wanted something that:

turns “back-of-napkin” math into an interactive tool,
makes assumptions explicit,
produces a link you can drop into Slack/Notion, and
holds up technically (fast load, predictable state).

That’s why we built calculators as a first-class part of the web app: not just for lead-gen, but as a reusable, composable surface we can iterate on as the product evolves.

Anatomy of a Calculator Page (and why each section exists)

One thing we learned quickly: the calculation itself is only a small part of the user journey.

Each page section has a distinct job:

Header + description: establishes context fast ("what this calculator answers") so users know they’re in the right place before entering data.
Formula block: adds transparency and trust, especially for technical readers who want to validate assumptions before using outputs.

Input controls: collect the minimum viable assumptions needed to compute a meaningful result without overwhelming the user.
Primary result card(s): surface the key answer immediately (e.g. churn, retention, LTV), with lightweight interpretive context.

Impact chart section: translates one-off outputs into a forward-looking narrative ("what changes over 3, 6, 12 months"), which is where decision-making usually happens.

Share section: turns a result into a portable artifact via URL, so teams can discuss the same scenario in Slack/Notion/email.
Related calculators: supports natural next questions (e.g. from churn to LTV), increasing usefulness and reducing dead-ends.
FAQ + CTA: FAQ handles objections and clarification; CTA gives users a clear next step after insight.

In practice, this structure helped us balance three goals simultaneously: educational content, interactive analysis, and team communication.

Tech Stack at a Glance

Next.js App Router for server/client component boundaries
React + TypeScript for predictable UI and typed state
Tailwind CSS for consistent composable styling
Recharts for chart rendering
URL query params as the source of truth for shareable results

1) Server-First Page Composition

A key architectural choice: keep route pages as server components, and pass searchParams down.

That gives us:

better SSR/SEO behavior,
cleaner hydration boundaries,
no useSearchParams() at the page level (which can force Suspense/client boundaries).

Example page composition:

import { config } from './config'
import Calculator from './calculator'
import ChurnImpactChart from './churn-impact-chart'
import { CalculatorPage, createCalculatorMetadata } from '@/components/calculators'

export const metadata = createCalculatorMetadata(config)

interface Props {
  searchParams?: Record<string, string | string[] | undefined>
}

export default function ChurnRateCalculatorPage({ searchParams }: Props) {
  return (
    <CalculatorPage
      config={config}
      initialSearchParams={searchParams}
      calculator={<Calculator initialSearchParams={searchParams} />}
      impactChart={<ChurnImpactChart initialSearchParams={searchParams} />}
    />
  )
}

This is a clean "orchestration layer" pattern: the page wires dependencies together, while feature components do domain work.

2) URL-Driven State via a Dedicated Hook

Instead of each calculator calling useSearchParams() directly, we introduced one shared adapter hook:

export function useCalculatorStateFromParams(
  initialSearchParams: SearchParamsInput,
): UseCalculatorStateReturn {
  const pathname = usePathname()
  const router = useRouter()
  const params = initialSearchParams ?? {}

  const state = useMemo(() => parseParamsToState(params), [params])

  const setState = useCallback(
    (updates: Partial<CalculatorState>) => {
      const next = { ...params }
      for (const [key, value] of Object.entries(updates)) {
        if (value !== undefined) next[key] = String(value)
      }
      const query = paramsToSearchString(next)
      router.replace(query ? `${pathname}?${query}` : pathname, { scroll: false })
    },
    [pathname, params, router],
  )

  return useMemo(() => ({ state, setState }), [state, setState])
}

Why this pattern works

Single source of truth for query parsing/serialization.
No duplicated URL sync logic across calculators.
Share-by-default UX: every calculated result can be copied as a link.

This is effectively an adapter around Next routing primitives with a calculator-focused API.

3) Config-Driven Page Metadata and Content

We model each calculator with a typed CalculatorConfig.

export interface CalculatorConfig {
  slug: string
  name: string
  meta: { title: string; description: string }
  formula: string
  content: {
    description: string
    intro?: { title: string; content: string }
    calculatorSectionTitle?: string
    ctaTitle: string
    ctaDescription: string
  }
  // ...
}

Then metadata generation becomes deterministic and reusable:

export function createCalculatorMetadata(config: CalculatorConfig): Metadata {
  return {
    title: config.meta.title,
    description: config.meta.description,
    alternates: {
      canonical: `https://trophy.so/calculators/${config.slug}`,
    },
  }
}

This reduces drift between SEO tags and on-page content, while making it easier to add new calculators safely.

4) Composition Over Monoliths

The shared shell (CalculatorPage) receives three key inputs:

config
calculator node
impactChart node

export default function CalculatorPage({
  config,
  initialSearchParams,
  calculator,
  impactChart,
}: Props) {
  return (
    <CalculatorLayout config={config}>
      <CalculatorShell>{calculator}</CalculatorShell>
      {impactChart}
      <CalculatorShareSection
        config={config}
        initialSearchParams={initialSearchParams}
        hideUntilCalculated
      />
    </CalculatorLayout>
  )
}

This is a pragmatic slot-based composition pattern:

The layout remains consistent across calculators.
Each domain calculator can evolve independently.
Shared behavior (share section, formula, related calculators, CTA) stays centralized.

5) Domain Math Lives in Pure Functions

UI is stateful and interactive; math should be deterministic and testable.

So the formulas sit in standalone utility modules:

export function generateChurnDecayData(
  startingUsers: number,
  period: 1 | 7 | 30,
  churnPercent: number,
  maxDays: number = 90,
) {
  const clamped = Math.max(0, Math.min(100, churnPercent))
  const survivalPerPeriod = clamped >= 100 ? 0 : 1 - clamped / 100
  const points: { days: number; users: number }[] = []
  const step = Math.max(1, Math.floor(period / 2))

  for (let d = 0; d <= maxDays; d += step) {
    const periodsElapsed = d / period
    const survival = Math.pow(survivalPerPeriod, periodsElapsed)
    points.push({ days: d, users: Math.round(startingUsers * survival) })
  }

  return points
}

Benefits

easier unit testing,
less coupling to React render cycles,
clearer auditing for stakeholders who care about formula correctness.

6) Two-Layer Validation Strategy

Each calculator validates in two places:

Realtime input validity (isValid) to disable calculate actions.
Action-time validation inside handleCalculate for safety.

const isValid =
  Number.isFinite(startNum) &&
  Number.isFinite(remainingNum) &&
  startNum > 0 &&
  remainingNum >= 0 &&
  remainingNum <= startNum

const handleCalculate = () => {
  if (!isValid) {
    setResult(null)
    setState({ shareReady: 0 })
    return
  }

  const churn = calculateChurn(start, remaining)
  setResult(churn)
  setState({ startingUsers: start, remainingUsers: remaining, churnRate: churn, shareReady: 1 })
}

This avoids accidental invalid URL state and keeps result cards/charts consistent.

7) Performance and UX Choices

Some implementation details that made a big difference:

useMemo for chart data and derived values (half-life, domains).
route updates via router.replace with { scroll: false } to avoid janky navigation.
fixed, typed period options (1 | 7 | 30) to simplify math and UI consistency.
responsive chart containers (overflow-x-auto + minimum widths) for small screens.

8) Design Patterns We Reused Across Calculators

The biggest win was pattern consistency:

Template + Slots: one page shell, pluggable calculator + chart.
Adapter Hook: one URL-state bridge for all calculators.
Pure Domain Modules: math separated from rendering.
Config-Driven Metadata: SEO/content generated from typed config.
Feature Flags in Query: share readiness and parameterized results.

These patterns made adding new calculators substantially faster after the first one.

9) What We’d Improve Next

If we were extending this further, we’d likely add:

schema-based query parsing/validation (e.g. zod/valibot) for stricter runtime guarantees,
analytics events at "calculate" and "share" boundaries,
optional server-side persistence for comparison history,
benchmarking (e.g. “you’re in the 60th percentile for churn in fitness apps”) with clear cohort definitions and data provenance,
downloadable reports (PDF/CSV) that bundle inputs, assumptions, charts, and a narrative summary,
shareable team reports (invite colleagues, comments, pinned scenarios) so calculators become collaborative artifacts—not just individual tools,
scenario management (save multiple parameter sets, compare side-by-side, and track deltas over time),
permissions + workspace context so sharing can be public links, private links, or org-only depending on the audience.

Final Thoughts

The core idea is simple: treat calculators as a product surface, not a throwaway widget.

By combining server-first composition, URL-based state, and pure domain math, we ended up with calculators that are:

maintainable,
predictable,
and genuinely useful to share in real workflows.

If you’re building anything similar, start with these two constraints:

Every result should be reproducible from the URL.
Every formula should live outside the component tree.

Everything else gets easier from there.

How to Build an Achievements Feature

Charlie Brinicombe — Fri, 17 Oct 2025 15:21:22 +0000

You want achievements. Track user progress. Award badges for milestones. Display completion status. Seems straightforward. Three weeks later, you're debugging why some users didn't get achievements they qualified for, handling backdating for new achievements, and optimizing queries that check completion criteria for every user action.

Achievement systems appear simple until you implement them at scale. The core concept (recognize milestone completion) hides complexity. When do you check if achievements are complete? How do you handle users who qualified before the achievement existed? What about achievements that require checking historical data across multiple metrics?

Trophy handles achievement systems including completion logic, progress tracking, and backdating. The complete implementation guide walks through the full process. Integration takes 1 day to 1 week. But understanding what building from scratch involves helps you make informed build versus buy decisions.

Key Points

Technical challenges in achievement system implementation
Completion checking patterns that scale
Backdating strategies for fairness
Integration examples with Trophy's API
Build versus buy considerations for achievement features

The Technical Reality

Before building achievement systems, understand the problems beyond simple milestone tracking.

Completion checking logic needs efficiency at scale. Checking every achievement on every user action kills performance. You need smart triggering that only checks relevant achievements. Building this trigger system takes time.

Progress tracking for multi-step achievements adds complexity. "Complete 100 tasks" needs counting. Showing users "45/100" requires storing partial progress. Updating this efficiently as users act requires careful database design.

Backdating ensures fairness when you add new achievements. Users who qualified before the achievement existed should complete it automatically. Scanning historical data for every user takes time. Getting this right without overloading your database is tricky.

Badge hosting and delivery seems minor but adds infrastructure. Where do badge images live? How do you serve them efficiently? What formats work across platforms? These details accumulate.

Rarity calculations show how many users completed each achievement. This requires counting completions across your entire user base and keeping these counts updated as more users complete achievements.

Building production-ready achievement systems typically takes 3-5 weeks including completion logic, progress tracking, and backdating. Trophy's infrastructure handles these problems, reducing implementation to integration work.

Architecture Patterns

If building in-house, these patterns avoid common mistakes.

Event-based checking triggers achievement evaluation only when relevant events occur. Store achievement triggers. When events arrive, check only achievements that could complete based on that event type. This scales better than checking all achievements on every action.

Incremental progress updates maintain partial completion state. Store "tasks completed: 45" instead of recalculating from history on every check. Update incrementally as users act. Trophy uses this pattern for efficient progress tracking.

Async backdating processes achievement qualification in background jobs. When you create an achievement, queue a job that scans historical data and awards to qualified users. Don't block achievement creation on backdating completion.

Denormalized completion state stores which users completed which achievements in fast-access storage. Recompute from history only when needed. Trophy maintains completion state with millisecond query latency.

Trigger mapping links achievement requirements to specific events. Achievement requires metric X reaching value Y, so only check it when metric X events arrive. Trophy's configuration system includes this trigger mapping automatically.

Trophy implements these patterns. You configure achievement criteria. Trophy handles the infrastructure complexity.

Implementation Estimate

Here's realistic timeline for building achievements in-house:

Week 1: Basic implementation. Create achievements. Track completions. Display badges. Works in development with simple achievements.

Week 2: Progress tracking. Store partial progress for multi-step achievements. Update progress efficiently. Show users their advancement toward incomplete achievements.

Week 3: Completion logic. Build trigger system that checks relevant achievements on user actions. Optimize to avoid checking irrelevant achievements. Handle achievement criteria complexity.

Week 4: Backdating and edge cases. Implement fair backdating for new achievements. Handle concurrent completion attempts. Test with realistic data volumes.

Ongoing: Maintenance and expansion. New achievements need adding regularly. Badge management continues. Performance tuning as usage scales.

That's 4+ weeks of engineering time plus ongoing maintenance. Trophy's infrastructure eliminates this timeline, reducing implementation to 1 day to 1 week of integration work.

Building with Trophy

Trophy's integration is faster because achievement infrastructure already exists. Here's what implementation looks like.

Step 1: Create Achievements

In Trophy's dashboard, create achievements with:

Name and description
Badge image (Trophy hosts this for you)
Trigger type (metric-based, API-based, or streak-based)
Completion criteria

For metric achievements, specify which metric and what threshold completes the achievement. Trophy automatically tracks progress and awards completion when users reach the threshold.

Managing achievements online means future additions or changes happen in the dashboard and not in your codebase, preventing back and forth changes.

Step 2: Track User Actions

Send events to Trophy when users perform achievement-relevant actions:

import { TrophyApiClient } from '@trophyso/node';

const trophy = new TrophyApiClient(process.env.TROPHY_API_KEY);

// When user completes a task
const response = await trophy.metrics.event('tasks_completed', {
  user: {
    id: 'user-123'
  },
  value: 1
});

// Check if user completed any achievements
if (response.achievements && response.achievements.length > 0) {
  response.achievements.forEach(achievement => {
    console.log(`Unlocked: ${achievement.name}`);
    console.log(`Badge: ${achievement.badgeUrl}`);
    showAchievementNotification(achievement);
  });
}

Trophy processes events and automatically checks if any achievements should complete. The response includes newly completed achievements for immediate user feedback.

Step 3: Display User Achievements

Fetch achievements a user has completed:

// Get user's completed achievements
const achievements = await trophy.users.achievements('user-123', {
  includeIncomplete: 'false' // Only show completed
});

achievements.forEach(achievement => {
  console.log({
    name: achievement.name,
    description: achievement.description,
    badgeUrl: achievement.badgeUrl,
    completedAt: achievement.achievedAt,
    rarity: achievement.rarity // Percentage of users who completed it
  });
});

Trophy returns achievement data including badges, completion timestamps, and rarity statistics. The achievements API documentation covers all available fields.

Step 4: Show Achievement Progress

For incomplete achievements, show progress toward completion:

// Get all achievements including incomplete ones with progress
const allAchievements = await trophy.users.achievements('user-123', {
  includeIncomplete: 'true'
});

allAchievements.forEach(achievement => {
  if (achievement.achievedAt) {
    // Completed
    console.log(`✓ ${achievement.name}`);
  } else {
    // Incomplete - show progress if available
    if (achievement.progress) {
      const percent = (achievement.progress.current / achievement.progress.target) * 100;
      console.log(`${achievement.name}: ${percent}% complete`);
    }
  }
});

Trophy tracks progress for metric-based achievements automatically. Users see how close they are to completion.

Step 5: Complete API Achievements

For achievements that can't be automatically tracked via metrics (completing onboarding, linking accounts, etc.), use the complete achievement API:

// When user completes onboarding
await trophy.achievements.complete('user-123', 'onboarding_complete');

// Trophy marks it as complete and returns achievement data
const result = await trophy.achievements.complete('user-123', 'onboarding_complete');

if (result.achievement) {
  console.log(`Completed: ${result.achievement.name}`);
  showAchievementNotification(result.achievement);
}

This gives you control over when achievements complete for events Trophy can't track automatically.

Achievement Types and Strategies

Different achievement structures serve different product goals. Understanding when your app needs achievements helps you design effective systems.

Metric achievements track cumulative actions. "Complete 100 tasks" or "View 50 lessons." These recognize consistent usage and progress toward mastery. Trophy's metric system tracks these automatically.

Streak achievements recognize consistency. "Maintain a 30-day streak" celebrates sustained engagement. Trophy's streak tracking makes these simple to implement.

API achievements recognize specific one-time events. "Complete onboarding" or "Link social account." You trigger these manually when appropriate events occur.

Tiered achievements create progression. Bronze (10 tasks), silver (50 tasks), gold (100 tasks). Users see clear advancement path. Trophy's metric thresholds support tiered structures naturally.

Hidden achievements surprise users through discovery. Don't show them until completed.

Mix achievement types to serve different user motivations and engagement patterns.

Designing Achievement Structures

Effective achievement design requires understanding user psychology and product goals. Designing achievements for optimal engagement explores strategic frameworks for achievement creation.

Accessibility balance matters. Some achievements should be easy (first task completed) for quick wins. Others should be challenging (1,000 tasks completed) for long-term goals. Trophy's analytics show completion rates helping you tune difficulty.

Progressive revelation prevents overwhelming new users. Show basic achievements upfront. Reveal advanced achievements as users progress. Trophy's achievement system supports controlling visibility.

Meaningful milestones align with user goals. Achievements should recognize progress users care about, not arbitrary metrics. Trophy's flexible metric system lets you track what matters for your product.

Rarity indicators show prestige. "Only 5% of users have completed this" motivates completion. Trophy automatically calculates and displays rarity statistics.

Backdating Logic

When you create new achievements, users who already qualified should complete them automatically. Trophy handles this through backdating.

When you activate an achievement in Trophy:

Trophy scans historical data for users who meet completion criteria
Awards the achievement to qualified users with original completion timestamp
Updates completion counts and rarity statistics
Processes in background without blocking achievement activation

This ensures fairness without requiring manual intervention. Users who completed 100 tasks before that achievement existed get credit when you launch it.

Your code doesn't change. Trophy handles backdating automatically based on achievement configuration.

Notification Strategy

Achievement completions need communication without overwhelming users. Trophy's email system handles notification timing.

Configure achievement emails in Trophy's dashboard:

When to send (immediately, batched, specific times)
Email content and design
Which achievements trigger emails

Trophy sends notifications automatically when users complete achievements. No manual email logic needed in your code.

// Trophy handles notifications automatically
// Your code just tracks events
await trophy.metrics.event('tasks_completed', {
  user: { id: 'user-123' },
  value: 1
});

// If user completes achievement, Trophy sends configured emails

Performance Considerations

Trophy's infrastructure is built for scale, but your integration patterns affect performance.

Check achievements server-side only. Don't query achievement status on every page load. Cache achievement data and refresh periodically or after user actions.

Cache completion state for display-heavy scenarios. Achievement lists don't need real-time accuracy. Cache for 5-10 minutes:

const cache = new Map();

async function getCachedAchievements(userId: string) {
  const cached = cache.get(userId);
  if (cached && Date.now() - cached.timestamp < 300000) {
    return cached.data;
  }

  const fresh = await trophy.users.achievements(userId);
  cache.set(userId, { data: fresh, timestamp: Date.now() });
  return fresh;
}

Trophy handles backend scaling. These client-side patterns optimize your application's performance.

Analytics and Tuning

Trophy provides analytics for achievement system health.

Completion rates show whether achievements are appropriately difficult. Trophy's dashboard shows what percentage of users complete each achievement. Aim for variety: some easy (60%+), some moderate (30-60%), some difficult (5-30%).

Completion velocity reveals how long achievements take. If most users complete an achievement within days of starting, it might be too easy. If it takes months on average, consider whether it's appropriately challenging or frustratingly difficult.

Rarity distribution shows whether you have enough aspirational achievements. If all achievements have 40-60% completion, you might need harder goals for engaged users.

Abandonment patterns indicate where users give up. If users progress halfway toward an achievement then stop, the difficulty curve might be wrong or the achievement might not be compelling.

Use these insights to refine achievement thresholds and create new achievements that fill gaps. Trophy's dashboard configuration makes adjustments quick without code changes.

How to Build an Energy Feature

Charlie Brinicombe — Fri, 17 Oct 2025 11:47:21 +0000

Your want to add an energy feature to your platform. Users consume energy for actions. Energy regenerates over time. Cap it at a maximum. Seems like simple arithmetic. Three weeks later, you're debugging regeneration timing, handling edge cases around maximum caps, and dealing with race conditions when users perform rapid actions.

Energy systems appear straightforward until you implement them at scale. The core concept (limited resource that regenerates) hides complexity. When does regeneration happen? What if users act while at zero energy? How do you handle time zones for regeneration timing? What prevents users from gaming the system?

Trophy handles energy systems including regeneration, consumption, and metering. The complete implementation guide walks through the full process. Integration takes 1 day to 1 week. But understanding what building from scratch involves helps you make informed build versus buy decisions.

Key Points

Technical challenges in energy system implementation
Regeneration patterns and timing considerations
Consumption triggers and usage metering
Integration examples with Trophy's API
Build versus buy considerations for energy features

The Technical Reality

Before building energy systems, understand the problems beyond simple counters.

Time-based regeneration needs careful implementation. Energy regenerates hourly or daily, but when exactly? Server-scheduled jobs create spiky regeneration patterns. Per-user timers scale poorly. Event-driven regeneration requires complex triggering. Getting this right takes time.

Maximum cap handling prevents infinite accumulation. Users hit the cap and stop regenerating. But what if regeneration happens while they're at cap? Do they lose potential energy? How do you communicate this clearly? Edge cases around caps create complexity.

Consumption timing affects user experience. Immediate energy deduction prevents spam but blocks users at zero. Deferred consumption allows actions but creates debt states. Partial consumption for partial actions adds more complexity.

Race conditions happen when users perform rapid actions. Two actions at 5 energy each when user has 8 energy total. Which succeeds? Do they both check balance simultaneously and both succeed, overdrawing the account? Proper locking prevents this but adds latency.

Time zone handling for regeneration schedules requires per-user logic. Daily regeneration at midnight means different times for different users. Trophy handles time zones automatically, but building this yourself means complex timezone math.

Building production-ready energy systems typically takes 3-6 months including regeneration logic, consumption triggers, and edge cases. Trophy's infrastructure handles these problems, reducing implementation to integration work.

Architecture Patterns

If building in-house, these patterns avoid common mistakes.

Event-based consumption separates action tracking from energy deduction. Store user actions as events. Process energy changes asynchronously. This prevents blocking user actions on energy calculations but requires careful consistency management.

Scheduled regeneration jobs grant energy at fixed intervals. Cron jobs that run hourly or daily and grant energy to eligible users. This pattern is simple but creates load spikes. Trophy uses distributed scheduling that spreads regeneration load evenly.

Lazy regeneration computes energy only when queried. Store last check time. When user requests their balance, calculate regeneration since last check and update. This avoids scheduled jobs but complicates balance queries. Trophy uses hybrid approach with cached totals and lazy updates.

Optimistic locking prevents race conditions. Check energy balance, attempt consumption, verify balance didn't change during operation. If it changed, retry. This ensures consistency without blocking concurrent operations.

Denormalized balances for query performance. Maintain current energy in fast storage (Redis). Recompute from event history only when needed. Trophy caches current balances with millisecond query latency.

Trophy implements these patterns. You configure regeneration rules and consumption triggers. Trophy handles the infrastructure complexity.

Implementation Estimate

Here's realistic timeline for building energy systems in-house:

Week 1-2: Basic implementation. Track energy balance. Deduct for actions. Display totals. Works in development with simple cases.

Week 3-4: Regeneration logic. Implement time-based regeneration with scheduled jobs. Handle maximum caps. Make regeneration work across user sessions and time zones. Test edge cases around timing.

Week 5-6: Consumption triggers. Build system for deducting energy based on different actions. Implement variable consumption amounts. Handle insufficient energy cases gracefully.

Week 7: Concurrency and edge cases. Prevent race conditions. Handle rapid actions correctly. Test regeneration at scale. Fix performance issues.

Ongoing: Maintenance and tuning. As usage patterns change, regeneration rates need adjustment. New actions need consumption rules. This work continues indefinitely.

That's 7+ weeks of engineering time plus ongoing maintenance. Trophy's infrastructure eliminates this timeline, reducing implementation to 1 day to 1 week of integration work.

Building with Trophy

Trophy's integration is faster because energy infrastructure already exists. Here's what implementation looks like.

Step 1: Create Energy System

In Trophy's dashboard, create a points system called "Energy" (or your preferred name). Configure the maximum energy cap users can have. Trophy supports any maximum up to your requirements.

Energy systems are just points systems with specific regeneration and consumption rules. Trophy's flexible points infrastructure supports both XP-style accumulation and energy-style metering.

Step 2: Configure Regeneration Triggers

Set up how users gain energy over time. In Trophy's dashboard, create time-based triggers:

Hourly regeneration : Grant X energy every N hours

Award 1 energy every hour
Award 10 energy every 6 hours
Maximum caps prevent energy exceeding limits

Daily regeneration : Grant energy once per day

Award 20 energy at midnight user time
Award 50 energy every 24 hours
Trophy handles timezone timing automatically

Trophy's trigger system grants energy automatically based on your configuration. Users receive energy without manual processing.

Step 3: Configure Consumption Triggers

Set up how users spend energy. Create negative-value triggers for actions that consume energy:

Action-based consumption : Deduct energy when users perform specific actions

Deduct 1 energy per lesson viewed
Deduct 5 energy per workout started
Deduct 10 energy per premium feature access

Configure these through Trophy's dashboard as negative point awards. When users perform tracked actions, Trophy automatically deducts configured energy amounts.

Step 4: Track Energy-Consuming Actions

Send events for actions that consume energy:

import { TrophyApiClient } from '@trophyso/node';

const trophy = new TrophyApiClient(process.env.TROPHY_API_KEY);

// When user views a lesson (consumes 1 energy)
const response = await trophy.metrics.event('lesson_viewed', {
  user: {
    id: 'user-123'
  },
  value: 1 // 1 lesson viewed
});

// Check remaining energy
if (response.points?.energy) {
  const remaining = response.points.energy.total;
  const consumed = Math.abs(response.points.energy.added); // Will be negative
  console.log(`Consumed ${consumed} energy. ${remaining} remaining.`);
}

Trophy processes the event and automatically deducts energy based on trigger configuration. The response includes updated energy balance for immediate display.

Changes to energy consumption logic can be made in the Trophy dashboard, preventing back and forth code changes.

Step 5: Check Energy Before Actions

Before allowing energy-consuming actions, check if user has sufficient energy:

// Check user's current energy
const energy = await trophy.users.points('user-123', 'energy');

if (energy.total > 0) {
  // User has energy, allow action
  await performAction();

  // Track the action (consumes energy)
  await trophy.metrics.event('lesson_viewed', {
    user: { id: 'user-123' },
    value: 1
  });
} else {
  // User has no energy, prevent action or show paywall
  showInsufficientEnergyMessage();
}

This pattern prevents users from attempting actions they can't afford. The energy check happens before action processing, providing clear feedback.

Step 6: Display Energy Status

Show users their current energy and when it regenerates:

// Get detailed energy information
const energy = await trophy.users.points('user-123', 'energy', {
  awards: 5 // Last 5 energy changes
});

console.log({
  current: energy.total,
  maximum: energy.maximum,
  recentChanges: energy.awards.map(award => ({
    amount: award.points,
    trigger: award.trigger.name,
    time: award.timestamp
  }))
});

Trophy returns current energy, maximum cap, and recent energy changes. Use this data for UI showing energy status and regeneration timing. The points API documentation covers all available fields.

Regeneration Strategies

Different regeneration patterns serve different product goals.

Constant regeneration grants energy at fixed intervals regardless of usage. Users get 1 energy per hour even if they're at maximum. Simple but can waste potential energy when users hit caps.

Regeneration until cap stops when users reach maximum. Trophy's default behavior. Users don't waste regeneration but might feel pressure to spend energy before hitting cap.

Overflow to storage lets excess regeneration accumulate in separate pool. Complex but prevents waste. Trophy supports this through secondary points systems that have different caps.

Activity-based regeneration grants energy for specific actions beyond time. Complete a challenge, gain energy. This creates positive feedback loops where engagement grants resources for more engagement.

Trophy's time-based triggers handle first two patterns natively. Configure in dashboard without code. More complex patterns use multiple points systems or custom trigger logic.

Consumption Patterns

How you consume energy affects gameplay and user psychology.

Fixed consumption deducts the same amount for all instances of an action. 1 energy per lesson. Simple and predictable. Users understand cost clearly.

Variable consumption charges different amounts for different actions or contexts. 1 energy for basic lesson, 5 energy for advanced lesson. Creates strategic choice about energy spending.

Scaling consumption increases cost based on usage. First 5 lessons cost 1 energy each, next 5 cost 2 each. Encourages moderation and prevents grinding. Trophy implements through threshold-based triggers.

Partial refunds return energy if actions don't complete. User starts lesson (spends energy) but quits (refunds energy). Requires custom logic to track partial completions and issue refunds as positive point awards.

Trophy's trigger flexibility supports all these patterns. Configure consumption amounts through dashboard. Adjust based on player behavior without code changes.

Preventing Energy Gaming

Energy systems create incentives to game. Design prevents exploitation.

Maximum caps prevent infinite accumulation. Trophy's configurable maximum prevents users from stockpiling unlimited energy for later use. Choose caps based on intended session length.

Rate limiting beyond energy. If users can refresh energy artificially (time zone changes, system clock manipulation), add detection and rate limits. Trophy's server-side processing prevents client-side time manipulation.

Consumption verification ensures actions actually completed before deducting energy. Deduct energy only after verifying action succeeded. Trophy's event-based model supports this through proper event sequencing.

Account-level tracking prevents multi-account farming. If users create multiple accounts to bypass energy limits, implement account-level detection. Trophy tracks per-user; your authentication layer handles account limits.

Display and Communication

How you present energy affects user experience.

Clear cost indicators before actions. "This will cost 5 energy" prevents surprise when users can't afford actions. Trophy's balance checking enables this.

Regeneration timing transparency. "Energy regenerates in 2 hours" or "Full energy at 8 PM" gives users planning information. Trophy's time-based triggers have predictable schedules you can communicate.

Friendly empty states. "You're out of energy! It regenerates 1 per hour." explains situation without being punitive. Frame energy as pacing mechanic, not punishment.

Progress toward regeneration. "Energy: 3/10 (regenerating...)" shows both current state and that progress continues. Trophy's balance provides current amount; you track maximum for display.

Economic Tuning

Energy systems need careful tuning to feel fair without killing engagement.

Regeneration rate determines session frequency. Fast regeneration (hourly) encourages frequent short sessions. Slow regeneration (daily) encourages longer, less frequent sessions. Trophy makes rate adjustments through dashboard configuration.

Maximum cap determines session length. Cap of 10 with consumption of 1 per action allows 10 actions per session. Cap of 100 allows longer sessions but slower regeneration to full. Trophy's configurable cap lets you test different values.

Consumption amounts relative to regeneration define gameplay pace. If regeneration grants 20 energy daily and average session consumes 15, users can play daily with buffer. Trophy's analytics show consumption patterns informing tuning.

Monitor average energy levels across users. If most users sit at maximum constantly, regeneration is too generous or consumption too low. If most users sit at zero, consumption is too high or regeneration too slow. Trophy's analytics dashboard shows energy distribution.

How to Build an XP Feature

Charlie Brinicombe — Fri, 17 Oct 2025 11:32:54 +0000

You want to add experience points. Track user actions. Award XP for each one. Display totals. Seems straightforward. Three weeks later, you're dealing with point inflation, rebalancing award amounts, and handling edge cases around which actions should grant XP and when.

XP systems appear simple until you implement them at scale. The core concept (accumulate points for actions) hides complexity in the details. Which actions grant how many points? How do you prevent inflation? What happens when you need to rebalance the economy? How do you handle retrospective changes fairly?

Trophy handles XP systems including triggers, economic balance, and award tracking. The complete implementation guide walks through the full process. Integration takes 1 day to 1 week. But understanding what building from scratch involves helps you make informed build versus buy decisions.

Key Points

Technical challenges in XP system implementation
Economic design patterns that prevent inflation
Trigger systems for awarding points automatically
Integration examples with Trophy's API
Build versus buy considerations for XP features

The Technical Reality

Before building XP systems, understand the problems you're solving beyond simple counters.

Point triggers need sophisticated logic. Users earn XP for actions, but not just any action. Completing 10 tasks might grant 50 XP. But should it grant 5 XP per task or 50 XP at the 10-task milestone? Different trigger patterns serve different goals. Building flexible trigger systems takes time.

Economic balance prevents inflation. If point values never change but users keep accumulating, eventually everyone has millions of points that mean nothing. You need either point sinks (ways to spend points) or the ability to rebalance without disrupting existing users.

Retrospective changes require careful handling. When you adjust point values or add new ways to earn XP, existing users might feel cheated if new users can earn more easily. Handling this fairly while improving the system is complex.

Award attribution matters for analytics. When users earn XP, you need to know why. Which specific trigger fired? This enables analysis of which behaviors drive engagement and which point awards are effective.

Historical tracking for progress visualization requires efficient storage. Showing users their XP over time means storing daily or weekly snapshots. This data grows linearly with users and time.

Building production-ready XP systems typically takes 3-6 months including trigger logic, economic tuning, and analytics. Trophy's infrastructure handles these problems, reducing implementation to integration work.

Architecture Patterns

If building in-house, these patterns avoid common mistakes.

Event-sourced points separate actions from point awards. Store user actions as events. Compute point totals from event history. This enables retroactive rebalancing and complete audit trails. Trophy uses this pattern, making it easy to understand exactly why users have their current XP totals.

Configurable triggers rather than hardcoded point awards. Store trigger rules in configuration or database, not code. This lets you adjust point values without deployment. Trophy's dashboard-based trigger configuration exemplifies this pattern.

Denormalized totals for query performance. Recomputing point totals from event history on every query doesn't scale. Maintain precomputed totals updated via triggers or async processes. Trophy caches current totals with millisecond query latency.

Idempotent award processing prevents double-awarding. If the same action triggers multiple times due to retries or bugs, ensure points award only once. Trophy's event processing includes idempotency to handle this.

Tiered trigger logic enables progressive complexity. Basic triggers: award X points for action Y. Advanced triggers: award X points for every N of action Y. Expert triggers: award points based on combinations of actions or user attributes.

Trophy implements all these patterns. You configure triggers through the dashboard. Trophy handles the infrastructure complexity.

Implementation Estimate

Here's realistic timeline for building XP systems in-house:

Week 1: Basic implementation. Track user actions. Award fixed points per action. Display totals. Works in development with sample data.

Week 2-3: Trigger system. Build configurable triggers for different actions. Implement threshold-based awards (points for every N actions). Make trigger configuration updateable without code changes.

Week 4-5: Economic balancing. Add tools to analyze point distribution. Implement rebalancing without disrupting existing users. Test point economy with realistic usage patterns.

Week 6-7: Analytics and history. Track which triggers award most points. Store historical point data for progress charts. Build reporting for understanding XP effectiveness.

Ongoing: Maintenance and tuning. As usage patterns change, point values need adjustment. New features need new triggers. This work continues indefinitely.

That's 7+ weeks of engineering time plus ongoing maintenance. Trophy's infrastructure eliminates this timeline, reducing implementation to 1 day to 1 week of integration work.

Building with Trophy

Trophy's integration is faster because XP infrastructure already exists. Here's what implementation looks like.

Step 1: Create Points System

In Trophy's dashboard, create a points system called "XP" (or whatever name fits your product). Configure optional settings like maximum points per user if you want caps.

Trophy supports multiple points systems simultaneously. You might have XP for overall progress and separate currency for other purposes. Each system tracks independently.

Step 2: Configure Point Triggers

Point triggers define how users earn XP. In Trophy's dashboard, create triggers for each way users should earn points:

Metric-based triggers award points when users reach metric thresholds:

Award 10 XP for every task completed
Award 50 XP for every 5 lessons finished
Award 100 XP for every workout logged

Achievement-based triggers award points when users complete achievements:

Award 500 XP for completing the "Power User" achievement
Award 1000 XP for reaching 30-day streak milestone

Streak-based triggers award points for streak milestones:

Award 50 XP for every 7-day streak
Award 200 XP for 30-day streak milestone

User identification triggers aware points to users the moment that they are first identified with Trophy:

Award 100 XP at sign up

Trophy processes these triggers automatically when relevant events occur. No manual point awarding needed.

Step 3: Track User Actions

Send events to Trophy when users perform actions:

import { TrophyApiClient } from '@trophyso/node';

const trophy = new TrophyApiClient(process.env.TROPHY_API_KEY);

// When user completes a task
await trophy.metrics.event('task_completed', {
  user: {
    id: 'user-123'
  },
  value: 1 // 1 task completed
});

Trophy processes the event and automatically:

Checks which point triggers apply
Awards appropriate XP based on trigger configuration
Updates user's total XP
Returns award details in the response

The response includes point awards:

const response = await trophy.metrics.event('task_completed', {
  user: {
    id: 'user-123'
  },
  value: 1
});

// Check if user earned XP
if (response.points?.xp) {
  const xpAwarded = response.points.xp.added;
  const newTotal = response.points.xp.total;
  console.log(`Earned ${xpAwarded} XP! Total: ${newTotal}`);

  // Show which triggers fired
  response.points.xp.awards.forEach(award => {
    console.log(`${award.trigger.points} XP from ${award.trigger.name}`);
  });
}

Step 4: Display User XP

Fetch user's XP total and recent awards:

// Get user's current XP with recent awards
const xp = await trophy.users.points('user-123', 'xp', {
  awards: 10 // Include last 10 XP awards
});

console.log({
  total: xp.total, // Total XP
  recentAwards: xp.awards.map(award => ({
    amount: award.points,
    trigger: award.trigger.name,
    timestamp: award.timestamp
  }))
});

This provides data for displaying XP totals and recent earning activity. The points API documentation covers all available query options.

Step 5: Display XP Progress Over Time

For charts showing XP earned over time:

// Get XP summary aggregated by day for last 30 days
const response = await trophy.users.pointsEventSummary('user-123', 'xp', {
  aggregation: 'daily',
  startDate: '2025-09-17',
  endDate: '2025-10-17'
});

// response.data contains daily XP totals for charting
response.data.forEach(day => {
  console.log(`${day.date}: ${day.total} XP`);
});

Trophy returns chart-ready data aggregated by day, week, or month. Use this for progress visualizations showing users their XP growth.

Point Trigger Strategies

Effective XP systems use multiple trigger types that serve different goals.

Consistent action rewards drive habit formation. Award the same XP amount every time users complete core actions. 10 XP per task completed. 5 XP per lesson reviewed. Users learn what actions are "worth" and build routines.

Milestone rewards celebrate progress. Award bonus XP at thresholds. 50 XP for 10th task. 200 XP for 50th task. These create goal posts beyond the core action loop.

Variety rewards encourage exploration. Award XP for trying different features. 20 XP for first time using advanced editor. 30 XP for completing different task types. This drives feature discovery.

Achievement rewards recognize special accomplishments. Award large XP amounts when users complete difficult achievements. 500 XP for mastery achievement. This creates high-value moments worth pursuing.

Trophy's trigger configuration supports all these patterns through dashboard settings. Test different combinations to find what drives engagement in your product.

Economic Balance

XP systems need economic design to prevent inflation and maintain meaning.

Relative values matter more than absolute amounts. Users don't care if they have 1,000 XP or 1,000,000 XP. They care about progression rate and comparisons to others. Design trigger values relative to each other, not based on absolute numbers.

Progression curves should feel good. Early users should earn XP quickly (fast positive feedback). Late users should still progress but at reasonable pace. Trophy's analytics show XP distribution across users, helping you tune progression.

Rebalancing capability is critical. As your product evolves, point values need adjustment. Trophy's trigger configuration makes rebalancing simple. Change values in dashboard. New events use new values. Existing XP remains unchanged, preventing user disruption.

Monitor XP distribution regularly. If everyone has millions of XP, values might need adjustment. Trophy's analytics dashboard shows distribution curves, helping identify inflation.

Handling Retroactive Changes

When you add new point triggers or change existing values, existing users have legitimate concerns about fairness.

Grandfathering means existing XP remains unchanged when you adjust values. Users keep what they earned under old rules. New actions use new values. This prevents disruption but creates inconsistency over time.

One-time bonuses can smooth transitions. When rebalancing downward, give existing high-XP users a one-time bonus so they don't feel penalized. Trophy's dashboard lets you create special one-time awards.

Clear communication about changes prevents confusion. "We're rebalancing XP to better reflect action value" explains the change. Users accept adjustments when rationale is clear.

Trophy's event sourcing means you can see exactly how users earned their XP. This transparency helps make fair decisions about retroactive changes.

Display and Communication

How you present XP affects user motivation.

Prominent placement for XP totals. Users should easily see their current XP and recent earnings. Trophy provides totals via API for display anywhere in your UI.

Immediate feedback when earning XP. Show "+10 XP" animations when users complete actions. Trophy's event response includes XP awards for immediate display.

Progress context helps users understand their XP. "You earned 250 XP this week, up 50 from last week" provides meaningful comparison. Trophy's summary API enables these comparisons.

Trigger transparency shows users how to earn more. "Complete 5 more tasks to earn 50 XP bonus" creates clear goals. Trophy's trigger configuration can be exposed to users through your UI design.

Analytics and Optimization

Trophy provides analytics showing XP system health.

Distribution curves show how XP spreads across your user base. Healthy systems show smooth progression from new users to power users. Clustering indicates problems in trigger design.

Trigger effectiveness shows which awards drive behavior. If users rarely hit certain triggers, they might be too difficult or poorly communicated. Trophy's analytics show trigger fire rates.

Earning velocity shows how quickly users accumulate XP. Compare early user velocity (first 30 days) to later velocity. Dramatic drops suggest progression issues.

Retention correlation reveals whether XP drives engagement. Do users who earn more XP retain better? Trophy's data combined with your retention analytics answers this question.

Use these insights to refine trigger values and introduce new ways to earn XP that drive behavior you want to encourage.

Common Implementation Mistakes

Teams integrating Trophy make predictable errors.

Too many triggers initially. Start with 5-10 core triggers covering primary user actions. Add more based on usage patterns. Trophy makes adding triggers easy, so start focused.

Ignoring trigger analytics. Trophy shows which triggers fire frequently and which don't. If triggers never fire, they're misconfigured or targeting rare behavior. Adjust based on data.

No progression structure. Award the same points for beginner and expert actions creates flat experience. Design trigger values that recognize increasing mastery. Trophy's flexible triggers support progression design.

Blocking user actions on Trophy responses. Trophy is fast, but don't block critical flows waiting for API responses. Track events asynchronously when possible.

Forgetting about inflation. Point values that seem balanced at 1,000 users might create inflation at 100,000 users. Monitor distribution curves and rebalance proactively.

Build vs. Buy Decision

Here's how to think about build versus buy for XP:

Build in-house when:

Your XP mechanics are so unusual platforms don't support them
You have backend engineers with capacity for 2-3 months plus maintenance
Engineering control over infrastructure is critical to your business
Scale is small enough that simple implementations work (under 1,000 users)

Use Trophy when:

You want XP features in days, not months
Trigger flexibility and rebalancing are important
Engineering time is better spent on core features
Analytics about XP effectiveness matter

Trophy's implementation guide covers the complete integration process. Most teams implement basic XP functionality in 1-2 days, advanced triggers and analytics in 3-5 days. Compare this to 2-3 months building from scratch.

FAQ

How long does Trophy integration take for XP?

Basic XP tracking: 1-2 days including trigger configuration and event tracking. Advanced features like custom trigger logic and detailed analytics: 3-5 days. Compare this to 2-3 months building in-house.

Can we adjust point values after launch?

Yes. Trophy's dashboard configuration means changing point values requires no code deployment. Adjust trigger values and new events use new amounts. Existing XP remains unchanged unless you explicitly choose to adjust it.

How do we prevent XP inflation?

Monitor distribution through Trophy's analytics. If concentration gets too high, adjust trigger values downward. Trophy's granular trigger control makes rebalancing straightforward without affecting existing user XP.

What if we want different XP rates for different users?

Trophy's user attributes enable segment-specific triggers. Award different XP amounts based on user level, subscription tier, or other attributes. Configure this through Trophy's dashboard.

Can users spend XP?

Trophy tracks XP totals. Implementing spending mechanics (point sinks) happens in your application. You can track spending as negative-value events that reduce XP totals, or implement separate spending tracking in your system.

How do we test XP changes without affecting real users?

Trophy supports multiple environments (staging, production). Test trigger configurations in staging before deploying to production. Trophy's event processing is deterministic, so staging tests accurately predict production behavior.

What happens if Trophy's API goes down?

Design your integration to degrade gracefully. Queue events for retry. Show cached XP totals. Most teams find Trophy's uptime meets or exceeds what they'd achieve with in-house infrastructure.

How to Build a Streaks Feature

Charlie Brinicombe — Fri, 17 Oct 2025 11:14:47 +0000

You decide to add a daily streak feature. Track consecutive days of user activity. Should be straightforward. Three weeks later, you're debugging why users in different time zones lose streaks unfairly, handling edge cases around daylight saving time, and dealing with race conditions when users act near midnight.

Streak tracking seems simple until you implement it. The core logic (did user act today?) hides complexity in "today." Whose today? Server time creates unfair advantages. User time zones require careful handling. Midnight boundaries need grace periods. Consistency matters because broken streaks feel like lost investment.

Trophy handles streak tracking including time zones, streak freezes, and edge cases. The complete implementation guide covers the full process. Integration takes 1 day to 1 week. But understanding what building from scratch involves helps you make informed build versus buy decisions.

Key Points

Technical challenges that make streak tracking harder than it appears
Time zone handling and consistency requirements
Implementation patterns for scalable streak systems
Integration examples with Trophy's API
Build versus buy considerations for streak features

The Technical Reality

Before building streak tracking, understand the problems you're solving.

Time zone fairness requires per-user calculations. A user in Tokyo and a user in New York shouldn't compete on different playing fields. Server-time streaks give systematic advantages to users in certain time zones. Implementing time zone handling correctly takes weeks and ongoing maintenance as time zone rules change.

Consistency guarantees prevent race conditions. If a user acts at 11:59 PM and 12:01 AM, that's one action or two depending on timing. Concurrent requests near midnight create edge cases. Without proper handling, users might extend streaks twice for one action or lose streaks despite acting.

Streak freeze logic adds complexity. Users need forgiveness for missed days without making streaks meaningless. Tracking freeze counts, granting new freezes over time, and applying them correctly when streaks would break requires careful state management.

Historical data for streak calendars and analytics needs efficient storage and querying. Showing users their past year of activity means storing and retrieving daily status. This grows linearly with users and time.

DST transitions create days that are 23 or 25 hours long. Naive date math breaks. Users might lose streaks on spring-forward days or extend twice on fall-back days without proper handling.

Building production-ready streaks typically takes 1-2 months including edge cases and testing. Trophy's infrastructure handles these problems, reducing implementation to integration work.

Architecture Patterns

If building in-house, these patterns avoid common mistakes.

Event-based tracking separates user actions from streak computation. Store time stamped events. Compute streak status from event history rather than maintaining streak counters directly. This enables accurate historical queries and simplifies consistency.

Per-user timezone storage lets you compute streaks in user-local time. Store user timezone preferences. Convert all streak calculations to user-local time. This requires timezone libraries that handle DST correctly.

Grace periods around midnight prevent losing streaks from being minutes late. Allow actions within 3-6 hours after midnight to count for the previous day. This reduces anxiety without meaningfully weakening consistency incentives.

Eventual consistency in streak display is acceptable. Showing slightly stale streak counts for a few seconds doesn't affect user experience. Prioritize correctness over real-time updates. Trophy's architecture uses eventual consistency with fast convergence (milliseconds to seconds).

Precomputed streak state for active users improves query performance. Maintain current streak length in fast storage (Redis or similar). Recompute from event history only when needed. This pattern scales better than computing from scratch on every query.

Trophy uses event-based architecture with timezone-aware computation and cached state. This combination provides both correctness and performance without requiring you to implement it.

Implementation Estimate

Here's realistic timeline for building streaks in-house:

Week 1: Basic implementation. Track user actions. Simple consecutive-day logic. Works in development with sample data.

Week 2: Time zone handling. Per-user timezone storage. Converting calculations to local time. Handling timezone changes when users travel.

Week 3: Streak freezes. Implementing freeze grants, consumption, and limits. Making freeze logic interact correctly with streak extension.

Week 4-5: Edge cases. DST transitions. Grace periods. Race conditions near midnight. Historical data queries for calendar views.

Ongoing: Maintenance. Time zone rule updates. Bug fixes for edge cases discovered in production. Performance optimization as usage scales.

That's 5+ weeks of engineering time plus ongoing maintenance. Trophy's infrastructure eliminates this timeline, reducing implementation to 1 day to 1 week of integration work.

Building with Trophy

Trophy's integration is faster because streak infrastructure already exists. Here's what implementation looks like.

Step 1: Configure Streak Settings

In Trophy's dashboard, configure your streak frequency (daily, weekly, or monthly) and select which metrics should extend streaks.

For example, if users should maintain streaks by completing lessons, select your lessons_completed metric. Trophy handles streak logic automatically when events arrive for that metric.

Configure streak freezes if desired: initial freeze count for new users, freeze accumulation rate, and maximum freeze count. Trophy grants and consumes freezes automatically based on your settings.

Step 2: Identify Users with Timezones

When identifying users with Trophy, include their timezone for accurate streak tracking:

import { TrophyApiClient } from '@trophyso/node';

const trophy = new TrophyApiClient(process.env.TROPHY_API_KEY);

// Identify user with timezone
await trophy.identify('user-123', {
  name: 'Joe Bloggs'
  tz: 'America/New_York' // User's IANA timezone identifier
});

Trophy uses this timezone for all streak calculations. If users travel, update their timezone and Trophy adjusts streak windows accordingly. This ensures fair streak tracking globally.

Step 3: Track Metric Events

Send events when users perform actions that should extend streaks:

// When user completes a lesson
await trophy.metrics.event('lessons_completed', {
  user: {
    id: 'user-123'
  },
  value: 1 // 1 lesson completed
});

Trophy processes the event and automatically:

Determines if it extends the user's streak based on their local timezone
Applies streak freezes if the user missed days
Updates streak length and history
Returns the updated streak status in the response

The response includes the user's current streak information:

const response = await trophy.metrics.event('lessons_completed', {
  user: {
    id: 'user-123'
  },
  value: 1 // 1 lesson completed
});

if (response.currentStreak?.extended) {
  // User extended their streak with this action
  console.log(`Streak length: ${response.currentStreak.length}`);
}

Step 4: Display Streak Information

Fetch user's streak status to display in your app:

// Get user's current streak
const streak = await trophy.users.streak('user-123');

console.log({
  length: streak.length, // Current streak length (e.g., 15)
  started: streak.started, // When streak started
  expires: streak.expires, // When streak expires in user's timezone
  freezesRemaining: streak.freezes // Number of freezes available
});

Trophy's API returns comprehensive streak data including expiration time in the user's local timezone. Use this for reminder notifications or UI that shows time until streak expires.

Step 5: Display Streak History

For calendar views showing past activity:

// Get streak with historical data
const streak = await trophy.users.streak('user-123', {
  historyPeriods: 90 // Last 90 days of history
});

// streak.streakHistory contains daily activity for calendar display
streak.streakHistory.forEach(period => {
  console.log(`${period.periodStart}: streak length ${period.length}`);
});

Trophy returns activity data for building calendar visualizations. The user streak API documentation covers all available fields and query options.

Handling Edge Cases

Production streak systems encounter edge cases that development testing misses. Trophy handles these automatically.

Users crossing time zones should have streaks follow them. If a user flies from California to Japan, their streak window shifts to Japan time. Trophy tracks user timezone and adjusts automatically when you update it.

Midnight action ambiguity needs clear rules. Trophy's grace period logic allows actions shortly after midnight to count for the previous day. This prevents losing streaks from being minutes late while maintaining meaningful consistency.

Daylight saving transitions create 23-hour or 25-hour days. Trophy's date math accounts for DST, ensuring users don't lose streaks on transition days due to calendar arithmetic.

Concurrent actions near midnight could double-count or create race conditions. Trophy's event processing ensures each action counts correctly for exactly one day, regardless of concurrency.

Freeze consumption timing affects user experience. Trophy applies freezes automatically when users would otherwise lose streaks, transparently maintaining their investment without manual intervention.

These edge cases take weeks to discover and fix when building in-house. Trophy's production experience means they're already handled correctly.

Streak Freeze Implementation

Streak freezes let users miss days without losing streaks. How streak freezes keep users engaged explores the psychology and strategy behind forgiveness mechanics.

Trophy's freeze system includes:

Initial freeze grant : New users receive configured initial freezes
Automatic accumulation : Users gain freezes over time based on your configuration
Maximum limit : Freeze count caps at your configured maximum
Automatic consumption : Trophy consumes freezes when users miss days
Transparent tracking : Users see remaining freeze count in API responses

Configure these in Trophy's dashboard without code changes. Testing different freeze strategies requires updating configuration, not rewriting logic.

// Streak response includes freeze information
const streak = await trophy.getStreak('user-123');

console.log({
  freezesRemaining: streak.freezes,
  maxFreezes: streak.maxFreezes,
  freezeAutoEarnAmount: streak.freezeAutoEarnAmount,
  freezeAutoEarnInterval: streak.freezeAutoEarnInterval
});

Notification Strategy

Streak reminders help users maintain consistency without creating anxiety. Trophy's email system handles notification timing automatically.

Configure streak emails in Trophy's dashboard:

Customize message content using a no-code email builder
Target specific user segments if needed

Trophy sends notifications based on user timezone, ensuring reminders arrive at appropriate local times. No manual timezone handling required.

Performance Considerations

Trophy's infrastructure is built for scale, but your integration patterns affect performance.

Cache streak data for display in high-traffic areas. Streak counts don't need real-time accuracy. Cache for 30-60 seconds:

const cache = new Map();

async function getCachedStreak(userId: string) {
  const cached = cache.get(userId);
  if (cached && Date.now() - cached.timestamp < 60000) {
    return cached.data;
  }

  const fresh = await trophy.users.streak(userId);
  cache.set(userId, { data: fresh, timestamp: Date.now() });
  return fresh;
}

Handle API errors gracefully. Network issues happen. Don't block critical user flows:

try {
  const response = await trophy.metrics.event('lessons_completed', {
    user: {
      id: 'user-123'
    },
    value: 1
  });
} catch (error) {
  console.error('Failed to track event:', error);
}

Batch events when possible. If users perform multiple tracked actions in one session, Trophy's API handles batching efficiently.

Trophy handles backend scaling automatically. These client-side patterns optimize your application's performance without affecting Trophy's streak calculations.

Testing Strategies

Streak systems are hard to test because they depend on time. Trophy provides tools for testing without waiting days.

Test with different timezones to ensure fair handling. Create test users in various timezones and verify streak calculations work correctly for each. Trophy's timezone support means your integration code stays simple while handling global complexity.

Test across midnight boundaries by simulating actions at 11:59 PM and 12:01 AM. Verify streak extends correctly and grace periods work as expected. Trophy's APIs work consistently regardless of timing.

Test freeze consumption by having test users miss days. Verify freezes consume correctly and streaks maintain. Trophy's automatic freeze handling should work without special code paths.

Test DST transitions by simulating actions on transition days. These are the hardest edge cases. Trophy handles them, but verify your UI displays correctly during transitions.

Trophy's staging environment lets you test integration without affecting production data. The development guide includes testing strategies and example scenarios.

Build vs. Buy Decision

Here's how to think about build versus buy for streaks:

Build in-house when:

Your streak requirements are so unusual that platforms don't support them
You have backend engineers with capacity for 2-3 months of work plus maintenance
Engineering control over infrastructure is critical to your business
Scale is small enough that simple implementations work (under 1,000 users)

Use Trophy when:

You want streaks in days, not months
Time zone handling needs to be correct globally
Engineering time is better spent on core features
Maintenance burden should be minimized

Trophy's implementation guide walks through the complete integration process. Most teams complete basic streak functionality in 1-2 days, advanced features in 3-5 days. Compare this to 2-3 months building from scratch including time zones, freezes, and edge cases.

Understanding User Behavior

Trophy provides analytics showing streak distribution across your user base. Understanding what happens when users lose their streaks helps you design better forgiveness mechanics and communication strategies.

Monitor these patterns:

Average streak length across all users
Distribution of streak lengths (how many at 7 days, 30 days, 100+ days)
Freeze usage patterns (immediate consumption vs. accumulation)
Restart rates after breaks (do users return after losing streaks?)

Trophy's analytics dashboard shows these metrics. Connecting them to your retention data reveals whether streaks drive sustainable engagement or create pressure that leads to churn.

FAQ

How long does Trophy integration take for streaks?

Basic streak tracking: 1-2 days including user identification with timezones and event tracking. Advanced features like custom freeze logic or complex calendar views: 3-5 days. Compare this to 2-3 months building in-house.

What happens if Trophy's API goes down?

Design your integration to degrade gracefully. Queue events for retry. Show cached streak data. Most teams find Trophy's uptime exceeds what they'd achieve with in-house infrastructure given resource constraints. The event tracking documentation includes reliability guidance.

How do we handle users with unreliable internet?

Trophy's API is designed for reliability, but network issues happen. Implement retry logic with exponential backoff. Queue failed events locally. Trophy's idempotency support prevents duplicate processing when retrying.

Can we customize streak rules?

Trophy supports daily, weekly, and monthly streak frequencies. Grace periods are configurable. Freeze grants and limits are configurable. This covers most use cases. If you need truly custom streak logic, building in-house gives full control, but validate this need before committing to months of development.

How do we test without waiting days?

Trophy provides test environments where you can manipulate time for testing. Create test users, track events with different timestamps, and verify streak behavior without waiting. The development guide includes testing strategies.

What if we want to change streak settings later?

Trophy's dashboard configuration means changes don't require code deployments. Adjust freeze grants, streak frequency, or which metrics count toward streaks through configuration. Changes apply to future streak periods without affecting users' existing streaks.

How to Build a Leaderboards Feature

Charlie Brinicombe — Fri, 17 Oct 2025 10:55:20 +0000

You want leaderboards. You estimate three weeks. Six weeks later, you're still debugging edge cases around time zones and optimizing queries that timeout at scale.

Leaderboards look simple. Display a sorted list of users and their scores. But production leaderboards require handling concurrent updates, efficient ranking algorithms, time-based resets, and global scale. Most teams underestimate the complexity until they're deep in implementation.

Trophy solves these problems through purpose-built leaderboard infrastructure that integrates in 1 day to 1 week. The complete implementation guide walks through the full process. But understanding what building from scratch actually involves helps you make informed build versus buy decisions.

Key Points

Technical challenges that make leaderboards harder than they appear
Architecture patterns for scalable leaderboard implementation
Time and cost estimates for building versus using a platform
Integration patterns with Trophy for rapid implementation
Code examples for common leaderboard scenarios

The Technical Reality

Before starting implementation, understand what you're actually building.

Real-time ranking computation doesn't scale naively. Sorting millions of users on every score update kills database performance. You need incremental ranking algorithms, precomputed rankings, or approximate methods. Implementing these correctly takes weeks.

Concurrent update handling creates race conditions. Two users updating scores simultaneously can corrupt rankings if not handled atomically. You need proper transaction isolation or event-based processing. Getting this wrong creates subtle bugs that surface under load.

Time-based resets for daily, weekly, or monthly leaderboards require accurate timekeeping across time zones. When does a daily leaderboard end globally? Trophy handles time zones automatically, but building this yourself means implementing per-user timezone logic and handling daylight saving transitions.

Query optimization becomes critical at scale. Fetching top 100 users is fast. Finding a specific user's rank among millions is slow without proper indexing. Getting both rankings and nearby competitors in one query requires careful optimization.

Data consistency between score updates and rankings needs attention. Eventually consistent systems might show stale rankings. Strongly consistent systems sacrifice availability. Choosing the right consistency model matters.

Building production-ready leaderboards from scratch typically takes 3-6 months including all these considerations. Trophy's infrastructure handles them, reducing implementation to 1 day to 1 week of integration work.

Architecture Patterns

If you're building in-house, these patterns help avoid common pitfalls.

Event-based score updates separate writes from ranking computation. User actions create score events. A separate process computes rankings asynchronously. This pattern scales better than synchronous ranking updates but adds complexity.

Sorted sets in Redis provide efficient ranking operations. Redis ZADD and ZRANK commands handle concurrent updates and ranking queries efficiently. But you still need to handle persistence, time-based resets, and integration with your application data.

Precomputed materialized views in your database work for smaller scale. Create a rankings table updated via triggers or batch jobs. Query this table for leaderboards. This pattern is simpler but doesn't scale as well as Redis-based approaches.

Approximate counting using HyperLogLog or similar algorithms works when exact rankings aren't critical. Users outside top 1,000 might see approximate ranks like "~50,000" which is sufficient for most use cases.

Trophy uses event-based architecture with Redis-backed ranking computation, materialized in PostgreSQL for durability. This combination provides both performance and reliability without you needing to implement it.

Implementation Estimate

Here's a realistic timeline for building leaderboards in-house with a competent backend engineer:

Week 1-2: Basic implementation. Score tracking, simple ranking logic, API endpoints. Everything works in development with small data volumes.

Week 3-4: Performance optimization. Query optimization, caching, handling concurrent updates properly. Making it work at scale reveals the real challenges.

Week 5-6: Time-based resets. Implementing daily/weekly/monthly leaderboards with proper time zone handling. This is harder than it looks.

Week 7-8: Edge cases and testing. Race conditions, consistency guarantees, handling database failures gracefully. QA finds issues you didn't anticipate.

Ongoing: Maintenance and evolution. As usage grows, performance degrades. New features require system evolution. This maintenance burden continues indefinitely.

That's 8+ weeks of engineering time plus ongoing maintenance. At typical fully-loaded costs for a backend engineer, this represents significant development investment, plus opportunity cost of features not built.

Trophy's pricing is based on monthly active users. The cost comparison depends on your specific usage and engineering costs, but for many teams, platform costs become competitive with in-house development when factoring in both initial build time and ongoing maintenance.

Building with Trophy

Trophy's integration is significantly faster because the infrastructure already exists. Here's what implementation actually looks like.

Step 1: Set Up Metrics

Leaderboards rank users based on metrics. First, define what you want to track. In Trophy's dashboard, create a metric for the action you want to rank users by.

For example, if you're building a fitness app leaderboard ranking by workouts completed, create a workouts_completed metric. Trophy's dashboard makes this a form-fill operation taking seconds.

Step 2: Track Events

Send events to Trophy when users perform tracked actions. Here's an example using Trophy's API:

import { TrophyApiClient } from '@trophyso/node';

const trophy = new TrophyApiClient({ apiKey: process.env.TROPHY_API_KEY });

// When user completes a workout
async function handleWorkoutComplete(userId: string) {
  const response = await trophy.metrics.event("workouts_completed", {
  user: {
    id: "18",
    email: "user@example.com",
    tz: "Europe/London",
  },
  value: 1, // 1 workout completed
});

  // Response includes updated leaderboard positions if user is ranked
  console.log(response.leaderboards);
}

Trophy processes events in milliseconds and updates leaderboard rankings automatically. The response includes the user's updated leaderboard positions, which you can use to show real-time feedback.

Step 3: Create Leaderboard

In Trophy's dashboard, create a leaderboard configuration:

Choose the type of leaderboard (e.g "Metric").
Choose the metric to rank by (e.g., workouts_completed)
Set the time window (e.g. every 3 days, every 6 months or perpetual)
Configure maximum participants (up to 1,000)
Set start/end dates if time-limited

Trophy handles all ranking computation, time zone processing, and data storage. No code required for the leaderboard logic itself.

Step 4: Display Rankings

Fetch leaderboard data to display in your app:

// Get top 10 users on a leaderboard
async function getLeaderboard(leaderboardKey: string) {
  const leaderbooard = await trophy.leaderboards.get("weekly-words", {
    offset: 0,
    limit: 10,
    run: "2025-01-15" // The specific week to get rankings for
  });

  return leaderboard.rankings.map(ranking => ({
    userId: ranking.userId,
    rank: ranking.rank,
    value: ranking.value
  }));
}

The leaderboard API documentation covers all query options including querying historical rankings for previous leaderboard runs.

Step 5: Show Position Changes

Trophy tracks rank changes, making it easy to show users when they move up or down:

// The metric event response includes leaderboard changes
async function handleWorkoutComplete(userId: string) {
  const response = await trophy.metrics.event('workouts_completed', {
    user: {
      id: "user-id"
    },
    value: 1
  });

  // Check if user moved up in rankings
  const leaderboard = response.leaderboards['weekly_workout_leaderboard'];
  if (leaderboard && leaderboard.rank < leaderboard.previousRank) {
    const positionsGained = leaderboard.previousRank - leaderboard.rank;
    showNotification(`You moved up ${positionsGained} positions!`);
  }
}

This real-time feedback creates engaging user experiences without complex rank tracking logic on your side.

Time-Based Leaderboards

Time-based leaderboards that reset daily, weekly, or monthly require careful handling of time zones and reset logic. Trophy manages this automatically.

When you create a leaderboard with a time window (e.g., "every 7 days"), Trophy:

Tracks user scores within the current time period
Resets scores at period boundaries
Handles time zones so all users get fair competition windows
Finalizes rankings after all time zones complete the period
Archives past period results for historical reference

Your code stays simple. Just send events and fetch rankings. Trophy handles the complexity of time-based competition.

// Create events - Trophy handles which period they belong to
const response = await trophy.metrics.event('workouts_completed', {
  user: {
    id: "user-id"
  },
  value: 1
});

// Fetch current week's leaderboard
const currentWeek = await trophy.leaderboards.get('weekly_workout_leaderboard');

// Fetch specific past week using the 'run' parameter
const lastWeek = await trophy.leaderboards.get('weekly_workout_leaderboard', {
  run: '2025-10-10' // Start date of the period
});

Historical leaderboard data persists automatically. You can display past winners or track user improvement over time without additional database design.

Filtered and Segmented Leaderboards

Many products need multiple leaderboard views. Friends only. Same region. Same skill level. Trophy supports this through user attributes.

First, set user attributes when identifying users:

await trophy.users.identify("user-id", {
  name: "Joe Bloggs",
  attributes: {
    region: 'north_america',
    skill_level: 'intermediate'
  }
});

Then create filtered leaderboards in Trophy's dashboard using these attributes. The same metric events feed multiple leaderboards, but each leaderboard only ranks users matching its filters.

This enables sophisticated leaderboard structures without complex query logic:

Global leaderboard (all users)
Regional leaderboards (filtered by region)
Skill-level leaderboards (filtered by skill_level)
Friend leaderboards (filtered by custom friend relationships)

Trophy's user attributes system makes segmentation straightforward.

Performance Considerations

Trophy's infrastructure is built for scale, but your integration patterns affect performance.

Cache leaderboard data on your side for read-heavy scenarios. Leaderboard rankings don't need real-time accuracy for display. Cache for 30-60 seconds:

const cache = new Map();

async function getCachedLeaderboard(key: string) {
  const cached = cache.get(key);
  if (cached && Date.now() - cached.timestamp < 60000) {
    return cached.data;
  }

  const fresh = await trophy.leaderboards.get(key);
  cache.set(key, { data: fresh, timestamp: Date.now() });
  return fresh;
}

Fetch only needed data using Trophy's query parameters. Don't fetch all 1,000 participants if you only display top 10:

// Efficient: Only fetch top 10
const top10 = await trophy.leaderboards.get(key, { limit: 10 });

// Inefficient: Fetch everything then filter client-side
const all = await trophy.leaderboards.get(key);
const top10 = all.rankings.slice(0, 10); // Don't do this

Trophy handles backend scaling automatically. These client-side patterns optimize your application's performance.

Handling Edge Cases

Production leaderboards encounter edge cases that development testing misses. Trophy handles these automatically, but understanding them helps you design better user experiences.

Tied scores need tie-breaking logic. Trophy breaks ties using timestamps (earlier achievement ranks higher). Communicate this to users so ties feel fair rather than arbitrary.

New users entering full leaderboards need to displace the lowest-ranked user. Trophy handles this automatically when leaderboards reach their participant limit. Users must exceed the lowest score to enter.

Score corrections might require re-ranking. If you discover fraudulent activity and need to adjust scores, Trophy's event system lets you send corrective events that trigger re-ranking.

Deleted users should be removed from leaderboards. When users delete accounts, Trophy can remove them from active leaderboards while preserving historical accuracy.

These edge cases typically take weeks to discover and fix when building in-house. Trophy's production experience means they're already handled.

Build vs. Buy Decision Matrix

Here's how to think about the build versus buy decision for leaderboards specifically:

Build in-house when:

Your leaderboard requirements are unusual enough that platforms don't support them
You have backend engineers with spare capacity (rare)
Engineering control over infrastructure is critical to your business
Scale is small enough that simple implementations work (under 1,000 users)

Use Trophy when:

You want leaderboards in weeks, not months
Engineering time is better spent on core product features
You need proven infrastructure that handles scale and edge cases
Maintenance burden should be minimized

Most teams find that platform costs are competitive with the engineering time required to build and maintain leaderboards in-house, especially when considering opportunity cost.

Migration from Existing Systems

If you've already built leaderboards in-house but want to migrate to Trophy, here's the pattern:

Phase 1: Dual write. Send events to both your system and Trophy. Validate that Trophy's rankings match your implementation.

Phase 2: Comparison. Run both systems in parallel for a period. Compare rankings and ensure consistency.

Phase 3: Switch reads. Start fetching leaderboard data from Trophy instead of your system.

Phase 4: Decommission. Remove your leaderboard implementation after a safety period.

Trophy's event API makes this migration smooth. You can transition with minimal risk by running systems in parallel initially.

FAQ

How long does Trophy integration actually take?

For basic leaderboards: 1 day setup including authentication and event tracking implementation. A few extra days for UI development. For complex multi-leaderboard setups with segmentation, perhaps a day more Compare this to 2-3 months building from scratch.

What about vendor lock-in?

Trophy's event data is yours. Export it anytime via API. If you eventually want to move to in-house infrastructure, you can migrate your event history. But most teams find Trophy's value continues to justify the cost compared to maintenance burden.

Can Trophy handle our scale?

Trophy processes millions of events daily and supports leaderboards up to 1,000 participants. If you need larger leaderboards or higher volume, contact Trophy's team to discuss enterprise options.

What if Trophy's API goes down?

Design your integration to degrade gracefully. Queue events for retry. Show cached leaderboard data. Most teams find Trophy's uptime exceeds what they'd achieve with in-house infrastructure given resource constraints.

How do we handle real-time updates in our UI?

Trophy's APIs are fast enough for polling (every 30-60 seconds) without creating scaling issues. For true real-time updates, cache aggressively and update on user actions rather than polling. Trophy's event response includes updated rankings for immediate feedback.

Can we customize leaderboard rules?

Trophy's metrics can track any user action. Leaderboards can rank by any metric. User attributes enable filtered leaderboards. This combination covers most use cases. If you need something truly custom, building in-house might be necessary, but validate this before committing to months of development.

What's the alternative if Trophy doesn't fit?

Building in-house remains an option. Use the architecture patterns in this post. Budget 3-6 months of engineering time plus ongoing maintenance. For many teams, this investment exceeds Trophy's lifetime cost, but some requirements genuinely need custom infrastructure.

How we built a block-based template editor for gamification emails

Charlie Brinicombe — Sun, 13 Jul 2025 22:02:22 +0000

At the company I co-founded we recently released an interactive template editor for gamification emails (things like achievement notifications, weekly usage recaps, and re-engagement emails after periods of inactivity).

The initial goal was to basically implement a Notion-style document editor, but things got complex pretty quickly...

This post breaks down the different approaches we considered, where we ended up, and why we made the decisions we did.

Goals & Potential Approaches

We knew from the start that we wanted our template editor to have the following attributes:

Easy to use, even for non-technical users
Extensible so we can easily add more new block types over time
Low-maintenance (not too many dependencies, not prone to those small-but-impossible-to-debug issues that can be the bane of engineers’ existence)
Dynamic, with support for embedded variables and conditional rendering

We considered the following approaches.

Raw HTML + Handlebars With Previewer

SendGrid uses this approach in their dynamic templates feature:

SendGrid's approach

If we went this route, our emails would be able to contain pretty much anything, since users would have control over HTML, and something like Handlebars is powerful enough to do all sorts of conditional rendering and variable insertion.

The obvious downside is that this is quite complicated for non-technical users (potentially disqualifying) and a high barrier to entry even for technical users, since it takes a long time to get a nice looking email out of raw HTML.

A template library could help with this, but there’d still be more work involved in adapting a template to fit a company’s exact needs and brand.

Block-Based With Previewer

Prismic uses this approach for their marketing page editor:

Prismic's approach

The goal here is to have a set of reusable blocks that can be added and reordered on the page. The blocks are not WYSIWYG, so they can contain form fields and other controls. To see the end result, users must use the preview tool.

Text fields within blocks could support rich text using TipTap and variable insertion via Mustache or Handlebars, and there could be a “Conditional” block type to support conditional rendering of blocks depending on those variables.

The main advantage of an approach like this over raw HTML is that it lowers the barrier to entry drastically. Users no longer need to fiddle with HTML and CSS, nor do they need to know the intricacies of handlebars for conditional rendering. They just need to be able to drag/drop blocks around and understand the {{variableName}} syntax.

But, this approach is slightly less powerful than raw HTML and still requires a previewer tool to see how the email would actually look to its recipients.

Notion-Style Blocks (WYSIWYG)

This style is all the rage these days.

Notion's approach

This approach maintains the advantages of the regular block-based approach, but loses the need for a previewer, since blocks display exactly as they would to recipients. The user can simply place the cursor into a block and start typing to make changes.

The main downside here is specific to our use case: we really need to support conditional rendering of blocks, and it’s unclear how that could work in a design like Notion’s.

Experimentation

I started out with the Notion-style approach, using TipTap’s Notion-style editor template. The entire system of blocks was within the scope of TipTap, meaning the entire email template editor was the rich text editor.

Every block was a TipTap node and the user could navigate through the document using the arrow keys or clicking around to different areas.

This got clunky very fast, for a couple of reasons:

We needed block types that had their own text fields within them. That means we needed blocks to have an “edit state”, where when selected they’d no longer be WYSIWYG.

This sort of view & edit state at the block level does not work well within TipTap since we’d have to deal with the cursor navigating in and out of these, and text selection (can the user click & drag to highlight text from multiple blocks, even when one is in the edit state?).

Conditional blocks, as previously mentioned. There was no elegant way to get conditional rendering trees to look & feel good within a Notion-style editor.

We did however like the feel of being able to click into text and use a TipTap-powered rich text experience for italicizing, bolding, and inserting variables using Mustache syntax. TipTap is extensible enough to add things like dynamic menus that appear when you type {{, showing the plain-English variable names.

So rather than throwing this out completely and trying out the block-based approach with a previewer, we figured a hybrid approach would be worth a shot.

Specifically I tried the following:

Get rid of TipTap as the manager of the blocks, and instead only use it for rich text fields within blocks.
Create our own simple React component for managing the blocks.
Have a selection state so users can select one block on the page at a time. The selected block is displayed in an edit mode that shows the block’s fields and controls. All other blocks remain in view mode which is fully WYSIWYG.

This approach worked!

It allowed us to keep the user-friendliness of the Notion-style editor, but still support dynamic rendering (through a “Conditional” block that shows all conditional paths when in edit mode but only one when in view mode) and having multiple fields within each block. Here’s what the editor looks like in practice:

Our first version

And that conditional block I mentioned looks like this while being edited:

Conditional blocks

Fleshing Out the Editor

Once we’d settled on the approach it was just a matter of building out all the block types and handling variables correctly. There are a couple interesting bits that I’ll note here.

Variable Insertion

We went with Mustache as it’s the simplest template language with basically zero logic. We want these email templates to use Conditional Blocks for logic—the text editor only needs to support rendering variables.

To add Mustache to TipTap I wrote a custom extension, which also renders this nice dropdown menu with the available variables:

Using variables

I added a preview pane on the right-hand side where users can edit the preview variables used by Mustache to populate the template.

Adding "Smart" Blocks

The email editor needed to support blocks powered by Trophy that you don’t find in other, more generic email template systems. So far we’ve added:

Achievement progress charts: Shows a user’s progress toward a set of related achievements.

Achievement progress chart block

Achievement unlocked: Shows an achievement that the user just unlocked.

Achievement unlocked block

Metric progress chart: Shows a user’s progress over time on a particular metric.

Metric progress chart block

Streak: Shows the user’s current streak (if any).

Streak block

Takeaways

I learned quite a lot from this!

First and foremost: the Notion editor style isn’t for everyone. I think we just assumed that it would work by default, but different types of editors really do require different UX.

Aside from that, I must say that TipTap is getting better and better; I can’t imagine starting a new project in 2025 and going with a different solution for rich text editing.

Detailed docs on the template editor and how it works are available here.

Why affiliates should get equity, not cash

Charlie Brinicombe — Mon, 30 Jun 2025 14:11:42 +0000

Most B2C startups approach creator partnerships with a simple playbook: offer affiliate commissions and hope for the best. But according to Tim Johnson, who's managed creator communities at three major consumer apps including Wattpad (acquired for $600M), this approach is fundamentally flawed.

In a recent episode of the Levels Podcast, Tim shared hard-won insights from building creator communities at Wattpad, launching his own app Couply, and now scaling Blossom Social's network of 125+ finance creators. His biggest revelation? Sometimes giving away equity is the key to unlocking sustainable creator partnerships.

Why Traditional Affiliate Models Fall Short

The problem with pure affiliate models isn't just the uncertainty—it's human psychology. As Tim explains from his experience across multiple platforms:

"Most creators are going to say no to an affiliate model... they want guaranteed cash, right? If they can take a couple thousand dollars, they'll take that over some affiliate thing because they can't, they don't have faith that they'll be able to drive enough downloads."

This reality forces early-stage startups into an impossible position. They can't compete with established platforms offering guaranteed payments, but they also can't afford to pay creators upfront without proven ROI. The solution, Tim discovered, lies in thinking beyond traditional compensation models.

The Community-First Approach

At Blossom Social, Tim and his team cracked this puzzle by building something more valuable than cash: genuine community. Their 125-creator network operates on multiple levels of engagement, from tracking downloadable rewards to exclusive events and speaking opportunities.

"It can be really lonely being a creator, you know? So building that community people has been the key."

But the real breakthrough came when Blossom started offering creators equity in the company itself. This wasn't just about compensation—it was about alignment and belonging.

"I think Blossom has seen a very significant number of their creators invest their own personal money in the company as well. So now they own a piece of the company and they're helping grow it. I think that's super powerful."

When to Deploy the Equity Strategy

Tim's advice on timing is crucial: equity becomes most effective when you have product-market fit, but it shouldn't be reserved only for later stages. Looking back at his experience with Couply, he wishes he'd been more aggressive with equity from the beginning:

"If I'd have to do Couply again, I'd have been more generous with equity, with larger creators, and I'd have brought them on probably as paid... I would have got some more salaries out there and then brought them on in like formal capacity."

The key is identifying creators who are genuinely passionate about your space and want to build something lasting. For relationship content creators working with Couply, or finance creators joining Blossom, the app represents more than just another revenue stream—it's a platform for their life's work.

Structuring Creator Equity Deals

Tim recommends a multi-layered approach that combines several elements:

1. Equity Stakes for Key Creators Offer meaningful equity to creators who demonstrate long-term commitment and alignment with your vision.

2. Investment Opportunities Allow creators to invest their own money in funding rounds, deepening their financial stake in success.

3. Salary + Equity for Core Partners Bring top creators on as formal team members with both immediate compensation and long-term upside.

4. Community Benefits Maintain the intangible benefits that pure cash can't replicate—exclusive access, networking opportunities, and speaking platforms.

The Product-Market Fit Equation

One critical insight from Tim's experience: the effectiveness of equity-based creator partnerships depends heavily on your startup's trajectory.

"All of this changes when you have product market fit, by the way... If you have product market fit and you know that your company is going to be a fucking unicorn, then it's in their best interest to get some equity and invest."

But even without proven product-market fit, Tim argues the strategy is worth pursuing:

"It doesn't matter anyway, because if you don't have product market fit, you're dead anyway."

This perspective reflects a fundamental truth about early-stage startups: you need to take calculated risks to break through the noise, and creator equity can be one of your most powerful tools.

Lessons from the Trenches

Tim's biggest regret with Couply wasn't the app's challenges—it was waiting too long to prioritize creator relationships:

"I wish I had done that from day one... the things that stopped me from doing it was a sense of imposter syndrome... I didn't scale it. And I think if I'd have done that, really, really early on, it would have definitely helped the app grow bigger in a better way."

The lesson is clear: creator relationships aren't a nice-to-have for later-stage growth—they're foundational to building sustainable B2C products.

Making It Work for Early-Stage Startups

For founders without Blossom's resources to host cruises or major events, Tim's advice is simple: start with what matters most.

"I'd offered equity probably to the first few bigger creators that I could get on... equity plus affiliate plus the ability to invest in the product as well."

The goal isn't to replicate someone else's creator program—it's to build authentic relationships with people who believe in your vision and want to see it succeed.

Key Takeaways

Rethink affiliate models : Pure commission-based partnerships often fail because creators prefer guaranteed income
Lead with community : The most valuable thing you can offer creators is connection with like-minded peers
Use equity strategically : Offer ownership stakes to creators who demonstrate genuine commitment to your space
Start early : Don't wait for product-market fit to begin building creator relationships
Combine approaches : The most effective creator partnerships blend equity, cash, community, and growth opportunities
Think long-term : Focus on creators who want to build something lasting in your vertical, not just earn quick commissions

Building a creator community isn't just about growth—it's about creating a sustainable ecosystem where everyone wins. By thinking beyond traditional compensation models and embracing equity as a community-building tool, early-stage startups can compete with much larger platforms and build lasting partnerships that scale.

Want to hear more insights from Tim Johnson on building B2C apps, brand partnerships, and creator communities? Listen to the full episode of the Levels Podcast.

Building Community Over Compensation: Why Creators Need More Than Money

Charlie Brinicombe — Sun, 29 Jun 2025 14:09:32 +0000

When most B2C startups think about creator partnerships, the conversation typically starts and ends with money. How much should we pay? What's the going rate? Can we afford this influencer? But according to Tim Johnson, who's managed creator relationships at three successful consumer apps including Wattpad (acquired for $600M) and currently heads brand partnerships at Blossom Social, this cash-first approach is fundamentally flawed.

Tim recently joined the Levels Podcast to share insights from his unique journey across multiple B2C platforms, and his perspective on creator partnerships challenges conventional wisdom. At Blossom, he oversees relationships with 125+ finance creators, and what he's learned might surprise founders who think they need deep pockets to compete for creator attention.

The Creator Compensation Paradox

The reality of creator partnerships is more nuanced than most founders realize. As Tim explains:

"Most creators are going to say no to an affiliate model. Outside of that, there is the trips that Blossom throws. There's the speaking opportunities. There's the event series that we run... for creators, many of them have a specific creator that they might have followed or been inspired by, and getting to meet them, go on a cruise with them... It's incredibly valuable."

This insight reveals a fundamental truth: creators, like all professionals, are motivated by more than just immediate financial gain. They're building careers, seeking community, and looking for opportunities that advance their long-term goals.

What Creators Really Want

Tim's experience shows that successful creator partnerships are built on understanding what creators value beyond compensation:

Community and Connection : "It can be really lonely being a creator," Tim notes. The isolation of content creation makes community particularly valuable. At Blossom, creators don't just get paid – they get access to a network of 125 like-minded finance creators.

Professional Development : Speaking opportunities, masterminds, and events provide creators with career advancement that pure cash can't buy. These experiences help creators build their personal brands and expand their reach.

Exclusive Access : Being part of an inner circle, getting early insights, or having first access to new features creates a sense of exclusivity that money can't replicate.

The Equity Strategy

For startups with limited cash but big ambitions, Tim suggests a bold approach:

"If I'd have to do Couply again, I'd have been more generous with equity, with larger creators, and I'd have brought them on probably as paid... I think I would have got some more salaries out there and then brought them on in like formal capacity."

This equity-plus-affiliate model works particularly well when you have product-market fit. As Tim explains:

"If you have product market fit and you know that your company is going to be a fucking unicorn, then it's in their best interest to get some equity and invest."

At Blossom, many creators have actually invested their own money in the company, creating true alignment between the platform's success and the creators' financial outcomes.

Building Without Big Budgets

For early-stage companies that can't afford cruises or major events, Tim's advice is to start with what you can control:

Equity Over Cash : Give creators ownership in your success story. A small equity stake in a growing company can be worth more than one-time payments.

Create Exclusive Experiences : Even simple networking dinners or virtual masterminds can provide immense value to creators looking to connect with peers.

Facilitate Creator-to-Creator Value : Help your creators help each other. Introductions, collaborations, and cross-promotion opportunities cost nothing but create lasting relationships.

The Long-Term Advantage

This community-first approach creates a sustainable competitive advantage. While competitors might outbid you for individual creators, they can't easily replicate a thriving community. As Tim learned from his experience:

"Community is the core of everything that Blossom does. And it's building a creative community where people come in, make friends, meet other creators, boost each other's stuff. Like it's building a big friendship network."

Lessons for B2C Founders

Tim's insights offer several key takeaways for B2C founders looking to build creator partnerships:

Start with relationship building, not transactions : Think long-term partnerships, not one-off campaigns.
Understand creator motivations beyond money : Professional development, community, and exclusive access often matter more than cash.
Use equity strategically : When cash is limited, equity can align incentives and create deeper partnerships.
Build systems for scale : Managing 125+ creators requires structure, tracking, and clear progression paths.
Create genuine value : The best creator partnerships solve real problems for creators, not just for your startup.

Key Points

• Creator partnerships require more than just financial compensation to be successful

• Community building and professional development opportunities often outweigh pure cash incentive

• Equity partnerships can align creator success with company growth, especially for startups with limited budgets

• Building exclusive experiences and facilitating creator-to-creator connections creates lasting value

• A community-first approach creates sustainable competitive advantages that competitors can't easily replicate

• Even simple networking opportunities can provide immense value to creators seeking peer connections

• Managing large creator networks requires structured systems and clear progression paths

Want to hear more insights from Tim Johnson on building successful B2C apps? Listen to the full conversation on the Levels Podcast where he shares lessons from Wattpad's $600M exit and building brand partnerships at scale.

The Anti-ChatGPT Sales Approach: Why Personalization Still Wins

Charlie Brinicombe — Sat, 28 Jun 2025 14:06:28 +0000

In an era where AI-generated emails flood inboxes and ChatGPT-powered outreach has become the norm, one sales professional is bucking the trend with remarkable results. Tim Johnson, Head of Brand Partnerships at Blossom Social and former Head of Brand Partnerships at Wattpad (acquired for $753 million), has achieved something most salespeople can only dream of: an 80% response rate to his outbound emails.

On the latest episode of the Levels Podcast, Tim shared his contrarian approach to B2B sales that prioritizes human connection over automation, quality over quantity, and genuine relationship building over transactional interactions.

The Problem with AI-Powered Outreach

Tim's frustration with the current state of sales outreach is palpable. As someone who receives dozens of B2B emails daily, he's witnessed firsthand how AI has degraded the quality of business communication.

"I get outreach every single day by B2B folks. I had two which were customized. One was from Datadog and one was from TikTok. So of the outreach that I got, two were actually personalized to me and what I was doing. The rest were written by ChatGPT. And if you think that we can't tell, ChatGpt wrote your outreach email, then you're wrong. It's just so obvious, right?"

The tell-tale signs are everywhere: generic weather references, obvious template language, and a complete lack of understanding about the recipient's actual business or challenges. Tim describes the typical AI-generated approach:

"Like you can't even spend the time. You can only spend like one minute to actually see who I am. Why would I spend one minute in responding to you? No."

The Power of Genuine Personalization

What made those two successful outreach attempts stand out? They demonstrated actual research and provided real value. Datadog's email addressed Tim's specific business problems, while TikTok took a different but equally effective approach.

"TikTok invited me to a dinner to meet interesting creators in my vertical and meet other app founders. Are you fucking kidding me? You bet I'm going to that dinner, right? I wanna meet interesting creators, I meet app founders, like down straight, this is amazing."

This example illustrates a crucial principle: instead of pushing your message out, focus on attracting prospects to you by offering genuine value. The TikTok invitation wasn't just personalized—it was irresistible because it solved multiple problems for Tim simultaneously.

The Stag Hunt vs. Squirrel Hunt Philosophy

Tim's approach to sales is built around what he calls "stag hunting versus squirrel hunting"—a metaphor that fundamentally changes how you think about prospecting and client relationships.

"I think a stag hunt versus a squirrel hunt feels like a very, very different thing. With a stag hunt, you're organized, you are focused, you know what you're looking at. You're looking at this big creature that's gonna feed you for a long, long time, right? And it's a very, very deliberate process going towards working with that partner. Versus a squirrel, you're sort of like chasing after it, expending a bunch of energy, and then it's not gonna last long term anyway."

This philosophy drives Tim to focus on high-value prospects who meet specific criteria:

They have a repeating budget
They're consistently looking for your audience
They have a realistic timeframe for decision-making
They can integrate technically with your solution
Success metrics can be clearly defined and agreed upon

Building Relationships, Not Closing Deals

Perhaps most importantly, Tim rejects the traditional "closing" mentality that dominates sales training. His approach is more collaborative and relationship-focused.

"I wouldn't say that there's any like maybe the stag analogy like isn't good for the going in for the kill because there's this pressure in like sales of like closing... That's definitely not the way that I do sales because there's no big close. There's no like big reveal where you put this big price on and like you try and trap them into it somehow."

Instead, he uses an analogy of gradually building trust: "It's like a very ongoing process. I guess it's more like you have like this food and you're putting like the food towards the stag and the stag is coming towards you and then you're like putting like, can I put like a harness on you? And they're like, yeah, okay, you can put a harness. Okay, cool. Can I put this saddle on you? Is that okay?"

The Event-Based Relationship Strategy

One of Tim's most effective tactics involves hosting carefully curated events that bring prospects into his orbit naturally. Rather than cold outreach, he creates opportunities for meaningful connections.

"It's just as simple. It's a dinner or it's a small client event. I've got a nice bar, come, grab some cocktails and learn something and meet some people. It's a nice little mix of all three. See what your competitors are doing. You do that and you invite this person."

These events work because they address different personality types simultaneously: detail-oriented people are attracted by insights, socialites by networking opportunities, and competitive individuals by seeing what others in their space are doing.

Quality Over Quantity: The Four-Hour Video Principle

Tim draws inspiration from creator McKenna Murphy, who spends four hours creating a one-minute video. When questioned about this seemingly inefficient approach, Murphy explained: "I noticed if I spent four hours on my one minute video, it was more likely to get a million views. And if I spent less than four hours, then it would get between like 10K and 20K. So there's an outsize return on me spending longer on it."

This principle applies directly to sales outreach. The extra time invested in genuine personalization and relationship building yields dramatically better results than mass, generic outreach.

The Human Element in a Digital World

Tim's success ultimately comes down to treating prospects like human beings rather than entries in a CRM system. He emphasizes being "this fully fleshed out person that is interested in the space and has expertise" rather than "this one person that does one tool-like thing."

The key is becoming a valuable resource for your prospects—sharing industry insights, making introductions, and genuinely helping them succeed, whether or not they become customers.

Since joining Blossom, Tim has brought in around $2 million for the seed-stage company using these relationship-focused methods, proving that in an age of AI automation, the human touch remains irreplaceably valuable.

Key Takeaways

• Personalization beats automation : Even a few minutes of genuine research outperforms AI-generated templates

• Focus on "stag hunting" : Target fewer, higher-value prospects for long-term relationships

• Create value before asking for it : Host events, share insights, make introductions

• Build relationships, don't close deals : Think partnership, not transaction

• Quality over quantity : Better to send 10 thoughtful emails than 1000 generic ones

• Be a resource, not a vendor : Establish expertise and provide ongoing value to your network

Ready to learn more strategies for scaling your consumer app? Listen to the full conversation_ with Tim Johnson on the Levels Podcast._

Predicting the Next Big Thing: How Wattpad Spotted BTS Before Anyone Else

Charlie Brinicombe — Thu, 26 Jun 2025 14:02:10 +0000

In the world of B2C startups, data is often viewed through the lens of user engagement, retention metrics, and conversion rates. But what if your app's data could predict the next cultural phenomenon before it breaks into the mainstream?

This isn't science fiction—it's exactly what happened at Wattpad, the storytelling platform that identified BTS as the next big thing back in 2016, years before the Korean boy band became a global sensation.

On the latest episode of the Levels Podcast, we sat down with Tim Johnson, former Head of Brand Partnerships at Wattpad and current Head of Brand Partnerships at Blossom Social. Tim shared fascinating insights into how consumer apps can become crystal balls for cultural trends, and more importantly, how startups can monetize these predictive capabilities.

The Power of Fan Fiction as Cultural Indicator

Wattpad's ability to spot BTS early wasn't luck—it was data science in action. As Tim explained during our conversation:

"We knew in advance that BTS would be absolutely massive boy-bound. We knew it in 2016. I went and presented that to media agencies and marketing agencies and said, hey guys, there's this Korean band that's about to break the internet."

The secret weapon? Fan fiction. Wattpad's platform, which Tim describes as "like YouTube, but for books and stories," became an unexpected forecasting tool for entertainment trends. The platform's data showed an exponential rise in BTS fan fiction, signaling massive fan engagement before the band hit mainstream Western audiences.

"We were predicting that back in 2015, 2016. So yeah, that's kind of the way to leverage some of the insights... we could see the fan fiction start to rise exponentially. And with that, that meant it was an early signal that this band, this group was coming in."

From Data to Dollars: Monetizing Predictive Insights

Identifying trends is one thing; turning that knowledge into revenue is another. Tim revealed how Wattpad monetized their cultural forecasting abilities by packaging insights with other services for entertainment companies.

The value proposition was compelling: entertainment companies invest massive upfront costs in movies, TV shows, and other content, hoping for returns years down the line. Having early indicators of what will be popular provides a significant competitive advantage.

"For a movie company, you want to understand like what trends are happening and why are they happening. So that was very, very interesting to the entertainment industry to be able to predict things that are going to be big next year."

Tim noted that books serve as particularly strong early predictors for other entertainment formats. The BTS prediction proved prescient not just for the band itself, but for the broader wave of Korean cultural content that followed, including hits like Squid Game.

"That meant K-pop was gonna be getting big. That meant perhaps other things around like Korea or interest around Korea was gonna get big. You start to see a lot more Korean based books. And I mean, that was been absolutely true."

The ASSET Framework for Network Effects

Wattpad's predictive capabilities stem from their network effects, which Tim breaks down using the ASSET framework developed by Wattpad's founders:

A tomic unit: The core value driver (books on Wattpad, portfolios on Blossom)
S eed supply: Bringing on creators and content
S cale demand: Advertising to bring in users
E nlarge network effects: Users become contributors
T rack proprietary insights: Data becomes valuable

The "T" in this framework—tracking proprietary insights—is where the magic happens for trend prediction. As Tim explains:

"This is the idea of now your data that you're building, your data set becomes valuable... These proprietary insights become very valuable as well."

Lessons for B2C Startups

For startup founders, Wattpad's story offers several key takeaways:

1. Your User Data is More Valuable Than You Think Consumer behavior patterns on your platform might reveal trends beyond your immediate industry. Whether it's reading preferences, investment choices, or relationship patterns, user behavior can signal broader cultural shifts.

2. Package Insights with Core Services Rather than selling raw data, Tim suggests packaging insights with other valuable services. Wattpad bundled trend predictions with IP partnerships and first-look deals for entertainment companies.

3. Focus on Leading Indicators Books proved to be leading indicators for broader entertainment trends. Consider what leading indicators might exist within your user base and industry.

4. Think Beyond Direct Monetization While Wattpad's primary revenue came from brand partnerships, their trend prediction capabilities added significant value to these relationships and opened new revenue streams.

Building Your Own Crystal Ball

Tim's experience at both Wattpad and now Blossom Social demonstrates that any consumer platform with engaged users can potentially develop predictive capabilities. At Blossom, they're applying similar principles to investment trends:

"With Blossom, we can see what investors are investing in in real time, which is even more valuable because we can see where the market is going immediately. We can also see sentiment across different verticals of investing."

The key is recognizing that your users aren't just customers—they're early adopters whose collective behavior might predict broader market movements.

Key Takeaways

Consumer app data can serve as powerful early indicators for cultural and market trends
Fan fiction and user-generated content often signal mainstream trends before they break
Predictive insights become valuable when packaged with other services for B2B clients
The ASSET framework helps identify where proprietary insights fit into your network effects
Entertainment companies and other industries value early trend identification for strategic planning
Books and storytelling platforms can be particularly strong predictors for broader entertainment trends

Want to hear more insights from successful B2C founders? Listen to the full conversation with Tim Johnson on the Levels Podcast, where we dive deep into brand partnerships, network effects, and building consumer apps that scale.

Why I shelved my mobile app after 500k downloads

Charlie Brinicombe — Thu, 26 Jun 2025 13:55:13 +0000

Not every startup needs to become a unicorn to be successful. Sometimes the most valuable lesson an entrepreneur can learn is when to pivot from venture-scale ambitions to building a sustainable, profitable business. This is exactly what Tim Johnson discovered with Couply, his couples relationship app that achieved impressive early metrics but ultimately taught him that product-market fit doesn't always equal venture scalability.

In a recent episode of the Levels Podcast, Tim Johnson—former head of brand partnerships at Wattpad (acquired for $753M CAD) and current head of brand partnerships at Blossom Social—shared the candid story of how he transitioned Couply from a struggling startup to a profitable side project. His journey offers valuable insights for B2C founders facing similar crossroads.

The Early Promise and Hidden Challenges

Couply started with all the right signals. Tim had identified a clear gap in the market while reading relationship books with his girlfriend:

"I thought, it'd be really cool if I could like go through this with my girlfriend. But I don't want to go through it with her in a book. Why do we have to mark this stuff down on paper and answer, do these quizzes, and then answer it up at the bottom? Why don't we do this in an app?"

The initial validation was strong. Tim bought the domain, created a landing page, and ran Google ads that achieved a remarkable 5% click-through rate for waitlist signups. The app eventually reached 500,000 downloads organically and became the number one couples app on Google Play Store.

However, beneath these impressive metrics lay a fundamental problem that would prove impossible to solve within their runway.

The Four Horsemen of Churn

Tim discovered what he calls the "four horsemen of the churn apocalypse"—a unique retention challenge that plagues problem-solving consumer apps, particularly those requiring two users:

"People wanted to use Couply to solve their problems, and then they churn. So they both like it. They both like it, and it works. They churn. Neither of like it. They churn. One likes it, one doesn't like it. Well, it's a couples app, so it needs both of you doing stuff. They churn. The other one likes it, the other one doesn't. Same thing, churn."

This insight reveals a critical challenge for consumer apps that solve immediate problems rather than providing ongoing entertainment or utility. Couply became a tool that couples used when their relationship was "in a pickle," but once the problem was solved, users naturally moved on.

Recognizing the Inflection Point

The decision to pivot wasn't made lightly. Tim and his co-founder had built a product that users genuinely loved and that effectively solved relationship problems. But loving a product and continuing to use it are two different things:

"The more I spoke to users, so Couply is an app that helps couples get out of a, when they're in a bit of a pickle. So every relationship goes through ups and downs, right? And when your relationship is going through a down phase, you need help, you need help fast."

Tim realized that Couply had become the relationship equivalent of emergency services—essential when needed, but not something people wanted to keep around once the crisis passed. The app's success as a problem-solver was actually limiting its potential for sustained engagement.

The Strategic Transition

Rather than continuing to burn through runway fighting an unsolvable retention problem, Tim made the strategic decision to transition Couply to a side project:

"I felt like it would be better served as a more of like a side project. So the company became a side project for us and that left me open to get back into the game."

This wasn't a failure—it was a recognition that different business models serve different purposes. The transition allowed Tim to:

Preserve the value they'd already created
Generate sustainable passive income
Free up time and energy for new opportunities
Work toward paying back investors

Building Sustainable Passive Income

Today, Couply operates as a profitable side project that demonstrates how consumer apps can generate sustainable revenue without venture-scale growth:

"Couply is profitable, it's making money, it's helping couples, and we are very close to paying all our investors back. And then it will make me and my co-founder an incredible passive income for as long as we keep it going."

The team maintains the app with minimal time investment—meeting for a few hours every weekend and conducting monthly team meetings. They've also maintained brand partnerships, working with companies targeting millennial couples, including therapy platforms like BetterHelp and Regain, as well as home insurance and mortgage companies.

Lessons for B2C Founders

Tim's experience with Couply offers several critical insights for consumer app founders:

Understand your app's natural usage pattern: Problem-solving apps have different retention characteristics than entertainment or utility apps. If your app solves a specific problem effectively, users may naturally churn after success.

Revenue diversification matters: Even as a side project, Couply maintains multiple revenue streams through subscriptions and brand partnerships, providing stability and growth potential.

Know when to pivot business models: Sometimes the most successful outcome isn't venture scale but sustainable profitability. Recognizing this early can preserve value and open new opportunities.

Leverage your experience: Tim's experience building Couply made him "so much more of a weapon" for subsequent startups, contributing to his success at Blossom Social.

Tim's journey from startup founder back to early-stage team member at Blossom demonstrates that there's no single path to success in consumer apps. Sometimes the most valuable thing you can build is the experience and expertise that will power your next venture.

Key Points

Product-market fit doesn't automatically equal venture scalability—some successful products are better suited to different business models
Problem-solving apps face unique retention challenges, especially those requiring multiple users
The "four horsemen of churn" can affect any app where success leads to natural user departure
Transitioning to a side project can preserve value while generating sustainable passive income
Brand partnerships can provide significant revenue even for smaller consumer apps
Founder experience from "failed" startups often becomes invaluable for future ventures

Ready to dive deeper into consumer app insights? Listen to the full conversation with Tim Johnson on the Levels Podcast where he shares more about building network effects, scaling brand partnerships, and growing B2C platforms.