People love using open-source software, but how do the businesses behind them make the work financially sustainable? Some projects stay as side hustles, some bootstrap with paid features or services, and a few turn into venture‑funded companies. We chose the last route — partly because Pangolin’s early adoption convinced us the demand was there, and partly because we wanted to see how far we could push this idea.

In under a year, Pangolin has grown past 15,000 GitHub stars, 3,600 Discord members, and nearly 1,000 individual donors with continued steady, organic traction. There hasn’t been a one‑time viral spike and growth has been consistent, mostly from word of mouth from many YouTube videos, podcasts, articles, and industry publications. That sort of momentum is the clearest sign you’ve reached product–community fit: people find it useful, they tell their peers, and the project starts to spread on its own.

Why would an OSS project raise money?

Not every OSS project needs to raise. Many can happily stay side projects funded by passion or small donations. For us, Pangolin was always meant to go beyond a hobby. We saw a chance to build something genuinely ambitious, and that meant moving faster and investing in the community at the same time.

The choice was either keep it a part‑time pursuit and grow slowly, or raise capital to give the project full focus, hire a team, and build responsibly for the long term. We chose the latter.

Donations don't scale

Donations have been amazing and helped us get here. Nearly 1,000 individuals have supported Pangolin directly which is deeply motivating. But even at that scale, donations simply don’t add up to sustainable funding for a team. Companies depend on Pangolin, but they’re rarely incentivized to contribute meaningfully via donations. What takes a company minutes to spend on a SaaS subscription can take years to raise through community donations.

Donations are a great way to validate interest, but they’re not enough to fund a durable business or full‑time contributors.

Timeline so far

• January 5th, 2025: We released the first Pangolin version in beta. Our first post on r/selfhosted blew up.
• January 15th, 2025: The first YouTube video by DB Tech went live spreading the word about Pangolin.
• January 17th, 2025: Pangolin hits 1,000 GitHub stars.
• March 4th, 2025: Pangolin leaves beta with a 1.0.0 release.
• April 6th, 2025: Pangolin hits 5,000 GitHub stars.
• May 9th, 2025: We applied to Y Combinator.
• May 21st, 2025: We interviewed with Andrew Miklas and Diana Hu at Y Combinator.
• May 22nd, 2025: We got accepted into the Y Combinator Summer batch.
• June 19th, 2025: Pangolin hits 10,000 GitHub stars.
• July 11th, 2025: We did our first Show HN post and got 500 points.
• August 23rd, 2025: We take our first seed fundraising meeting.
• August 27th, 2025: We take our last seed fundraising meeting.
• October 1st, 2025: Pangolin hits 15,000 GitHub Stars.

That pace reinforced our conviction: you don’t get this kind of adoption unless the problem resonates widely.

Our seed round

In August, we closed a $4.7M seed round, backed by Chemistry, Y Combinator, BLAST Capital, 468 Capital, Transpose Platform, Pioneer Fund, and a number of supportive angels.

That funding buys us time to invest in the OSS core, to support the community properly, and to figure out which business routes make sense for sustainability.

Is this too soon?

One critique we heard often in fundraising is that we hadn't figured out monetization. That’s normal for early OSS. Most open‑source companies need more time and runway than a SaaS startup before monetization makes sense. You first prove real adoption (product–community fit), then begin exploring business models.

Raising early is about buying enough time to grow naturally without forcing premature monetization.

Closing thoughts

Of course, turning an open‑source project into a business is controversial. Some argue OSS and VC don’t mix; others worry about features being “held back” for commercial editions. We don’t think there’s a single right answer, but our perspective is that the OSS project stays free and useful and the company exists to make sure it stays alive and keeps improving.

If we do it right, the two should reinforce each other.