[applfanboysbgon]

Be careful with making decisions about your livelihood based on a rational calculus. As you correctly point out, there is a threshold for which a programmer or company should not even blink at the cost of software. It's often the case that if the software they're buying saves one single hour of productivity, it's value-positive... and yet they won't buy it. Individual devs are notorious for refusing to pay a cent out of their own wallet, turning up their noses at anything that isn't offered open source and completely free. Enterprises manage to saddle what should be a no-brainer trivial expense into dozens of hours of bureaucracy that cost two orders of magnitude more than the expense the bureaucracy is for.

Your customers are more irrational than you are, and your appeal to them will likely need to resonate with them on an emotional level rather than logical one. I would argue that marketing is the hardest part of entrepreneurship, by far.

[brandur]

Yes, I roughly agree with all of this. In fact, for most of my existence, I'm been one of those cheap programmers.

The circumstances that led to me trying to push River for the next few months were somewhat accidental, and it felt like a good moment to at least make a go of trying to make it work. I'm not committing the rest of my career/life to any particular decision one way or the other.

I'll reiterate too that I believe we're still quite early in the LLM age and are still waiting for the other shoe to drop. All LLM-generated software feels free at the moment because it's still novel and the exhilaration of accomplishment when you build something complex inside of a few hours is addictive beyond words. However, within a year or two I think we're going to have a lot more software, all of which needs maintaining to some degree, and we're going to become a little more reluctant to generate new projects to add to the heap. This'll cause an adjustment back to a more compromise position.

(Also, could be completely wrong about all of that, so take it for what it is.)

[chrisweekly]

"one of those cheap programmers"

"one of those stingy programmers" might be clearer wrt this use of "cheap" meaning "tightwad" not "inexpensive"

[aaronbrethorst]

Plus, too many companies don't spend their money in a logical fashion. As a manager, you can direct your $200,000/year engineer in any way you want, but try to spend any amount of money on a new SaaS product and procurement might huffily demand hours of your time and weeks of delay to authorize even $40/month, let alone $400/month.

That said, I think the path Brandur is describing is well-trodden and proven out by projects like Sidekiq.

[Aurornis]

Some of my past employers were pretty good about authorizing small and medium expenditures quickly, or in some cases not requiring any authorization at all.

This feature almost always went away as the company grew and the abuse became too much to ignore. I thought it would be safe to trust developers and to deal with isolated abuse when it came up, but the number of people who see any spending perk and treat it like a target they need to maximize is way higher than I ever thought.

There are a lot of examples of this, like companies that offer to pay for dinner if people have to stay late. This seemingly always turns into a game where people hang out in the office and scroll on their phones until the allowed time arrives, then they take their dinner and leave. This doesn’t happen at small companies where you can witness what people are doing, but cross the threshold to big company and many people start doing whatever they can get away with.

There was a big story a few years ago about how employees at a big company were even caught using this perk to order their home groceries because the DoorDash like service they used had launched a section where they could get those things delivered with their food. It was crazy that employees making mid six figure salaries were still brazenly breaking the rules for personal gain of a couple hundreds of dollars per month.

[hilariously]

This is one of those things that makes me go insane at the last three companies I worked at and the reality is there's just an in group of people whose purchases are basically auto approved, and anyone below our out of this group might as well pound sand.

This creates so many weird inefficiencies that I have seen an entire billion dollar companies analytics run on free google sheets + compute because they couldn't figure out what to use for five years.

[ezekg]

Thankfully, most devs aren't the one making purchasing decisions in B2B. I haven't seen any change in the build vs buy equation for real businesses tbqh, and in B2B, those are the customers you want to target anyways, not the indie devs who think they can build Dropbox in a weekend. In B2C, I can definitely see this being true, but I have very little experience there so anything I say here is more on gut-feeling than anything else. But I have over 10 years of experience in B2B, and I've never seen businesses more eager to buy, to free teams up to work on the things they're experts at -- myself included.

Build a good product and they will come.

[claw-el]

If we can show that the hour of productivity saved is worth more, would the individual dev still want to build it because they like tinkering with it. The individual dev would value the time of playing with the code more than the time of productivity saved?

[fragmede]

https://xkcd.com/1319/

and

https://xkcd.com/1205/

[Eridrus]

I think people are more rational than given credit for. Their decisions are not necessarily rational for the company, but they are often pretty rational for themselves.

And some bureaucracy is often necessary to evaluate security, data protection agreements, etc.

Some companies are not efficiently allocating resources and so projects sit in legal/security review for longer than is reasonable, but it makes sense that individual developers don't have unilateral authority to use 3rd party vendors.

[cadamsdotcom]

Thanks applfanboysbgon, this is the type of comment every HN commented should aspire to!

Packed full of insightful comments that cut against the grain and are logical even if unpleasant to hear, delivered with kindness and a thoughtful, caring tone, and backed up with strong justification.

Did I mention delivered with kindness?

And it mirrors my experience. The struggle has me convinced that to sell anyone anything your offer has to be so overwhelmingly good they’d not just win from having it but lose from not having it. It’s why the slick salespeople of old would talk for minutes at you just to get you to buy a thing once - non stop talking attacking your objections from every angle before finally moving on to the price. Sure, as the person offering the thing you see the value - but your prospect just showed up to your site, they’ve got an Amazon purchase to finish on another tab, the baby is crying in the other room, and there’s an outage. Sorry - your thing does what again?

[pphysch]

Dismissing software non-buyers as irrational, or asserting certain purchases are "no-brainers" is missing the mark.

Acquiring new software is a major commitment beyond just the price tag. It means integration, continuous maintenance, dealing with forced UI updates, supply chain exposure, and so on.

Every seasoned dev (unless very lucky) has dealt with bad software acquisitions, almost all of which seemed to be great deals at the time of purchase.

[DougN7]

This is so true, and it’s true of libraries, OSS, etc. I frequently build instead of using a library simply because I’ll know and can fix the warts, I’m automatically in tune with the state of the code, and I’m in control of maintenance. Of course if the code is too big (TLS library like OpenSSL) then it changes. But I still try to avoid external stuff just because of the costs you listed.

[arcanemachiner]

> integration, continuous maintenance, dealing with forced UI updates, supply chain exposure, and so on

Not to mention enshittification, predatory prices increases, the supplier getting bought out, etc. The list goes on...