Comment by mewpmewp2
12 hours ago
What if you are about to get a potentially really high paying customer, but they might go elsewhere unless you deliver X feature immediately and it is so much quicker to do it with the JS script?
12 hours ago
What if you are about to get a potentially really high paying customer, but they might go elsewhere unless you deliver X feature immediately and it is so much quicker to do it with the JS script?
Given that the potential high paying customer is just that - a potential, one must always keep the long term platform stability in mind as it affects every other customer, not just this potential customer. Hence, it boils down to opportunity cost and setting the right expectations:
We can deliver feature X for you - incrementally broken down into sub-features x1, x2, x3 over a period of Y weeks/months
The other way to do this would be to build a custom integration on top of your existing APIs and beta test it alongside the customer, bill them accordingly and eventually merge the changes into the main platform, once you can guarantee stability.
But, both these methods will sound boring to VC funded companies as they are under constant pressure from VCs to show something in their weekly graphs - meaningful or not.
The customer could be on the fence between you and a competitor and this customer could be potentially paying 10x more than all your existing customers together. It could make or break your company. They would go to the competitor immediately if you make it complicated for them and have delays with the setup. What do you do then?
Sounds like a bad business model then - if you have to depend on one single customer to make or break your company.
1 reply →