Why our pricing page is an API call

Our pricing page does not contain any prices. It fetches them, at render time, from the same catalog our billing system charges from. If we changed what we charge tomorrow, the website would change on its own, because there is only one place where prices exist. We built it this way on purpose, and the reason is not technical.

The usual arrangement

On most SaaS websites, pricing is copy. A marketing page says one thing; a billing table somewhere says another; a sales deck says a third. Usually they agree, because someone remembers to update all three. Sometimes they do not, and then a customer discovers the difference on an invoice, and the company explains that the website was "out of date". Everyone involved was honest, individually. The system was still capable of lying.

We are a small team inside Teknowledge Software in Kolkata, and we have shipped software for other people for over twenty years. We have seen this failure from the inside. It is never malicious. It is always structural: two sources of truth will eventually disagree, and the customer always finds out at the worse of the two.

The constraint

So we made a rule, internally numbered S10-02 in our spec, which says: the pricing page renders the same catalog the billing system charges from. Not a copy of it, not a JSON file someone exports quarterly. The same catalog, over the same API our own billing reads.

Our prices are flat and public: ₹10, ₹20 or ₹30 per user per month for Starter, Growth and Pro, and a 365-day free trial for companies up to 50 employees. You can read them on the pricing page, and what you read there is, mechanically, what an invoice would say. There is no enterprise-call-us tier where the real prices live.

What the constraint does to us

The interesting part is not the engineering; fetching a catalog is a Tuesday afternoon. The interesting part is what the rule forbids.

We cannot run a website discount that billing does not honour. We cannot show a teaser price with an asterisk that resolves to something else at checkout. We cannot quietly raise prices for new signups while the page still shows the old number, because the page does not have its own number to show. Every dishonest pricing move we could make now requires changing the actual catalog, in the open, for everyone, at once.

Constraints like this are a way of making promises to strangers. Anyone can write "transparent pricing" on a website; the words are free. Wiring the website to the billing system is different, because it removes the mechanism by which the promise could be broken casually. We would have to break it deliberately, and deliberate is where shame still works.

The same idea, elsewhere in the product

Once you see pricing this way, you start applying it everywhere. Our security page lists what we have not built yet, alongside what we have, because a security page that only lists strengths is marketing wearing a lab coat. Our payroll engine will not publish payslips from anything but a finalized run, because a payslip should trace to the numbers that were actually locked. One source of truth, rendered everywhere it is needed, is the whole platform philosophy; the pricing page is just the most public instance of it.

We launched recently. We have no famous logos to borrow credibility from, and we are not going to invent any. What we can offer instead is architecture that makes certain kinds of lying expensive. That is worth more than a testimonial, though we accept it makes for a quieter homepage.

The honest cost

Is there a downside? One: we have given up pricing flexibility that other companies use, sometimes legitimately. No negotiated deals, no regional experiments that the website does not reflect. If we ever want those, we will have to model them in the catalog properly, where everyone can see the structure. We think that is the right kind of friction. If a pricing idea cannot survive being visible, we probably should not be having it.