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?
The minimum viable unit of saleable software
11–20 of 89 posts
Re: The minimum viable unit of saleable software
#12Good 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
Re: The minimum viable unit of saleable software
#13Be 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…
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…
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.
Re: The minimum viable unit of saleable software
#14Be 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…
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?
Re: The minimum viable unit of saleable software
#15Not 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
Re: The minimum viable unit of saleable software
#16I 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.
Re: The minimum viable unit of saleable software
#17Be 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…
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…
> 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...
Re: The minimum viable unit of saleable software
#18Not 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
Re: The minimum viable unit of saleable software
#19I 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 cou…
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.
Re: The minimum viable unit of saleable software
#20I 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 cou…
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.
Yeah exactly, I literally don’t know how to change my spec until I’ve gathered more data.
I was building a transaction classifier recently and I initially thought it would be a trivial “solved” problem. Throw transactions into a tiny local LLM, let it classify. But that approach was too slow, and not accurate enough. I didn’t know that though until I tried and then needed to change the spec.