Pricing the Low code tooling stack

Pricing has always been a very tricky question. If you would ask Pierre de Fermat – it would seem like an optimisation problem to him. And I would imagine the lawyer cum mathematician would plot price paid vs value derived by the customer on a cartesian plane. While we mere mortals (read bootstrapped companies) – don’t have the luxury of time to perfect this plane but rather work our way through numerical techniques of approximation and trials and see what really works. Most of my peers in the industry would rather follow a similar approach.

I was recently in the bay area attending SaaSBoomi and listening to Jyoti Bansal from harness/unusual ventures. While he spoke on the platform a lot of great things but in the context of pricing and PMF he spoke about something which I find absolute gold. Here is what he said:

PMF is all about repeatability and repeatability itself has to be broken down into 3 bullets:

1. Repeatability of Value prop
2. Repeatability of sales playbook (should include pricing, pipeline, etc)
3. Repeatability of value ROI calculated by customer

Point 3 intersects Descartes’s cartesian plane – surely this is where magic is. Reverse engineering the scenario can lead us to imagine a line item in the annual operating budget plan. If this is what it looks like then with the new offering of Self Hosted then we are surely nowhere near the ROI repeatability path yet. Again we are broadly speaking on behalf of the whole industry which is pricing the subscription with a similar sort of pricing model.

But we are learning from our customers and we are learning from some of our friends in the industry and we find some bright new ideas to price our self host service in an innovative way. Surely the 1st amongst all our friends in our space.

Broad idea is we take our self-hosted version and add a new price model based on the number of developers who would use the low code platform and not bother about end users of the applications. Logic being ->for some applications – say a tax filing application for employees, to be used just once a year or twice a year, a customer would find it hard to justify a per user per month fee for end users. And in many cases neither usage nor user based pricing makes any sense. Also, the value derived out of usage will vary from application to application. So having just the two models of pricing is not sufficient. In our bid to address such cases we introduce the developer based pricing. Imagine cases where you are building just a couple applications and want to give it to 1000s of users. Per user based fee might not let the customer really derive full ROI on this investment.

Thinking a bit from the perspective of a CTO — As a business I want to develop applications to run or operate my business with a breeze. Historically developer tools enable me to build multiple applications without bothering about end users or even usage of applications. With Eclipse/Netbeans/Visual Studio I would just go on to build applications. So here we go –> we take a cue and make developer only licenses for self hosted versions available for our customers. This license gets you unlimited internal or external users. In short we are taking a bold position to treat our self host version as a pure-play developer tool for building applications – both frontend as well as middleware services.

It means that now an engineering manager need not bother about usage nor end users while choosing a low code product and rather simply empower their developers to build applications faster with the powerful low code tooling. Create as many custom internal tools or large applications for business without paying any fees for end users.

Let’s simplify plan selection

Go for User-based pricing when you know exactly how many users will interact with your app and how many times. Let say, a warehouse checklist where a team of 5 operates machinery.

Go for Usage-based pricing when you don’t know how many times your app will be used and by how many people. Say, a premium calculator app to be interacted by unknown number of users.

Go for developer-based pricing when you have built an app to be embedded into your product / portal, very high app usage and a high number of end users to be supported.

Do let me know what you think or have any feedback for us. Reach out to me at jinen@dronahq.com