I like that you point out that the cost to build software is still not 0. And in my expirence it’s further from 0 than I would expect. I often find myself thinking I can rebuild a project (or usually improve upon an existing one) in just a few days. And yet when it comes down to making anything well, it still takes time and iteration.
It’s a bit funny because I felt this way before coding agents as well, like you could clone something in just a few weeks. But in practice my expectations are rarely accurate.
I find myself fixing the spec of my software often, and that makes lots of existing code obsolete. Creating working code is getting cheaper with AI, but creating great specs which make the software easy and intuitive to use seems to be more difficult for AI.
Why? Because you have to actually use the product to discover what is wrong, or sub-optimal, with it.
I have multiple side projects that I would never have contemplated building before but whose utility now exceeds the much lower cost to build.
I got a few weeks in to each and then stalled on all of them because the effort and motivation required to extend beyond the crazed early days _is_ still more than the utility I get.
In a professional context, paying someone for software to do something outside my core domain is still the practical option compared to the motivation and effort needed to maintain another dependency.
I wouldn't underestimate the community effect of software. There are plenty of features that get shipped because a small but important minority requested them, only to benefit the long tail of users who never knew to ask for such a feature but now find it indispensable. If everyone is building their own isolated solutions, how does this positive externality manifest itself?
Also, some software businesses use a ton of aggregated or hard to get data which needs to be synthesized and that doesn't go away even if the llm driven coding is cheap.
Not a SalesForce dev, but there is a bit of oversimplification what CRM SaaS is today.
Almost everything integrates with SF today and most often understanding, replicating and maintaining these integration pathways may need more than 1.5 engineers. You then bring 3 engineers (to cover absences) and buy enough tokens.
And we haven't even scratched other parts: disaster recovery, security, legal (CCPA/GDPR), etc
I would say that the main reason to buy corporate software is to delegate responsibility to a 3rd party. By doing in-house you take the legal, regulatory responsibility of pretty sensitive records, that will definitely bite you in the future, or will easily inflate the build costs
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 bureacracy that cost two orders of magnitude more than the expense the bureacracy 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 enterpreneurship, by far.
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.)
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.
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.
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?
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.
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.
Good luck on your new endeavour! Selling to devs is hard, did you consider building in public? That would def help get traction imo.
Your point about considering API design and overall architecture would definitely differentiate among the all AI slop out there
It’s a bit funny because I felt this way before coding agents as well, like you could clone something in just a few weeks. But in practice my expectations are rarely accurate.
Why? Because you have to actually use the product to discover what is wrong, or sub-optimal, with it.
I got a few weeks in to each and then stalled on all of them because the effort and motivation required to extend beyond the crazed early days _is_ still more than the utility I get.
In a professional context, paying someone for software to do something outside my core domain is still the practical option compared to the motivation and effort needed to maintain another dependency.
Also, some software businesses use a ton of aggregated or hard to get data which needs to be synthesized and that doesn't go away even if the llm driven coding is cheap.
Almost everything integrates with SF today and most often understanding, replicating and maintaining these integration pathways may need more than 1.5 engineers. You then bring 3 engineers (to cover absences) and buy enough tokens.
And we haven't even scratched other parts: disaster recovery, security, legal (CCPA/GDPR), etc
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 enterpreneurship, by far.
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.)
Build a good product and they will come.
That said, I think the path Brandur is describing is well-trodden and proven out by projects like Sidekiq.
and
https://xkcd.com/1205/
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.
Not to mention enshittification, predatory prices increases, the supplier getting bought out, etc. The list goes on...