I Make $5M/Year Giving My SaaS Away for Free

Company snapshot & headline outcome

• Tally (bootstrapped SaaS form builder) grew from ~$30–40k ARR/month (MR) in early years to ~$400k MR in recent reporting, reaching ~$5M/year ARR.
• User base: ~1.8M users with ~16,000 paying users (very large free-to-paid funnel).

Core strategy: simplicity + “forms are viral” distribution flywheel

The distribution/viral loop (explicitly described as a flywheel)

• Users create/share forms (viral by nature).
• More free users → more adoption → more form views/submissions → more discovery.
• Tally gives away a very generous free tier, so sharing happens without friction.
• Paid conversions come from free usage, not from heavy ads.

Product strategy principles

They emphasize:

• Keep the product simple to:
  • move fast with a small team,
  • reduce support load,
  • maintain an easy onboarding experience.
• Avoid “suite creep” (don’t become a Swiss-army tool).
• Build features only if they:
  • can ship in a small window (target: ~1–2 weeks for a simple version),
  • can (sometimes) be offered for free,
  • fit the vision: “simplest form builder” rather than adjacent categories (e-signing/CRM/etc.).

Monetization model (freemium mechanics + profitability)

Pricing structure

• Free tier is core to distribution (no account/credit card barrier to first value).
• Paid tier described as $29 (Tally Pro).

Economic rationale & conversion benchmark

• Conversion: ~2% of free users → paid (Tally Pro).
• Profitability lever:
  • early years hosting costs were low (notably Google Cloud billed < $1,000/month for a long period),
  • minimal marketing spend and careful spending discipline.
• Key constraint: support capacity—supporting tens of thousands of paid users with a small team is feasible if the product stays self-serve.

GTM / distribution channels & how growth changed

Early-stage growth tactics (bootstrap + feedback loop)

• Built everything themselves for ~3 years (including during personal time constraints).
• No big marketing budget; no early designer/branding; initially product-first (builder immediately).
• Acquired early customer insight through direct community contact:
  • DMs on Twitter,
  • people found on Product Hunt and Indie Hackers,
  • invited responders to Slack for feedback.

Customer feedback “system” (process playbook)

• Slack instead of calls (faster, more scalable, less confrontational).
• Workflow:
  • Ask for feedback asynchronously.
  • If requested improvements are clear and fit these criteria:
    • simplicity,
    • free-value,
    • roadmap signals,
  • then ship quickly.
• Keep a “no-lost-context” feedback database in Notion (they tracked what different users asked for).

Feature prioritization “evidence stack”

They described combining:

• user requests (including public roadmap / “years of data”),
• support ticket recurrence (“most important” signal),
• internal principles (simplicity, fast shipping, free-value where possible),
• vision fit (not expanding into unrelated tool categories).

LLM-driven discovery surge (mid/late 2024 into early 2025)

• Major growth inflection after noticing people found Tally via ChatGPT (LLMs).
• They attribute the change to:
  • being active for years on social + Reddit (social listening/pitching in relevant conversations),
  • help center content created to avoid answering the same question twice.
• Operational learning:
  • later invested in basic SEO hygiene (headings, URLs) and optimizing for search/AI retrieval.
• Outcome:
  • growth started with ChatGPT, then expanded as new LLM/AI “cloud” usage increased.
• They also plan to create more “content gaps” they can fill with simple pages that LLMs can pick up.

Operating model: how they scaled a small team

Team evolution

• First hire: customer support person (Richard) selected from the Slack community.
• Remote engineering was attempted, but communication/expectation issues led them to switch to in-house.
• Current shape mentioned:
  • ~10 people total
  • Phil (technical/product) + Mari
  • Marketing manager
  • Support team of 4
  • ~3 engineers (plus Mari/Phil total product/leadership)
• They emphasized a constraint: avoid scaling beyond ~10 because complexity increases.

Transition lesson (solo → team)

• Start with customer support to handle “edge cases” and community-surfaced backlog.
• Remote teams can fail if:
  • they lack prior remote operating systems,
  • expectations/communication aren’t aligned.

Explicit KPIs / targets mentioned

• ~$5M/year ARR (celebrated milestone).
• ~2M users approaching (free users).
• ~1.8M users / ~16k paying users at the time of the episode.
• Revenue growth pacing:
  • ~$5K MR → ~10K MR took ~1 year each (early growth ramp),
  • “Major change” led to $1M/year → $5M/year in ~12 months (recent acceleration).
• Conversion target benchmark: ~2% free → paid.
• Future targets (aspirational):
  • ~$7M ARR by end of this year / beginning next year
  • ~$10M ARR as the next major milestone (expected “a couple more years”).

Concrete example tactics they used

• Hotspots pivot during COVID:
  • The original hotel ↔ travel influencer marketplace became unviable when borders closed.
  • Pivoted to forms during lockdown brainstorming (leveraged their form-building experience).
• Tally-to-PDF feature:
  • They resisted for years (“PDFs? who uses PDFs?”) but it became one of the most requested features.
  • Still filtered through their criteria: ship simple version quickly, free/value logic, and vision fit.

Actionable recommendations / playbooks distilled from their approach

• Build a viral distribution loop into the core product (e.g., shareable artifacts like forms).
• Use freemium correctly:
  • free tier should be immediately valuable (no credit card, no long onboarding),
  • “Try for a day” won’t work; the user needs time to generate shareable outputs.
• Feature selection framework:
  • requested by users (and/or shows up repeatedly in tickets),
  • can ship a simple version in 1–2 weeks,
  • aligns with “keep it simple” + “avoid suite creep,”
  • ideally maintains growth economics (free where feasible).
• Feedback system:
  • prefer async community feedback (Slack/DM), not only calls,
  • maintain a structured “what users want” database (Notion),
  • close the loop quickly (“build it and announce it”).
• Growth experimentation priority:
  • don’t neglect SEO/AI discoverability; do “boring” technical fundamentals earlier.
• Hiring sequencing:
  • hire support early when volume grows and community insights become operational load.

Market / LLM angle (high level, execution-focused)

• They don’t frame this as “investing” but as a discoverability shift:
  • LLMs/AI assistants can surface your product via help-center content + online mentions.
• They respond by:
  • improving content structure,
  • mapping product FAQs into indexable / LLM-retrievable assets,
  • keeping product friction low and accessible via agents (they mention MCP integration conceptually).

Presenters / sources

• Mari (co-founder of Tally; subject of the case study)
• Philip (technical co-founder; referenced throughout)
• Host / Interviewers: not clearly named in the subtitles (only referred to in “my question/episode host” style)