LoMApps business model
Our business model for LoMAppS is to charge a very modest pay-per-run fee that does not entitle the user to personalised support. We will take note of issues via e-mail and will fix those that are affecting users widely. Individual users experiencing idiosyncratic issues will be left to sink or swim.
The reason for this business model is that we perceive our users to be individuals or very small teams for whom price of services is a major issue. Hence the low pay-per-run fee. Being developers they are likely to be able to sort issues out for themselves. So being expected to do so is a fair trade-off for the low usage price.
APILoader business model
Our business model for APILoader is the SODaaS variant of the SaaS model. Also known as the bulldozer varient, SODaaS provides software (S), an operator (O), and custom development (D) as a service. Just like hiring a bulldozer, with the development being akin to reconfiguring the bulldozer by changing blades.
We don't supply APILoader as shrink-wrapped software that you can purchase. Instead we run it on your behalf. To that extent we participate directly in your performance engineering project. And we bill for our time at performance engineer rates.
The reason for this business model is that at the price at which we could expect to sell APILoader we would need about 1,000 customers to reach payback of development and marketing costs. And we simply don't have the resources, or the desire, to support that many customers at the level to which the purchase price would entitle them.
Our typical customer, one who uses the very high throughput capability of APILoader, is a one-off using an in-house developed system. We expect them to require custom development of APILoader to suit their needs. We charge for that development at normal developer rates.
Don't like this model ? Can't say I blame you. See alternative models for alternatives.
Sales process
- You contqct us for a preliminary discussion about your needs.
- We agree on a proof-of-concept use case and a rate at which to run it.
- You send us a JAR file containing your Java API cient.
- You send us a JAR file containing any external libraries required to run your Java API cient.
- You provide us with sufficient JavaDoc or other documentation to allow us to understand the data needs of the API calls in the proof-of-concept use case.
- We put a Java wrapper round your API client. We upload the wrapped client to APILoader. We build the proof-of-concept use case.
- You make a test system available against which we can run the use case. If you are not comfortable exposing the test system over the internet then we can come to you. Alternatively we can build a server that simulates handling of the use case at the agreed rate, but for this we bill you (probably a days work).
- We run the use case at the agreed rate. We make the results available to you.
- We extend the proof of concept as agreed until you are satisfied you wish to proceed with APILoader.
- We begin to run APILoader on your behalf.
Alternative business models
The reason we don't generally sell APILoader is that we aren't in a position to support the number of customers that it would take to recover the development cost through sales revenue.
But you can buy it if you want to. We will sell it to you, on a non-exclusive licence, for half the cost of development or $US150,000. But support would be on a time and materials basis and for a limited period. We will be willing to work with you to transition support to your people at normal rates.
Alternatively we are happy to work with you to develop your own APILoader. APILoader evolved from a couple of earlier products and could be much simplified now the purpose of the product is stabilised. For a single owner-user it could be simplified again. If you don't need the very high throughput that APILoader currently supports it could be simplified quite a bit further.
Still not happy and still want to use the product ? Then contact us.
Business opportunity
Frankly, APILoader has more upside than we can exploit.
We see four opportunities:
- API load testing tool
- Like it says on the box - a very high throughput, very easy-to-use API client load testing tool. Our target is obviously the big end of town.
- A front-end to BlazeMeter
- Blazemeter's big weakness, if you can point to a weakness in such a successful product, is that you have to bring your own JMeter test plan. APILoader builds its own test plans and has the potential to be a VAR for Blazemeter.
- Generalised cloud deployment
- APILoader includes sophisticated capability to allocate, configure, run, monitor, control, and terminate cloud provider machines. This capability could well be generalised to deployment of cloud machines, in bulk, to specific problems. We have reserved the domain name cloudmobiliser.com for this purpose.
- Performance testing process aware record and playback load testing tool
- APILoader supports record and playback based load testing of HTTP and HTTPS. And it does so without requiring any scripting. The operations necessary to customise recordings and to capture and reuse run-time values have been abstracted and built into APILoader's GUI. As far as we know this is an advance on current tools.
If you want to exploit one or more of these then contact us.
Contact details
