3 ms·

You can price based on eng time saved, but the rejoinder will be that the devs use test time to answer emails, respond in slack/jira, etc. And to some extent t

by x0x0 4y ago

You can price based on eng time saved, but the rejoinder will be that the devs use test time to answer emails, respond in slack/jira, etc. And to some extent that's probably true. I do have some very strong advice on how not to charge: (1) do not charge based on your costs (customers won't care), and (2) do not charge based on fine-grained usage. The latter is important because if a VPE signs a contract for $3k/mo, he/she doesn't want to sit there worrying that devs run a couple extra tests or add a few tests, etc, and boom: all of a sudden the VPE is going to the cfo to explain $10k in overage charges. So: price in broad tiers, and price based on value. If you save hundreds of eng hours/mo, charge for the first 20 hours saved. At $150 per, that's $3k/mo. Multiply by 5 to have a functional company (you can't do sales for under $10k; every successful sale -- which will be 20% if you're very good and lucky -- must pay for all failed sales, all marketing, all dev, etc. Oh, and you're doing sales.) So $15k/mo. That's within the approval authority for a vpe with 50 reports. And accept that bigger companies don't worry about $2k-$3k/mo. So maybe your target should also be smaller shops that can't accept the infra overhead to build this out, but will buy a cheap solution that saves their 1-4 devs a ton of time. Dunno. edit: and you need a strong cross-tenant security story.

Silhouette 4y ago
The latter is important because if a VPE signs a contract for $3k/mo, he/she doesn't want to sit there worrying that devs run a couple extra tests or add a few tests, etc, and boom: all of a sudden the VPE is going to the cfo to explain $10k in overage charges. Counterpoint: I have personally seen companies of the size OP is talking about run into unexpected big jumps in spending on key infrastructure and tooling because they made some architectural change and then suddenly realised it was going to run the tests 10x as often or something. Without exception the response has been twofold. First they did take the immediate financial hit because they couldn't afford to be without a critical system. Second they diverted significant resources to getting the usage levels back under control very quickly so they didn't have to rework that critical infrastructure as well. If anything, since bringing the costs of some important infrastructure down is exactly the problem OP's tool is solving and its value is directly demonstrable in terms of time and therefore money saved, your general argument should be a positive sign for OP that they probably have a viable business model. I could buy an argument that tiered pricing might work better for OP than metered if someone showed up with data supporting the theory. But metered pricing seems to be working out pretty well for a lot of popular cloud-hosted dev tools and of course is almost universal among cloud infrastructure providers. People complain a lot about AWS having unpredictable pricing but I heard AWS has still had some success breaking into the cloud hosting market and probably it's making enough money that Amazon might keep it running. To be fair that's partly because although AWS lacks safeguards that would certainly be welcomed by many it does also have a reputation for being very decent about support in the occasional "Oh s@£t" scenarios.
- x0x0 4y ago
  Metered: significant internal and external resources are devoted to understanding aws spend. See the whole industry springing up around this, starting with Duckbill. No vpe is looking to add more to that list of things they have to understand and plan out. Flat rate or bucketed pricing is common across many dev tools. eg ci/cd: see bamboo, gitlab ci/cd (purchased in blocks), circleci (credits w/ account, more credits sold in blocks). apms like honeycomb.io. etc.
  - Silhouette 4y ago
    Some of the companies I mentioned were using some of the tools you mentioned. You don't necessarily avoid the price shock with tiered pricing models. It just means there's a step function and if some change does unexpectedly put you over the next threshold that just became some relatively senior people's #1 problem today.

by x0x0 4y ago

Silhouette 4y ago

The latter is important because if a VPE signs a contract for $3k/mo, he/she doesn't want to sit there worrying that devs run a couple extra tests or add a few tests, etc, and boom: all of a sudden the VPE is going to the cfo to explain $10k in overage charges. Counterpoint: I have personally seen companies of the size OP is talking about run into unexpected big jumps in spending on key infrastructure and tooling because they made some architectural change and then suddenly realised it was going to run the tests 10x as often or something. Without exception the response has been twofold. First they did take the immediate financial hit because they couldn't afford to be without a critical system. Second they diverted significant resources to getting the usage levels back under control very quickly so they didn't have to rework that critical infrastructure as well. If anything, since bringing the costs of some important infrastructure down is exactly the problem OP's tool is solving and its value is directly demonstrable in terms of time and therefore money saved, your general argument should be a positive sign for OP that they probably have a viable business model. I could buy an argument that tiered pricing might work better for OP than metered if someone showed up with data supporting the theory. But metered pricing seems to be working out pretty well for a lot of popular cloud-hosted dev tools and of course is almost universal among cloud infrastructure providers. People complain a lot about AWS having unpredictable pricing but I heard AWS has still had some success breaking into the cloud hosting market and probably it's making enough money that Amazon might keep it running. To be fair that's partly because although AWS lacks safeguards that would certainly be welcomed by many it does also have a reputation for being very decent about support in the occasional "Oh s@£t" scenarios.

x0x0 4y ago
Metered: significant internal and external resources are devoted to understanding aws spend. See the whole industry springing up around this, starting with Duckbill. No vpe is looking to add more to that list of things they have to understand and plan out. Flat rate or bucketed pricing is common across many dev tools. eg ci/cd: see bamboo, gitlab ci/cd (purchased in blocks), circleci (credits w/ account, more credits sold in blocks). apms like honeycomb.io. etc.
- Silhouette 4y ago
  Some of the companies I mentioned were using some of the tools you mentioned. You don't necessarily avoid the price shock with tiered pricing models. It just means there's a step function and if some change does unexpectedly put you over the next threshold that just became some relatively senior people's #1 problem today.