Theme

Start for free

Developer tools

For developer tools: which READMEs, posts and docs bring developers whose teams pay.

Developer tools are adopted bottom-up: one developer finds the tool through a README, a post or an assistant, tries it on a side project and later gets a team to pay. Tally ties each plan to the visits behind it, and the command line and MCP server answer revenue questions without leaving the terminal.

Start for free

14 days free, no card needed.

01How they sell

  • SubscriptionPer-seat team plans, monthly or yearly, often with a discount or no charge at all for open-source projects.
  • FreemiumA free individual tier, with team features such as shared config, SSO or audit logs on paid plans.
  • UsageSome bill by builds, minutes, requests or active seats each month.

02Payments it reads

  • StripeTeam plans and usage through Stripe subscriptions; added seats, renewals and refunds are read.
  • PolarChosen by developer tools that want billing built for developers; orders, subscription cycles and lost disputes are read.
  • PaddleDeveloper tools selling to companies worldwide use Paddle as merchant of record; transactions and adjustments are read.
  • Lemon SqueezyIndie developer tools sell licences through Lemon Squeezy with licence keys.

What Tally can't read

  • Plans bought through GitHub Marketplace are billed by GitHub, so they aren't read.
  • Paid plugins sold through the JetBrains Marketplace are licensed and billed by JetBrains and aren't read.
  • Package installs from npm, PyPI or crates.io, and editor extension installs, aren't visits or sales.

03Where buyers come from

  • GitHub READMEsA link in a popular repository's README sends developers who already trust the project.
  • Hacker News and RedditLaunch posts and technical deep-dives send bursts of developers who try first and may pay much later.
  • Docs searchDevelopers searching an error message or how to do one thing land on docs pages.
  • AI coding assistantsAssistants answering a coding question may recommend your tool and send the developer to its docs, in the AI channel.
  • Talks and podcastsConference talks and developer podcasts send people who look the tool up afterwards, typed in rather than linked.

04What Tally answers

  1. Which README links send developers who end up paying?

    GitHub shows up as a referrer with its visitors and the revenue credited to it; add UTMs to the links in each README to tell the repositories apart.

    Sources with revenue
  2. How long from a developer's first visit to a team plan?

    Path to purchase gives the median time and visits from first visit to first payment and the pages buyers saw; a side-project trial before a team buys shows as a long path with docs pages near the end.

    Path to purchase
  3. Can I check revenue without leaving the terminal?

    The command line and the REST API give you the figures from a terminal or a script, and the MCP server lets an AI assistant in your editor answer questions about them.

    API, CLI and MCP
  4. Why do some team plans show no source?

    Coverage gives the share of revenue linked and the reason for each unlinked sale, such as a Checkout Session created by the CLI's upgrade command without the visitor's id, with the snippet that fixes it.

    Coverage
  5. Did the launch thread bring paying teams, months later?

    Each team plan's receipt keeps the first visit as well as the credited one, so a developer who found you in a launch thread and paid months later still shows the thread in the evidence.

    Receipts

05Numbers worth watching

Visitors from AI assistants
Visits from AI assistants answering coding questions, counted in a channel of their own.
Median time to buy
The median time from first visit to first payment, the length of the side-project phase.
Coverage
The share of revenue linked to a visit; upgrades started from a CLI or an IDE are the usual gap.
Revenue by source
Revenue behind each README campaign, community and docs landing page.

06An example

Example

Path to purchase

Last 30 days · 105 of 124 new sales, the ones linked to a visitor

Median time to buy

3days

from their first visit

Median visits

3visits

the one they paid in included

Bought on the first visit

12%

13 of 105

Pages before buying

11

median pages viewed

Where buyers came from, and who closed the sale

105 new sales: where each buyer first came from, and the source credited with the sale.

50% of new sales were credited to the source that first brought the buyer in. Hover or focus a flow for its numbers.

  1. Googlecredited toGoogle26
  2. x.comcredited tox.com10
  3. Other (3 sources)credited toOther (3 sources)10
  4. Directcredited toOther (3 sources)9
  5. ChatGPTcredited toChatGPT9
  6. Other (3 sources)credited toNewsletter9
  7. Redditcredited toReddit8
  8. Googlecredited toNewsletter6

6 smaller flows in the table below.

Show the flows as a table
105 new sales: where each buyer first came from, and the source credited with the sale.
Brought them inCredited with the saleNew salesShare
GoogleGoogle2625%
x.comx.com1010%
Other (3 sources)Other (3 sources)1010%
DirectOther (3 sources)99%
ChatGPTChatGPT99%
Other (3 sources)Newsletter99%
RedditReddit88%
GoogleNewsletter66%
DirectGoogle55%
x.comGoogle55%
RedditGoogle33%
DirectReddit22%
ChatGPTGoogle22%
Other (3 sources)ChatGPT1<1%

Time from first visit to purchase

  1. 13Same visit: 13 sales (12%), bought in their first visit
  2. 13Same day: 13 sales (12%), a later visit, under 24 hours after the first
  3. 301–3 days: 30 sales (29%), 1 to 3 days after the first visit
  4. 194–7 days: 19 sales (18%), 4 to 7 days after the first visit
  5. 151–2 weeks: 15 sales (14%), 8 to 14 days after the first visit
  6. 102–4 weeks: 10 sales (10%), 15 to 28 days after the first visit
  7. 51–3 months: 5 sales (5%), 29 to 90 days after the first visit
  8. 03+ months: 0 sales (0%), 91 days or more after the first visit

Pages buyers saw before paying

Share of the 105 buyers who viewed each page before paying

  1. /pricing96%, 101 of 105 buyers
  2. /71%, 75 of 105 buyers
  3. /signup63%, 67 of 105 buyers
  4. /docs38%, 40 of 105 buyers
  5. /blog/stripe-fees26%, 28 of 105 buyers
  6. /compare21%, 23 of 105 buyers
  7. /changelog8%, 9 of 105 buyers
  8. /blog/launch-week5%, 6 of 105 buyers

Only new sales count here. Renewals and upgrades belong to the visit that won the subscription, so counting them would count that journey again.

Fig. 1Path to purchase on the example site. For a developer tool, read the histogram's long tail as side projects becoming team purchases.

07Setting up

  1. Next.jsIf the docs and site are one Next.js app, put the tag in the root layout so docs, pricing and the dashboard all carry it.
  2. PolarWith Polar, set tally_visitor_id in the checkout's metadata when a developer picks a team plan.
  3. Add UTMs to the links in your READMEs and package pages, since a referrer may carry only the site's domain, not the repository.
  4. Call tally('identify', { email }) after sign-in, so a payment made later with that email links even from the terminal.

08Questions

  • Do npm installs or editor extension installs count?

    No. Installs from package registries and extension marketplaces aren't read; visits to your site and payments in your provider are.

  • Do AI coding assistants send us developers?

    Visits from ChatGPT, Claude, Perplexity and other assistants have a channel of their own, with revenue beside them; for a developer tool, check which docs pages those visitors land on.

  • A developer pays for themselves, then their company buys a team plan. One customer or two?

    Two when the payments use different emails or browsers, each credited to its own last visit that didn't come direct. If the same identified email pays both, they sit on one customer's row.