Playbook, developer tools company
Nobody is asking what it costs, they are asking what counts as one
A rate is easy to publish and it answers almost nothing. The reader is building a spreadsheet they have to defend to somebody who holds a budget, and every cell in it depends on a definition you keep in your billing code: whether a retry counts, whether an error counts, whether a build cancelled in its first second counts. That definition is the pricing answer, and it is usually the one thing not on the pricing page.
Why this is not the general answer
The handling pattern for pricing questions holds across every trade. What follows is the part that does not.
- The price is a rate against a meter, so the real question is never how much but what increments the counter: a retried request, a cached response, a run that timed out, a service account that is not a person.
- The reader is modelling rather than buying. They are producing a figure to take into a meeting they will not invite you to, and a range they cannot defend there loses the adoption silently.
- The free tier is a product decision rather than a discount, because it exists to be built on, so what matters is the exact ceiling and what happens at it: whether calls start failing or a bill quietly begins.
- Where there is an open source core and a commercial edition, a good share of what arrives as a pricing question is a licence question about whether the reader may ship what they have already installed.
How it arrives
- does a retried request count twice against the quota
- what happens the moment we go over the free tier
- is the meter on requests or on rows returned
- do service accounts need a seat each
- can we run the open source build in production without paying
- how do i work out a monthly bill from our current traffic
What has to be indexed for this to work
| The meter definition, written as what counts and what does not | Enumerate the boundary rather than the concept: retries, redirects, rejected calls, cached hits, a job cancelled before it started, a run that exceeded its own timeout. Each of those was a decision somebody made in your billing code, and none of them can be guessed from outside. |
|---|---|
| The free tier ceiling and the behaviour at the moment it is reached | Whether traffic is declined, throttled or simply starts costing money, and whether the allowance resets on a calendar month or on the anniversary of signup. Those two reset rules differ by up to a month and people plan around the wrong one. |
| The boundary between the open source edition and the commercial one, in plain words | What may be run, modified, embedded and redistributed, written as sentences next to the licence text rather than as the text alone. The question underneath is always whether they may ship it, and a reader left to interpret a clause will ship on their own reading. |
| The overage rate, and whether anything caps it | The price past the included allowance, whether it steps down at volume, and whether a hard limit exists that stops traffic instead of accruing. Nobody signs an uncapped meter into a production system without knowing it can be capped. |
The reply
The meter counts accepted calls, and the reference lists what does not increment it: rejected calls, responses served from cache, and anything retried after a timeout on our side [1]. The free tier stops at the published ceiling and declines further traffic rather than starting to charge, so a bill cannot appear until somebody adds a payment method [2]. Service accounts are counted on the same meter as everything else rather than per seat, so a machine identity does not need one. I cannot see your traffic or work out what it would cost, so if you want a modelled figure, leave your name, your work email and a rough monthly volume and the team will put one together.
It defines the unit before it mentions the rate, because the rate is already on the page and the unit is the part nobody can infer. The sentence about a bill being impossible without a payment method answers the fear behind most free tier questions, which is not the price but the surprise. Refusing to model described traffic is the honest line, since nothing here can see any of it.
Where it stops
The trigger. The reader describes their own traffic, workload or existing spend and asks what it would come to, or asks whether a licence permits a particular way of shipping the product.
Costing a real workload needs somebody who can look at the shape of it, and a licence question about how you intend to ship deserves a proper answer rather than my reading of the text. Leave your name, your work email and a rough monthly volume and the team will come back with a figure.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never estimate what a described workload would cost, because a number given in a chat window gets pasted straight into a budget.
- Never say a particular use is permitted under the open source licence, since that is a legal reading and the reader will build on it.
- Never state a unit price, an allowance or an overage rate that is not on the published pricing page.
- Never suggest that a plan could be discounted, extended or negotiated, as that belongs to somebody with the authority to agree it.
Questions
- Our rate is published. Why does this keep getting asked?
- Because the rate was never the missing fact. What counts as one unit is settled in your billing code and written down almost nowhere, so anybody modelling a month has to guess at retries, errors and cached hits. Publishing that list answers the question the pricing page was not answering.
- Can it tell somebody what they are currently spending?
- No. It reads documents and has no view of any account or meter. It can explain how the counter increments and where usage is shown in the product, then take the details if somebody needs a real figure for their own traffic.
- Should it touch the licence question at all?
- It should state where the editions divide, in your own words, alongside the licence. What must not happen is it interpreting a clause for somebody about to build a business on the interpretation. Explain the split, then hand over.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Handling pricing questions in generalPublished price versus the price for this buyer. Bands, ranges and from pricing, and why a firm number for unscoped work is the damaging failure.
- An engineer has been asked to explain a spike to somebody in financeReconciling a usage counter against a line item, spikes with a timestamp behind them, and the purchase order details a finance team blocks on.
- Two deployments, and two completely different answers to delete our dataFor a self hosted install there is nothing on your side to delete. For the hosted one, request logs and telemetry each run their own clock.
- An engineer has been handed a review and does not own the answersAudit logs, retention windows and release provenance. What can be answered from published trust material, and which rows need an agreement.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.