zlacker

>>vimes6+(OP)
Well the counter argument is that shipping later also destroys value (because value can only actually start to be accumulated once a product has shipped).

But this article doesn't seem to address the obvious counter-point.

For instance, take the below:

> wouldn't you rather run a your customer's payments through code that is at least attempting to handle error conditions, rather than some happy path code that just assumes everything works?

But this doesn't address the obvious issue which is, there is value destroyed (or not created) by not allowing customers to pay you earlier.

>>Closi+w7
I really don't like this conclusion. I guess this is why we need financial regulation, because rushing through a buggy payment system so you can make a buck quicker is how customers get their accounts hijacked and identities stolen. Maybe as an early-stage investor or company founder, it makes no difference to you because you'll exit before anything ever hits the fan and the law will never hold you accountable, but you might be ruining people's lives. Certain systems need to be robust even if it means businesses might have to earn revenue more slowly. You're not creating value in this case. You're stealing it from your customers.

>>noname+rh
The article is talking about integrating a payment gateway, so I don't think this specific risk is valid but the overall point is right - yes, there is a trade off between speed to market and how many workarounds will be required.

The truth is that sometimes speed to market is more important than quality, and visa-versa. Handling sensitive credit card data? Sure quality and security are important of course. Implementing a payment gateway to bootstrap a company where that is 1 of 100 tasks before go-live? Hack away and go as fast as possible, and worry about improving it later!