Perspectives
Why our margin is on the pricing page
A price a buyer can check beats a price a buyer negotiates, and keeping it true has to be mechanical.
By Ehsan Gazar, 14 September 2026
You open a vendor's pricing page and find "contact sales". You book the call. Weeks later you have a number, and no idea whether the next buyer got a better one.
I did not want Vatan to work like that. So the margin is on the page.
The number
A markup is the amount a seller adds on top of what something costs them. Most vendors fold it into one blended price. We print ours.
A request through the Vatan gateway is charged at what the model costs us to buy, plus 5%. For a model we buy direct, our cost is the provider's published price. The rate is the same on every plan.
Nothing else goes on the bill. There is no platform fee, no seat and no subscription. Pay as you go starts with a $5 top-up, and that is the only minimum.
Why there is no discount for bigger plans
On 4 September 2026 we considered a tiered markup, lower on bigger plans. We dropped it the same day.
A tier sounds generous. In practice it turns the price into a conversation. Every buyer asks which tier they are in, and whether the next one down is open to them. The rate stops being something you read and becomes something you argue about.
One rate gives the procurement question one answer, and the buyer can check it alone. I think that is worth more than a discount somebody has to earn.
If a buyer has to ask what the price is, you do not have a price yet.
A published number drifts
Printing a percentage is easy. Keeping it true is the hard part, because a price lives in more places than you expect. Ours lives in four, and all four must agree:
- The rates table,
routing.model_prices, which is the sell price itself. deploy/invariants.json, which records the multiplier "1.05" that the post-deploy check recomputes against.- The console's billing constant, 500 basis points, which every figure on the site is built from.
- The internal pricing model document, where the decision is written down.
A basis point is one hundredth of a percent, so 500 basis points is 5%. You never need to think in basis points. The point is that the site never types the figure; it derives it.
The usual failure is not one wrong price. It is two places that were both right once and then drifted apart.
That happened to us on 4 September 2026. The catalogue had moved to the new rate. The FAQ kept quoting an older, higher markup for a day. Nobody chose to mislead anyone. The figure had been typed into prose in more than one file, and the test guarding the plan cards never read the FAQ.
Never update a price
Every row in the rates table has a start date. A reprice inserts new rows and never rewrites old ones.
That sounds like bookkeeping, and it is the part that protects you. Last week's charge still reconciles against the invoice it produced. Update a price in place and every past invoice disagrees with the table that supposedly produced it. One UPDATE destroys your own audit trail.
Never update a price. Insert the next one.
The checks that hold the number still
The FAQ was fixed by making a second figure impossible to ship, not by rewording it. A test now reads every shipped string in the site's data modules and marketing pages. It fails the build if any percentage presented as a markup differs from the one the meter charges.
After each deploy, the release pipeline reads the live rates table. Every advertised rate on a model we buy direct must be exactly the recorded multiplier times a list figure. A model re-rated at any other markup fails the release. Models we buy through another provider are checked the same way, against their own recorded basis, because what they cost us is different.
The pipeline then fetches the served site over real TLS. The release fails if the bundle does not contain the literal string "plus 5.00%". Without that, a page that quietly lost the number would pass everything else.
A failed release rolls back. A price change nobody decided is treated like an outage, because for the buyer it is one.
Assert the price as a property of the data, never as a copy of somebody's price list.
Show the working
The /models page lists each model with the provider that serves it. It shows what the model costs us beside what you pay. Since 5 September 2026 it also marks the cheapest provider for each model.
Marking the cheapest provider costs us something. It sends buyers to the cheapest route, where 5% is a smaller amount of money. I think that is the right trade. A buyer who watches us point at the cheaper option tends to believe the rest of the page.
What this does not solve
A published markup tells you nothing about whether the underlying cost is fair. Providers set their own prices, and those prices move. When one moves, your bill moves with it, even though our 5% has not.
I do not have a clean answer to that. The best I have is that every change is a new dated row, and the working is on the page.
If your pricing page and your meter can disagree, one of them is wrong, and a buyer will find out which before you do.