Kiwicode startup story(11): Pay by usage = Grow with customers
This article is one of the articles in a series ‘Kiwicode startup stories’, and you can read the last article ‘Kiwicode startup story(10): Create the backend of your app.’.
In January 2020, Adrian and I have kept up with the pace of a garage business for the past year. We need to charge for the services that run on our cloud after we designed the Service Builder to make it easier for our customers to create custom databases and services. I need to figure out how to come up with a reasonable charging method for customers to enjoy this service.
I am convinced that a good commercial product’s pricing and charging model are integral parts of the product. Kiwicode has always insisted on offering customers fair pricing, protecting both parties’ long-term interests, and achieving mutual benefit and win-win outcomes. Kiwicode contains a subscription fee, and a single payment fee is required to generate the code according to the amount of code. The ‘delta’ rule is applied to regenerating the code after changing the same item, and only a small fee is required. You can find out why this is the price by going back and reading the article: ‘Kiwicode startup story(7): Build a SaaS company’ and ‘Kiwicode startup story(8): Stop fucking customers with unreasonable prices.’.
Because each service consumes server resources, charging based on usage is the most cost-effective solution. Within a month, we will charge based on the total number of requests and the runtime of each running service. You can run all of your services for a few dollars per month if your application is still in the early stages of development. The back end is where everything happens. You will need to pay more as the number of users of your application grows each month. Customers don’t have to worry about how many people we can support or how many visits they can make because we support unlimited visits. Customers should only be concerned about growth rather than whether or not their services will be interrupted. We’ll keep an eye on the services to make sure everything is running smoothly.
Based on the number of requests and runtime, it is the most reasonable way to measure Service’s resource consumption. A request is an HTTP request to the API that uses server resources. Even if some services only require just several requests, each one will take a long time to complete, and the long runtime will consume more server resources.
Each customer only has to pay a small fee (approximately $1.00) to use all of the services he desires. Since there may be a lot of services that need to be run under each customer’s account, we will uniformly settle the trial status of all services within one cycle, and the customer can pay us every month. Customers do not need to be concerned about paying large amounts of fees in the early stage. All customers start with $1.00, and as their accounts grow, they will pay the fees that are due based on their actual usage. This will not result in any waste, and every dollar spent by the customer will be well spent.
Customers can also choose the running status of each service independently, run a ready service at any time, or pause or stop services they don’t want to run. Customers only need to tap once to get an overview of the service’s current status. You can keep updating the version of the service that has stopped working until you are sure you can go online again.
Our team will have to put in a lot of effort to achieve a good function. Adrian needs to create a plan for automatic deployment. When a customer requests that a service be started, the necessary environment is automatically deployed to ensure that the service can run without our intervention. Similarly, when a customer’s service is turned off or suspended, an automation solution must be in place. If the customer must contact us every time they deploy or go offline, the customer experience must be poor, and we must also hire a large number of people to serve them (Not our wish).
Kiwicode’s products already have a lot of features, but we need to get closer to the customers’ use cases: for example, some customers have a lot of API connections. Slack can connect to APIs from a variety of companies, and customers’ applications have a variety of interface requirements.
The next article ‘Kiwicode startup story(12): No vendor lock’ is published. Simply send me some claps and feedback if you enjoyed my story.
If you want to join our product — Kiwicode (a code generation SaaS)’s waitlist, click here.
