I'm sure Stripe EU is subject to EU regulations, just like Adyen. But unlike Adyen, they are also subject to some US regulations due to being a subsidiary. And, highly likely, they run software systems build by their US counterpart, meaning data exfiltration or even sabotage is trivial.

Really? Must be a recent thing then..? I've used them for all sorts of small (and not so small) things.

Mollie (also Dutch) existed even before Adyen (and way before Stripe). They have no problem dealing with small customers, and have always offered a trivially easy to use API.

Love for Mollie - and literally had this exact theme last year at work. Stripe implemented, then customer A couldn't use it due to US base, so went to Adyen, built integration, rejected as less than $5 million as first responder said, then went to Mollie.

Only gripe is no embeddable checkout but its not a huge deal, and they have superior test platform than even Stripe. The test cards are right there in slide in panel, and you have option to select paid/cancel/fail etc to test different outcomes.

Sure there are. Both Mollie and Adyen are API-first. Mollie developer experience has always been on par with Stripe in my experience. And they existed 6 years earlier.

> But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies.

Each of these three sentences are in need of some evidence. I'm not actually seing any signs of software velocity notably increasing anywhere. Except perhaps in the AI-reseller sphere, but that seems mostly due to throwing huge amounts of VC money at it and a lack of quality control.

Yes, but one wouldn't quote these as if they were trusted sources either.

Where are you seeing such a narrow pay band? I don't have a great view on the market, but that strikes me as really odd.

Kotlin is a terrible language for learning, as it has a lot syntactic shortcuts that are easy to mistake for magic. I think it's actually easier to learn some Java first, as it's simpler and teaches you the semantics both languages (mostly) share.

> So, assuming we can all make "good enough" code

Your entire argument hinges on "good enough". Problem is: you can never know if something is "good enough", except in hindsight for those products that succeeded.

I'm upvoting you because your comment is well made, and certainly common, even if it is nothing more than a tautology :)

The bar for "good enough" can be set quite low. In general, consumers can be convinced to buy almost anything. And their resistance to good marketing is very weak.

The problem with presenting good examples is that decades of sustained marketing is hard to overcome even with facts which are immediately obvious. Indeed good marketing has already negated those facts.

For example smoking is objectively terrible and yet was (and is) very popular for decades. Tobacco might be out, but vaping is still cool; same message as before.

From outside its easy to spot US examples because their absurdity is obvious to outsiders. It's harder to see examples in one's own society (because we have our own marketers.)

In software land there is obviously lots and lots of complete rubbish. Most of it gets no marketing at all. But is Windows the best OS? Is Chrome the best browser? Is Google the best search engine? Is Facebook the best social network?

Or do each of those have a competitor with "better code" that has no marketing and gets no traction?

When IBM hooked up with MS was it because of good code? When Sun bought MySql was it for the customer base, and Brand, or the code?

Did Facebook buy WhatsApp for 18 billion because of the code? Fo you think they compared the code to some other messenger with 100 users, or did the 400 million people using WhatsApp matter more?

In truth every product you ever heard of, and ever used, was good enough. Github is full of projects with really great code and no users.

There's a fundamental disconnect between business people and codesmiths. The programmer wants another year to craft perfection. The business needs to start selling and earning next week.

Good code lasts longer, and is better for the company in the long run. Engineers know this. Companies know they have to ship, and sell and earn, to survive at all. Engineers sneer at marketing, the product should be good enough. (Tell that to Amiga.) Marketeers are frustrated by Engineers who want to build forever and never ship. (Any wonder they want to replace us with AI.)

Yes AI products are objectively worse. But if history tells us anything; that doesn't matter.

I agree with most of what you're saying.

But was Google the best search engine when they got popular? Most definitely! Chrome the best browser? According to most, yes! When MySQL got popular, that was also due to it being the best free product out there at the time.

That is to say, a good product can easily be the key factor to growth. Especially in the critical early phase. But it'll have to be a lot better than the well-known alternative.

But doesn't your counter point assume all products that failed were not good enough?

Well, at least the combination of code, marketing and luck wasn't good enough.

Sure, but the context here is only about code.

I think in your StableDiffusion example, a lot more than $600k will have been spend on electricity alone for inference (on those personal computers you mention). So inference is more expensive then training.