Nothing Is Free: How Your Free Dev Tools Actually Make Money

A few years into my career I stopped asking whether a tool was free and started asking how the free version stays in business. It sounds cynical, but it turned out to be one of the more useful lenses I picked up, because the answer to that question predicts almost everything about how the product will evolve, what data it collects, and whether it will still exist in five years. Free is not a business model. Free is a distribution strategy sitting on top of some other business model, and figuring out which one you are dealing with changes how you should use the tool.

The four flavors of free

The first and most straightforward is the freemium ladder. Think GitHub, Vercel, most SaaS dev tools. The free tier is genuinely useful but capped on usage, seats, or features, and the company is betting that enough of you will hit the ceiling and convert to paid. This model is honest in the sense that the incentives are aligned with the product actually being good, because a bad free tier does not generate upgrade momentum. The risk here is usage creep, where the caps quietly tighten over time as the company needs to push more conversions, or where a feature that used to be free moves behind a paywall in a version bump you did not read closely.

The second flavor is the open core model, common among infrastructure tools. The core is open source and free forever, generally under a permissive or source-available license, and the company sells a hosted version, enterprise features like SSO and audit logs, or support contracts. This tends to be the most durable arrangement for the end user because even if the company folds, you still have the open source core to self-host. The catch is watching license changes closely. Several well-known infrastructure projects have relicensed away from permissive open source terms once a cloud provider started reselling their hosted product more successfully than the original company could monetize it themselves. That is not a hypothetical, it has happened enough times that I now check the license file before adopting any open core tool for anything load-bearing.

The third is data as the product. This is the one people underestimate. Some free tools, particularly browser extensions, developer utility sites, or free API testing tools, are funded by aggregating and selling anonymized or not-so-anonymized usage data. If a tool touches your clipboard, reads content from pages you visit, or logs the requests you make through it, ask yourself what happens to that data. I am not saying every free browser extension is selling your data, most are not, but the ones with no other visible revenue stream and no funding announcement anywhere are worth a second look before you install them on a work machine.

The fourth flavor, and the one I think is currently reshaping the developer tools landscape, is the loss leader for a platform. A lot of free AI coding tools and free tiers on cloud platforms exist specifically to get developers building inside an ecosystem, where the actual money is made on compute, storage, or adjacent paid services once your project has any real usage. This is not necessarily bad for you, subsidized free tiers can be genuinely great value while they last, but it means the free tier's generosity is tied to a company's growth strategy, not to the actual cost of serving you, and growth strategies change.

Why this matters for how you build

Once you can categorize a tool this way, you can make better decisions about where to depend on it. I am comfortable building core infrastructure on open core tools because worst case I self-host. I am much more cautious about building a critical workflow around a freemium tool's free tier specifically, because caps and pricing on freemium products are the most volatile of the four categories, subject to change whenever a company needs to hit a revenue number. I have watched teams build entire CI pipelines around a free tier that later introduced a hard usage cap mid-quarter, and migrating off it under time pressure was far more expensive than just paying for the tool from the start would have been.

Data-as-product tools I treat differently again. I still use them, plenty of genuinely useful utilities live in that category, but I do not paste anything sensitive into them, and I check what permissions a browser extension actually requests before installing it. A JSON formatter that asks for access to read and change all data on all websites, when it should only need clipboard access, is a signal worth paying attention to.

A concrete example from my own stack

I switched a personal project's database hosting from a well-known free-tier database provider to a self-hosted Postgres instance on a small VPS after the provider quietly reduced the free tier's connection pool limit twice in one year. Individually, each change was defensible from their side, they needed to manage costs as usage across their platform scaled. But from my side, it meant a project that had been stable for a year suddenly started throwing connection errors in production with no code change on my part. That was the moment I actually internalized this whole framework, not from reading about it, but from getting bitten by it.

What I actually look for now

Before adopting a free tool for anything beyond a weekend project, I look for three things. First, is there a visible, sustainable business behind it, a funding announcement, a clear paid tier, an acquisition by a company with obvious monetization plans. Second, if it is open source, what license, and is there a credible self-hosting path if the hosted free tier disappears. Third, what data does it actually touch, and would I be comfortable with that data showing up in a breach notification email a year from now.

None of this means avoid free tools. Most of the best developer tools I use daily have generous free tiers and I would not want to pay for everything individually. But going in with eyes open about why the free tier exists means fewer unpleasant surprises down the road, and it tends to make you a more discerning evaluator of new tools in general, which is a useful skill completely independent of any specific product.

I also think this framework is a useful lens for the current wave of free AI coding tools specifically, since the compute costs behind them are real and substantial in a way that a simple JSON formatter's hosting costs never were. When a company is subsidizing genuinely expensive inference to build a user base, that subsidy is a strategic bet with a timeline, not a permanent feature of the product, and I would go into any workflow built around a generous free AI tier with a rough mental model of what you would do if that generosity got dialed back significantly. That is not pessimism, plenty of these bets pay off and the generosity sticks around, it is just the same due diligence I would apply to any other loss-leader offering, and it has saved me from over-indexing my workflow on pricing that was never guaranteed to be permanent in the first place.