Pricing a devtool for product-led growth is a marketing decision that finance happens to sign off on. The model you pick, free tier versus free trial versus open core, tells developers what kind of company you are before they read a word of your homepage. Usage-based pricing signals that you win when they win. Seat-based signals that you are counting heads. Where you put the paywall decides whether people ever feel the value before you ask for a card. Packaging it right lets the product do most of the selling, and packaging it wrong is the kind of mistake no amount of content digs you out of. Here is how to make these calls.
Why is pricing a positioning decision, not a finance one?
Because for a developer, your pricing page is a product spec. It is often the second page they open after the docs, and they read it the way they read an API reference: looking for the catch, the rate limit, the line where the free thing stops being useful.
A finance-led pricing exercise asks what the market will bear and what protects margin. A positioning-led one asks what the model says about who you are, and whether the free experience proves the thing you claim. Those produce different pages. If your whole pitch is “we save engineering teams hours,” but your pricing charges per seat so adding a teammate costs money, you have priced against your own story. Developers notice, and they will tell you in a GitHub issue.
This is downstream of your actual positioning, which is why I treat the two as one project. If you have not nailed down what category you are in and who you are for, read positioning a technical product first. Pricing built on fuzzy positioning is just guessing with a dollar sign.
Free tier vs free trial vs open core: which one?
These are not interchangeable. Each one fits a different product shape and a different buyer.
A free tier is a permanently free version with real limits. It works when your product has a natural usage dimension you can cap (requests, projects, seats, storage) and when a solo developer or small team can get genuine value inside those limits. The free tier is your top-of-funnel and your best marketing channel at once. The risk is that it never converts because it is too generous, which I will get to.
A free trial is full access for a set window, usually 14 days. It works when the value lands fast and when your product is something people adopt in a burst, like a CI tool or an observability platform they wire in over a sprint. Trials force a decision, which is good for revenue and bad for the slow, bottom-up adoption a lot of devtools rely on. Developers evaluate on their own timeline, and a countdown clock does not respect that.
Open core is an open-source project with paid proprietary features around it, usually the team, security, and scale features enterprises need. It works when community adoption is your moat and the open version is genuinely useful on its own. It is the slowest to monetize and the hardest to get right, because the line between “free forever” and “pay now” is a community trust question, not a spreadsheet one. Move a feature behind the paywall that people assumed was free and you get a backlash on Hacker News.
| Model | Best when | The real risk | What it signals |
|---|---|---|---|
| Free tier | Clear usage cap, solo/small-team value | Too generous to convert | “Start free, grow with us” |
| Free trial | Value lands fast, burst adoption | Clock fights bottom-up adoption | “Try the whole thing, then decide” |
| Open core | Community is the moat | Trust breaks when you move the line | “We are of the ecosystem” |
You can combine these. Plenty of companies run an open-core project with a free-tier cloud offering on top. Just be clear which one is doing the acquisition work and which one is doing the monetization work, because they are rarely the same layer.
Usage-based or seat-based pricing?
Default to usage-based for infrastructure and API-shaped products, and seat-based for collaboration and workflow tools. Then check your answer against how value actually scales.
The question to ask: what grows as the customer gets more value out of you? If it is volume, calls, data, compute, builds, then price on that. Usage-based aligns your revenue with their success and removes the friction of adding teammates, which matters a lot for tools that spread across an engineering org. It is the honest model for infrastructure, and developers trust it because they can reason about the meter.
Seat-based makes sense when the value really is per-person, like a code review tool or a collaborative IDE where each new user gets their own value. It is more predictable for the buyer’s budget, which procurement likes. The failure mode is that seat-based pricing quietly punishes adoption. If it costs money every time someone opens your tool, teams share logins and cap their own usage, and you have built a tax on the exact behavior you want.
A lot of AI-native devtools are landing on hybrid: a small platform fee plus usage on tokens or actions. That is fine, as long as the meter is something the developer can predict. The fastest way to lose trust with an engineer is a bill they could not have forecast. If your pricing needs a calculator with six inputs, simplify it or add a hard spend cap, because unpredictable cost reads as a trap. This is doubly true for the AI engineer audience, who have watched token bills blow up and distrust vague metering.
Where should the paywall go?
Put the paywall after the aha moment, never before it. The single most common devtool pricing mistake is gating the thing that proves your value behind a signup wall or a paid plan, so people bounce before they ever feel why you are worth paying for.
Map your activation moment first: the specific point where a developer goes “oh, that is useful.” For an error-tracking tool it is seeing a real stack trace from their own app. For a database tool it is running the first fast query. That moment has to be free and it has to be easy to reach. Everything before it should have as little friction as you can manage, ideally no credit card and no sales call.
Then the paywall goes where the customer has clearly outgrown “trying it” and moved into “depending on it.” Good triggers are collaboration (inviting a team), scale (more than X of something), and production concerns (SSO, audit logs, longer retention, SLAs). At those moments the buyer already has a business reason to pay, so the ask feels fair instead of extractive. Bad triggers are the core feature itself, or an arbitrarily low limit that hits during honest evaluation.
How do you build a generous free tier that still converts?
Make the free tier generous on dimensions that prove value and stingy on dimensions that signal a real business is using you. That is the whole trick, and most teams get it backwards.
Be generous with the “does this work and do I like it” dimensions: features, the core workflow, single-user or small-project usage, time to first result. You want a developer to fully understand and love the product for free. A free tier that only shows a crippled version does not build advocates, it builds skeptics.
Be strict on the dimensions that correlate with a company deriving commercial value: team size, production-grade volume, retention windows, and the governance features (SSO, roles, audit) that only matter once there is something to govern. A developer kicking the tires should be able to live on your free tier happily, possibly forever. A team shipping real product on it should hit a wall that is clearly about their scale, not about you nickel-and-diming them.
The test I use: would a developer recommend your free tier to a friend, and would a team lead be slightly embarrassed to still be on it in production? If both are yes, the tier is doing its job. A free tier that converts nobody has usually drawn its limits on the wrong axis, capping features people need to fall in love instead of the scale that signals it is time to pay.
Self-serve or sales-assist?
Run both, and let the deal size decide which path a given customer takes. PLG does not mean no sales. It means sales does not gate the first experience.
Everything up to a certain contract value should be fully self-serve: sign up, use it, upgrade with a card, no human required. Developers strongly prefer buying this way for smaller commitments, and forcing a “talk to sales” step for a $50 plan just leaks pipeline. Above some threshold, usually where you are into annual contracts, security review, and procurement, sales-assist earns its keep on the negotiation, the security questionnaire, and the multi-team rollout.
The pattern that works: self-serve is the front door for everyone, and a product-qualified signal (a team hitting usage limits, multiple signups from one company domain, someone poking at the enterprise features) tips an account over to a salesperson. Your product does the qualifying, so sales only talks to people who already want you. If you are standing up this motion for the first time and wondering who owns it, that is really a question about your first marketing hire and how go-to-market and product intersect.
Where to start
If you are pricing or repricing a devtool right now, do it in this order. Pin down positioning, because the model has to tell the same story your homepage does. Pick the model that matches your product shape, not the one your competitor uses. Find the aha moment and make sure it is free and fast to reach. Draw free-tier limits on scale, not on features. Then wire self-serve as the default with sales-assist for the big deals. Pricing is not set-it-and-forget-it, so plan to revisit it as you learn, ideally alongside your launch plan.
If you want a second set of eyes on your pricing page before it goes live, or you are staring at a free tier that gets signups but no upgrades, that is exactly the kind of thing I dig into. Take a look at how I work with devtools teams, or tell me where your pricing is stuck and I will tell you what I would change.
