No offence, but inexperienced JS fanatics always do this because of some weird affectionado they have for the language itself. Otherwise, even a decently qualified CTO would have chosen to keep everything in Go from the beginning or might have not waited until they were bleeding $300k. JS is also the worst possible language choice for this problem. So, it definitely sounds a bunch of script kiddies with fancy titles bought with VC money rather than actual experience.

▲

mewpmewp2 an hour ago | parent [-]

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?

▲

neya an hour ago | parent [-]

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.

	▲	mewpmewp2 39 minutes ago \| parent [-]
		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?