Sell a paid product to the users of your free open-source project

Build a paid product on top of your free open-source project and sell it to the people already using the free part. Tailwind Labs made $400,000 on the first day of Tailwind UI. Laravel's creator turned his own server setup chores into Forge, which WorkOS reports had thousands of paying customers within a month. Both cases are self-reported by founders or close observers.

How it works

The free project builds the audience. The paid product sells to that audience through the places it already visits. The two cases follow the same steps.

1. Grow the free project first. Tailwind CSS's first release was being finished on Halloween night 2017. Before the post on how Tailwind grew from a side project into a business, it had passed 10 million total installs. Taylor Otwell made no money from Laravel for years.
2. Pick the paid product from work your users repeat. Otwell was building servers by hand again and again to test Laravel, so he automated that work. The result, Forge, provisions EC2 servers using the customer's own AWS credentials. Adam Wathan went full-time on the free framework knowing he could sell themes, UI kits or courses around it. His team then spent months building Tailwind UI on top of the framework.
3. Sell through the free project's own surfaces. In his 2020 year in review, Wathan credits the framework docs with sending buyers to Tailwind UI. Otwell told The Laravel Podcast that Forge launched at Laracon in New York City in summer 2014. Community events work too. Jason McCreary's Shift, a paid Laravel upgrade tool, went from $0 to $3,000 a month in 10 months.
4. Keep investing in the free project. Wathan says improving Tailwind CSS and teaching people to use it proved the most effective way to grow the business.

The results were large relative to the founders' hopes. Otwell hoped Forge would cover his mortgage and electric bill, and far more people used it than he expected. By January 2015 he was working on Laravel full-time, according to WorkOS's interview with Otwell. Tailwind UI was about to pass $2 million in revenue about five months after release. That success let the founders start hiring. Details are on the Tailwind UI case page and the Laravel Forge case page.

What it takes

Our estimate: about 120 hours of work, and about 30 days before you can read a signal. Most of the hours go into building a first version of the paid product that solves one repeated task well, plus a sales page, checkout and a few placements inside your docs. A waitlist or pre-sale can come before the product is finished, which shortens the wait for a first read. The signal takes about a month because launch-day buying is noisy and you need a few weeks of steady docs-driven sales to see the real rate.

What to measure

Paid signups per docs visitor tells you whether the free project actually carries the paid one. If docs traffic converts well and other sources barely do, your distribution is the project. If docs traffic converts poorly, the paid product may be too far from what users do in the free one.

Pre-launch signups per week are your cheapest demand test. A rising count before launch is a good sign. A flat count after you have promoted it in the docs is a warning.

First 30 days of revenue against build hours keeps you honest about whether this beats spending the same time on the free project.

Installs and docs traffic before and after launch guards the source of your audience. If they fall after launch, users may be reacting badly to the paid product.

Refunds and cancellations by source show whether you sold to the right people. Compare your numbers with our free-to-paid conversion benchmarks, but treat an open-source audience as its own segment.

When it backfires

• Users expect it to be free. Shift charged only $3 to $7 per upgrade. Price too high and you invite a free clone.
• The paid product starves the free one. Tailwind's growth came from keeping the framework improving. If the paid work pulls every hour away from the project, the audience shrinks.
• The product is not tied to repeated work. Forge worked because it removed a chore Otwell did daily. A generic add-on has no such pull.
• No runway while you wait. Wathan funded his full-time work with earnings from Refactoring UI, and Otwell went years without income from Laravel. Without a cushion you may quit before the audience is large enough.
• Launch crunch. The Tailwind team worked 36 hours straight to hit a self-set early access deadline. That pace is a cost, not a method.

Run it as an experiment

Hypothesis: a paid product placed inside our docs will convert docs visitors at a rate high enough to pay back the build within one quarter. We recommend a pre-sale or waitlist page first, linked from a callout in the docs. Show the callout to a random half of docs visitors for four weeks and hold out the other half, then compare signup rates. Use the sample size calculator to check you have enough traffic, and the waitlist launch playbook for the page. Log docs page, visitor source, signup, payment and refund. Our suggested decision rule: build the full product if the exposed group signs up clearly above the holdout and early payments cover the projected build hours, otherwise change the offer or drop it. Write it up with the growth experiment guide.

How strong the evidence is

The grade is case with numbers: at least one company documented the tactic and published results as figures. Tailwind Labs carries most of it, with founder-stated figures such as over $4 million in revenue in under two years. Laravel adds a third-party report of thousands of paying Forge customers and Otwell's line about selling $10 million of software, which covers all his products, not Forge alone. The podcast host's view that the total is now higher is a guess. Shift's growth is told on McCreary's own write-up. All figures are revenue, not profit. There is no control group. For running community well, see the community-led growth playbook.