How to price a developer tool at launch

Pricing a developer tool is not a maths problem. It is a positioning statement written in numbers, and your first users read it that way. A free tool with no paid path says "this is a side project". A tool at enterprise rates with no self-serve option says "you will be talking to a salesperson". Both are valid, and both close doors.

The decisions below are the ones that are expensive to reverse. Get these roughly right at launch and the number itself becomes easy to adjust later.

Decide what you are charging for before how much

Most pricing confusion is actually a metric problem. Pick the thing you bill against first:

Two rules worth applying hard. First, the metric must be something the buyer can measure themselves before they pay, and audit afterwards. If they cannot predict the bill, they will not adopt it for anything important. Second, the metric should go up when the customer succeeds, not when they experiment. Charging per CI run punishes the team that adds tests.

Per-seat pricing deserves particular scrutiny for developer tools. It is the default in SaaS, and it is often wrong here, because the tool is installed once and its benefit spreads to people who never open it. Seat counting then becomes something your customers actively work around.

What your free tier is for

A free tier has exactly one job, and you have to know which one:

Evaluation. The user needs to prove it works on their real data before they can ask for budget. An evaluation tier should be generous in capability and limited in scope or time: full features, one project, or a 14-day window on everything. What you must not limit is the thing they need to test.

Distribution. You want the tool everywhere, and revenue comes from a minority who cross a line. A distribution tier should be limited by something that grows with the user's own success: team size, request volume, private repos, production use. Individuals and hobbyists stay free forever and cost you little; companies pay when the tool becomes load-bearing.

A free tier that is neither, for instance one crippled enough that nobody can evaluate but generous enough that companies never upgrade, is the most common pricing mistake in this category. If you cannot say which of the two jobs yours does, you do not have a free tier, you have an unpriced product.

Also decide what happens at the limit. Hard stop, degraded service, or an overage charge? Silently failing at the limit is the fastest way to lose a customer who was about to pay you.

Open source plus paid, honestly

If part of your tool is open source, the model you pick determines what you can charge for later, and changing it is painful and public.

• Open core. Base is open source, some features are commercial. Works when the commercial features are naturally organisational: SSO, audit logs, RBAC, multi-tenancy, compliance controls. Draw the line clearly at launch and publish it, because moving a feature from open to paid later is the change that generates the loudest backlash.
• Managed hosting. Everything is open source, you sell running it. Honest and easy to explain. The risk is that a bigger platform can also run it, so your advantage has to be expertise, speed, or integration rather than access to the code.
• Source-available or delayed open source. The code is readable and often usable, but a license restricts competing commercial use, sometimes converting to a true open source license after a set period. Legally effective, and understand that a meaningful part of your audience will not treat it as open source and will say so. Do not describe it as open source if it is not, because that argument overshadows your launch.
• Dual licensing. Copyleft for the community, a commercial license for companies that cannot accept those terms. Requires that you own or have assignment on all contributions.
• Support and services. Everything free, you sell help. Straightforward to start, hard to scale, and it prices your time rather than your product.

Whichever you choose, put the licence and the boundary in the README rather than in a blog post. Our open source launch checklist covers where those files belong.

When to start charging

The useful test is not revenue readiness, it is dependence: charge once a user would be annoyed if you turned the tool off tomorrow. Before that point, a price mostly measures your optimism. After it, free usage trains people to expect free forever.

Arguments for charging earlier than feels comfortable:

• A paying user gives qualitatively better feedback than a free one, because their own money is involved.
• Price is the fastest test of whether you are solving an expensive problem or a mildly annoying one.
• Free users who would never pay can consume all of your support capacity while telling you very little.

Arguments for waiting:

• Taking money creates obligations you may not be able to meet yet: uptime, data durability, invoices, refunds, tax handling, and a support response time.
• If your onboarding still needs you personally, every paying customer is a commitment of your own hours.

A common middle path is "free during beta, pricing published, paid from a stated date". That keeps the beta honest about what comes next and gives you a deadline. Our comparison of waitlist or open beta covers which shape of beta suits that.

Picking a number you can defend

There is no formula, but there are boundaries.

The floor is your marginal cost per customer plus the support you expect, with enough margin that a heavy user is not a loss. Model your worst realistic customer, not your average one. For anything that runs compute or calls a paid model on the user's behalf, do this before you publish a flat price, because unmetered flat pricing on metered costs is how tools get withdrawn.

The ceiling is what the problem costs your user today. That is usually engineering hours: how long the task takes now, how often, multiplied by a loaded hourly cost they would recognise. You do not need to know their exact salary figures to know that a tool saving a few hours a month is worth more than a streaming subscription, which is where many developer tools inexplicably price themselves.

The anchor is what they would do instead. For developer tools the real alternative is almost never a competitor. It is a shell script, a cron job, a spreadsheet, or a junior engineer's afternoon. Price against that, and know that "we will build it internally" is a live option for exactly the audience you are selling to.

Practical points that matter more than the number:

• Publish it. A self-serve developer tool with "Contact us" as its only pricing loses the engineer who was evaluating it at 11pm. Reserve sales contact for the tier where a contract is genuinely required.
• Two or three tiers, not five. Tiers separate genuinely different buyers, they do not make a table look complete.
• Show an example bill. For usage pricing, show what a realistic team actually pays, with the numbers worked through.
• Annual discount is a cash-flow tool, not a growth strategy. Offer it plainly and do not hide the monthly option.

Changing price later without burning early users

You will get the first number wrong. That is expected, and it is recoverable if you handle it as a promise rather than a config change.

• Change the price for new signups first. Existing customers keep their price. This is the least disruptive move available and it costs you almost nothing except the difference on a small base.
• Grandfather explicitly, in writing, with a duration. "Your price is locked for 12 months from today" is a keepable promise. "Early supporters keep this forever" is one you may regret, so only say it if you mean it. Vague reassurance is worse than either.
• Announce before, never after. Email affected users directly, with the new price, the date, what changes for them, and the reason. Discovering a price change from an invoice is the thing people remember and repeat.
• Give long notice on anything that reduces what someone already has, and provide an export path. If your tool holds their data or configuration, being easy to leave is what makes people willing to stay.
• Understand which changes are actually resented. Raising the price of a plan is usually accepted if the product has visibly improved. Removing or gutting a free tier that people built on is what generates lasting anger, because it breaks something that was already working. If your free tier might not survive, limit it clearly at launch rather than shrinking it later.
• Never re-tier silently. Moving a feature someone relies on into a higher tier is a price rise with extra steps, and treating it as a "packaging update" fools nobody.

One deliberate exception: raising prices while keeping every current customer where they are is the single safest pricing change you can make, and most teams delay it far too long.

The honest takeaway

At launch, precision is not available to you and is not required. What is required is a metric your users can predict, a free tier with one clear job, a published number, and an explicit promise about what happens to early users when the number changes. Those four things survive being wrong about the amount. If you want to see how comparable tools present their pricing before you set yours, browsing what is already listed on Explore and the open source launches collection is a faster reality check than any spreadsheet, and when your own page is ready, list the tool with pricing stated rather than implied.