Design Free Tiers That Convert Without Creating Resentment

This skill designs free tiers for developer tools that let developers build real things, demonstrate value, and convert to paid naturally rather than feeling like a trap. It first distinguishes four models - free trial (time-limited full access, best for high-touch enterprise sales), free tier (permanently free with usage/feature limits, best for self-serve developer tools), freemium (a free tier plus paid premium features), and open core (free open source with commercial additions, best for infrastructure/platforms) - and argues developer tools almost always need a permanent free tier rather than a trial, since developers build side projects and evaluate tools for future use over long horizons. It defines good limit dimensions that developers understand and that scale naturally with app growth - API calls/requests, compute resources, storage, seats - versus bad ones: time-based trials disguised as free tiers, arbitrary multi-dimensional feature combinations, and limits that punish success (like a hard active-user cap). It sets a "Goldilocks zone" test - allow meaningful real usage, cover hobbyist use cases fully free, trigger upgrades on growth rather than time, and stay easy to predict - illustrated with real limit structures from Vercel, Supabase, and PlanetScale. On feature gating, it lays out a principle (free tiers must support full evaluation, shipping a real project, and small-scale production use) with concrete keep-free items (core functionality, all SDKs/integrations, standard auth, basic monitoring, docs/community support) versus paid-gated items (collaboration/access-control features, higher scale/performance, and enterprise requirements like SSO, SLAs, and compliance), plus named anti-patterns to avoid (gating custom domains or CI/CD, time-locking "advanced features," requiring a credit card for production deploys). It documents five resentment triggers (hidden degradation, feature removal, surprise limits, contemptuous "unlock BASIC features" messaging, second-class support) and contrasts nagging upgrade prompts with contextual, threshold-based ones (70/85/95% usage warnings) and a five-point timing discipline (never interrupt workflow, warn before limits, explain the trigger, offer alternatives, don't repeat dismissed prompts). It covers the open-core model specifically - a clear open/commercial boundary, keeping the open-source edition genuinely useful rather than crippled, and the risk of a sudden relicensing rug-pull (naming HashiCorp, Redis, and Elastic as cautionary examples) - and closes with worked real-world cases: Stripe (no monthly fee, pay per transaction, unlimited test mode), Cloudflare (generous free bandwidth), MongoDB Atlas (512MB storage free forever), Algolia (usage scales with app success), GitHub's free-tier expansion over time, and GitLab's Community/Enterprise/SaaS split, alongside four named anti-pattern cases (hidden trial, feature prison, support desert, sudden rug pull).

Use it when designing or auditing a free tier, freemium model, free trial, or open-core commercial strategy for a developer tool - choosing which model fits the sales motion, setting usage limits, deciding what to gate behind paid tiers, writing upgrade-trigger copy, or building a pricing page. It recommends first reviewing a companion developer-audience-context skill, since free tier design differs materially for hobbyists versus startups versus enterprises, and understanding the actual unit cost of a free user. Do NOT use it to justify a time-limited free trial for a self-serve developer tool - the skill argues explicitly against that pairing - and do not use its limit-setting guidance to gate genuinely basic developer needs (custom domains, CI/CD, environment variables) behind a paywall, which it calls out as a direct anti-pattern.

Inputs: the target audience (hobbyist/startup/enterprise), the actual per-user cost structure, and the sales motion (self-serve vs high-touch). Outputs: a chosen tier model (free trial/free tier/freemium/open core) with specific limit dimensions and numbers, a free-vs-paid feature gating list, upgrade-trigger copy and timing rules, and pricing-page structure with an FAQ covering the questions every free-tier page needs to answer.

Names specific tools by category: usage tracking and metered billing (Lago, Metronome, Orb, Stripe Billing), feature flags for gating (LaunchDarkly, Flagsmith, PostHog), and conversion analytics (Amplitude, Mixpanel, ProfitWell). It also references companion skills - usage-based-pricing, developer-signup-flow, and developer-onboarding - for adjacent parts of the same funnel.

Product, growth, and pricing teams at developer-tools or infrastructure companies who need to design a free tier that supports real evaluation and hobby use while converting naturally as projects grow, without triggering the resentment that comes from hidden limits or feature removal.