From where I sit, right now, this does not seem to be the case.
This is as if writing down the code is not the biggest problem, or the biggest time sink, of building software.
Often these SaaS tools are expensive, aren't actually that complicated (or if they are complicated, the bit they need isn't) and have limitations.
For example, a company I know recently got told their v1 API they relied on on some back office SaaS tool was being deprecated. V2 of the API didn't have the same features.
Result = dev spends a week or two rebuilding that tool. It's shipped and in production now. It would have taken similar amount of time to work around the API deprecation.
NODS HEAD VIGOROUSLY
Last 12 months: Docusign down 37%, Adobe down 38%, Atlassian down 41%, Asana down 41%, Monday.com down 44%, Hubspot down 49%. Eventbrite being bought for pennies.
They are being replaced by newer, smaller, cheaper, sometimes internal solutions.
How many samples do you have?
Which industries are they from?
Which SaaS products were they using, exactly and which features?
> ...a company I know recently got told their v1 API they relied on on some back office SaaS tool was being deprecated. V2 of the API didn't have the same features ... dev spends a week or two rebuilding that tool
Was that SaaS the equivalent of the left-pad Node.js module?
It definitely has for me. I'm creating toolS and utilities every week easily that I never would've attempted in the past.
> This is as if writing down the code is not the biggest problem, or the biggest time sink, of building software.
Lots of people can think logically and organize a process flow, but don't know all the ridiculous code incantations (and worse development and hosting environment details) to turn their plans into tools.
It's trivial to one-shot all kinds of impressive toys in Gemini now, but it's going to be an even bigger deal when Google adds some type of persistent data storage. It will be like the rebirth of a fully modern Microsoft Access.
- Maintenance, Security
- Upgrades and patches
- Hosting and ability to maintain uptime with traffic
- Support and dealing with customer complexities
- New requirements/features
- Most importantly, ability to blame someone else (at least for management). Politics plays a part. If you build a tool in-house and it fails, you are on the chopping block. If you buy, you at least can say "Hey everyone else bought it too and I shouldn't be fired for that".
Customers pay for all of the above when they buy a SAAS subscription. AI may come for most of the above at some point but not yet. I say give it 3-5 years to see how it all pans out.
Now, that's not exactly the same thing, but their paucity of skills made them terrified to do something like this before, they had little confidence they could pull it off and their exec team would just scoff and tell them to work on other revenue generating activities.
Now the confidence of Claude is hard to shake off of them which is not exactly the way I wanted the pendulum to swing, but its almost 500k yearly back in their pockets.
I recently found some assembly source for some old C64 games and used an LLM to walk me through it (purely recreational). It was so good at it. If I was teaching a software engineering class, I'd have students use LLMs to do analysis of large code bases. One of the things we did in grad school was to go through gcc and contribute something to it. Man, that code was so complex and compilers are one of my specialties (at the time). I think having an LLM with me would have made the task 100x easier.
We've got an backend pipeline that does image processing. At every step of the pipeline, it would make copies of small (less than 10MB) files from an S3 storage source, do a task, then copy the results back up to the storage source.
Originally, it was using AWS but years ago it was decided that AWS was not cost effective so we turned to another partner OVH and Backblaze.
Unfortunately, the reliability and throughput of both of them isn't as consistent as AWS and this has been a constant headache.
We were going to go back to AWS or find a new partner, but I nominated we use NFS. So we build nothing, pay nothing, get POSIX semantics back, and speed has gone up 3x. At peak, we only copy 40GB of files per day, so it was never really necessary to use S3 except that our servers were distributed and that was the only way anyone previously could think to give each server the same storage source.
While this isn't exactly what the OP and you are talking about, I think it illustrates a fact: SaaS software was seen as the hammer to all nails, giving you solutions and externalizing problems and accountability.
Now that either the industry has matured, building in-house is easier, or cost centers need to be reduced, SaaS is going be re-evaluated under the context of 'do we really need it'?
I think the answer to many people is going to be no, you don't need enterprise level solutions at all levels of your company, especially if you're not anywhere near the Fortune 1000.
There have been a lot of little blogs about "home cooking" style apps that you make for yourself. Maybe AI is the microwave meal version.
You had all these small-by-modern-standards teams (though sometimes in large companies) putting out desktop applications, sometimes on multiple platforms, with shitloads of features. On fairly tight schedules. To address markets that are itty-bitty by modern standards.
Now people are like “We’ll need (3x the personnel) and (2x the time) and you can forget about native, it’s webshit or else you can double those figures… for one platform. What’s that? Your TAM is only (the size of the entire home PC market circa 1995)? Oh forget about it then, you’ll never get funded”
It seems like we’ve gotten far less efficient.
I’m skeptical this problem has to do with code-writing, and so am skeptical that LLMs are going to even get us back to our former baseline.
I'm not advocating for everyone to do all of their math on paper or something, but when I look back on the times I learned the most, it involved a level of focus and dedication that LLMs simply do not require. In fact, I think their default settings may unfortunately lead you toward shallow patterns of thought.
Don't forget the second-order effect of clients deciding they could do it in-house.
Even with perfect prompt engineering, context rot catches up to you eventually. Maybe a fundamental architecture breakthrough will change this, but I'm not holding my breath.
This was in service of a time when tech was the great equalizer, powered by ZIRP. It also dovetailed perfectly with middle managers needing more reports in fast growing tech companies. Perhaps the pendulum is swinging back from the overly collective focus we had during the 2010s.
My bet is if there were a lot of great apps being built, even excellent quality, nobody would even hear about them. The big players would copy them before anyone even found out about them.
IMO, the market is not even a playing field anymore, this is why everyone is getting into politics now, though politics is also somewhat monopolized, there is still more potential for success because there is such an abundance of dissatisfied people willing to look outside of mainstream channels. It's much easier to sell political ideologies than to sell products.
What you've listed are the easy parts that are within people's control. You didn't list the most critical part, the actual bottleneck which is not within people's control.
The market is now essentially controlled by algorithms. I predict there will be amazing software... Which will end up ignored by the markets completely until their features are copied by big tech and nobody will know where the idea originated.
Building is absolutely worthless in the context of a monopolized marketplace.
80's/90's dev teams were more weird nerds with very high dedication to their craft. Today devs are much more regular people, but there are a lot more of them.
When I had to deal with/patch complex c/c++ code, I rarely ever got a deep understanding of what the code did exactly - just barely enough to patch what was needed and move on. With help of LLMs it's easier to understand what the whole codebase is about.
So a combination of both is useful.
Counterpoint: What might have happened is that we expect software to do a lot more than we did in the 90s, and we really don't expect our software features to be static after purchase.
I agree that we sometimes make things incredibly complex for no purpose in SE, but also think that we do a rose-colored thing where we forget how shitty things were in the 1990s.
For anything that is billed by the human, O365 is the benchmark. I’m not paying some stupid company $30/mo for some basic process, I use our scale to justify hiring a couple of contractors to build 80% of what they do for $400-600k in a few months. Half the time I can have them build on powerapps and have zero new opex.
Most SaaS used to be killed by bespoke software engineers that would build some custom thing, and it was integrated perfectly into the legacy system.
Then all those people decided to be managers and go on "i dont care" autopilot mode and hired a bunch of teens that still do care, to some extent. But those teens suck at it, and the old guys just don't really care anymore.
Now with agentic code, instead of "buy splunk" or "buy jira" or whatever thing they are trying to do, they have one of those "teens now in their mid twenties" that are SUPER excited about Agentic flows, either write an agentic tool or simply use an agentic tool to code up the 300 lines of code that would replace their need for a Jira or a Splunk or whatever. Since most people only use 5% of the total features of any product, there's no reason to buy tools anymore, just build it for a fraction of the cost.
I don't know if the above is where we're at right now, but it's coming.
Nobody would hire the JP Morgan IT team to run a dentist practice IT workload. Likewise, AWS can save you money at scale, but if your business can run on 3 2U servers, it should.
The latter would do very little to support my point, as it doesn't consider future growth trends.
I'm not seeing that either.
And why would the benefits of being able to code faster accrue to a small independent developer over a large company that already has an established reputation and a customer base?
“No one ever got fired for buying Salesforce”.
I once had influence over the buying decision to support an implementation I was leading. I found this perfect SaaS product by a one man shop who was local.
Working with my CTO and lawyers, we made a proposal to the founder. We would sign with him and be 70% of his post signing revenue if he agreed to give us our own self hosted instance and put his latest code in escrow with a third party (Green Mountain) and we would have non exclusive rights to use the code (but not distribute it) under certain circumstances.
I think the difficulty I have is that I don't think it's all that straightforward to assess how it is exactly that I came not just to _learn_, but to _understand_ things. As a result, I have low confidence in knowing which parts of my understanding were the result of different kinds of learning.
Who is going to maintain the local software? Who is going to maintain the servers for self hosted or the client software?
(Or at least AI-assisted to the point where the author feels like they should mention it.)
Outside the specific case of Apple's "magical" cross-device interoperability, I can't think of many areas where this is true. When I step outside the Apple ecosystem, stuff feels pretty much the same as it did in 2005 or so, except it's all using 5-20x the resources (and is a fully enshittified ad-filled disjointed mess of an OS in Windows' case)...
> I agree that we sometimes make things incredibly complex for no purpose in SE, but also think that we do a rose-colored thing where we forget how shitty things were in the 1990s.
... aside from that everything crashes way, way less now than in the '90s, but a ton of that's down to OS and driver improvements. Our tools are supposed to be handling most of the rest. If that improved stability is imposing high costs on development of user-facing software, something's gone very wrong.
You're right that all the instability used to be truly awful, but I'm not sure it's better now because software delivery slowed way down (in general—maybe for operating systems and drivers)
What LLMs demonstrate is that the problem is dealing with people, not software. Look at the number of open source maintainers who are hanging it up.
Unless you have a path to monetization, writing software for anybody but yourself is a fool's errand.
1. Personally I find writing software for the web far more difficult/tedious than desktop. We sure settled on the lowest common denominator
1a. Perhaps part of that is that the web doesn't really afford the same level of WYSIWYG?
2. Is it perhaps more difficult (superlinear) to write one cloud SaaS product that can scale to the whole world, rather than apps for which each installation only needed to scale to one client? Oh and make sure to retain perfect separation between clients
2a. To make everything scale, it's super distributed, but having everything so distributed has a huge cost
3. Some level of DLL hell, but something different (update hell?) I barely do any programming in my free time anymore because I would end up spending almost the whole time needing to deal with some barrage of updates, to the IDE, to the framework, to the libraries, to the build infrastructure
3a. There's always a cost to shipping, to the development team and/or the users. With releases so frequent, that cost is paid constantly and/or unpredictably (from the development or user perspective)
3b. Is there any mental sense of completion/accomplishment anymore or just a never-ending always-accelerating treadmill?
3c. I wish I could find the source but there was some joke that said "software developers are arrogant or naïve enough to think that if you take a marathon and just break it up into smaller parts you can 'sprint' the whole way"
TBH. I'm kind of shocked I still have to explain this. When you get on the wrong side of the algorithms you will understand, you will understand viscerally. And I do mean 'when' not 'if'.
Maybe the algorithms have been working for you so far and you're not feeling them but just give it a few years. Unfortunately, once you understand, you won't have a voice anymore and those still in the game won't have enough empathy to help you.
Of course it makes sense. You just refuse to cope. This is like thinking that marxism is "rich people bad"
Internally it gives us a competitive advantage of the data being in our system from the beginning of the pipeline through the rest of the system where the data would be needed anyway.
But it's for me and tailor made to solve my precise use cases. Publishing it would just add headaches and endless feature requests and bug reports for zero benefit to me.
The bubble means that a) the salaries are higher, b) the total addressable market has to justify those salaries, c) everyone cargo cults the success stories, and so d) the best practices are all based on the idea that you're going to hyperscale and therefore need a bazillion microservices hooked up to multiple distributed databases that either use atomic clocks or are only eventually consistent, distributed queues and logs for everything, four separate UIs that work on web/iOS/android/desktop, an entire hadoop cluster, some kind of k8s/mesos/ECS abomination, etc.
The rest of the world, and apparently even the rest of the US, has engineering that looks a little more like this, but it's still influenced by hyperscaler best practices.
The marketplace for software for single-owner shops or 1-5 employee size places does seem to be quite strong, and then there's enterprise software, but small business seems to have a software marketplace that is atrociously bad. Here is the typical thing a prospective customer asks me to fix for them:
- They are using some piece of software that is essential to their business. - There really isn't much good competition for that software, and it would be a large cost to convert to another platform that also has all the same downsides below. - The software vendor used to be great, but seems to have been sold several times. - The vendor has recently switched to a subscription-only model and keeps on raising subscription prices in the 12% or so range every year, and the cost of this has started to become noticeable in their budget. - They were accustomed to software being a capital investment with a modest ongoing cost for support, but now it's becoming just an expense. - Quality has taken a nosedive and in particular new features are buggy. Promised integrations seem quite lacking and new features/integrations feel bolted on. - Support is difficult to get ahold of, and the formerly good telephone support then got replaced by being asked to open tickets/emails and now has been replaced by an AI chatbot frontend before they can even open a ticket. Most issues go unresolved.
There are literally millions of software packages in existence, and the bulk of them by numbers are niche products used by small businesses. (Think of a software package which solely exists to help you write custom enhancements for another software package which is used by a specific sector of the furniture-manufacturing business, to get an example.) The quality of this sector is not improving.
This is a field that is absolutely ripe for improvement. If the cost of building software really were dropping 90%, this would be a very easy field to move into and simply start offering for $6,000 a year the product that your competition is charging $12,000 a year for, for an inferior product. Before you bring up things like vendor lock-in or the pain of migration... why can't you write software to solve those problems, too? After all, the cost of writing a migration tool should be 90% cheaper now, too, right?
I had a question about how to do something in Django, and after googling found a good SO answer.
I read through it thinking about how much I appreciated the author's detailed explanation and answer.
When I looked at the author it was me from two years ago.
"Today we’re introducing Fizzy. Kanban as it should be, not as it has been. [...] we’ll host your account for just $20/month for unlimited cards and unlimited users. [...] And here’s a surprise... Fizzy is open source! If you’d prefer not to pay us, or you want to customize Fizzy for your own use, you can run it yourself for free forever." https://x.com/jasonfried/status/1995886683028685291
You are saying there aren't more low cost alternatives coming out
You also say writing code isn't the big problem (which I agree with)
But both can be true and in fact the reason is because the second is true! You aren't seeing the alternate because marketing is hard. People generally don't care about new products and aren't willing to save a little bit of money risking their time on something new
make something decent in the same space as an existing mega-corporation's tool? prepare to get sued and they also steal your good ideas and implement them themselves because you don't have the money to fight them in court
The idea here, however, is that machine developers are changing the calculus. If you need more machine developers it takes, what, a few days to produce the necessary hardware? Instead of 20+ years to produce the legacy human hardware. Meaning, for all intents and purposes, there is no observable limit to how much software machine can create, driving the cost towards zero.
Yeah, sure, the tech still isn't anywhere near capable enough to reproduce something like Salesforce in its entirety. But it is claimed that it is already there for the most trivial of services. Not all SaaS services are Salesforce-like behemoths. Think something more like patio11's bingo card creator. It is conceivable, however, that technology advancement will continue such that someday even Salesforce becomes equally trivial to reproduce.
Maintenance is not a meaningful cost unless you also want to continually have the software do more and more. That could tip the favour towards SaaS — but only if the SaaS service is in alignment with the same future you wish for. If you have to start paying them for bespoke modifications... Have fun with that. You'll be wishing you were paying for maintenance of your own product instead. Especially when said machines drive the cost of that maintenance to near-zero all the same.
Local software has to target multiple OSes, multiple versions of those OSes, and then a million different combinations of environments that you as a developer have no control over. Windows update whatever broke your app, but the next one fixed it? Good luck getting your user base to update instead of being pissed at you
The crap I build _replaces_ someone else's SaaS (or free open source) product.
They solve my exact problem and nothing else and they follow the ways I like to use my software, with no fancy Dockerised WebUIs etc.
I have exactly zero intention of putting any of that shit out there as any kind of service with user accounts and billing and all of the associated stress. A few of them might be something I could sell as a SaaS offering, but I'm not interested in it at all.
Most of them are on my Github though for anyone to get and use as they see fit, but then it's up to them if the vibe coded program does something it shouldn't :)
There are SO FUCKING MANY tools for marketing your shitty SaaS all over subreddits dedicated for people to advertise their new services and applications.
I had to unsubscribe from all of them because about a year ago they went from semi-interesting to 100 different "my SaaS AI tool will automatically advertise your AI SaaS tool on social media" solutions every week.
It will not be. Even in this fairly broken state of affairs we are currently in, most non-technical people I spoke to already say that they have too much apps and too much machines with "intelligent" features.
And IMO when we have machines that can crank out a complete-but-better Salesforce, our civilization and race would be in an entirely another level and we would see such things as toys. Who needs that antiquated procurement and tracking expenses software, where's our 174th fusion reactor? What is even that in fact? Oh you mean that nail-sized addon we put on our main processing unit? Yeah we're not interested in ancient software history now. We need more juice to capture those gases around Jupiter for the wireless beaming of energy project! Our DAG-based workflow solver and the 5 AIs around it all said we can't do without it.
...So of course nobody wants to pay programmers. We've been viewed as expensive and unnecessary since the dawn of time. A necessary evil, more or less. But your last paragraph captures why many companies need them -- bespoke solutions. You can only add so many cloud services before your normal staff starts making mistakes on an hourly basis because they have to reconcile data between multiple systems whose vendors will always refuse to make integrations.
And even if many try to have their cake and eat it too -- i.e. have an IT friend they call only for those bespoke enhancements but only pay them during that time and not every month -- then this service will simply become more boutique and expensive, mostly compensating for the lack of salary. You'd do multiple stints for the year that would cover all your expenses and normal lifestyle, it would just not be through a monthly paycheck. Why? Because I think a lot of people will exit programming. So the law of supply and demand will ultimately triumph.
...Or we get a true general AI and it makes all of this redundant in 5 years.
They all work decently enough for my personal use and are 80-100% Vibe coded but about 0% vibe designed.
Why pay for a piece of software that you really only use 5% of all the features, and still may need customizations for. Vs just internally have somebody code a custom solution for your company.
The only benefit of a outside solution is that you can blame a outsider. Internal solution used to be bad because if the person with the knowledge of the codebase left, you ended up screwed. But with LLMs and "vibe" coding, there becomes a disconnect between the code and whoever wrote it. Making it easier to later make modifications on that same codebase, using ... LLMs.
And if it's a free open source application, why would I care if someone can't run it on their specific brand of OS? I'm open to PRs.
If the "user base" wants to update, they can come to the github page and download the latest binary. I'm not building an autoupdater for a free application.
Every SaaS feature in my experience ends up being a mess due to having to support a billion use cases, and figuring it out is more trouble than its worth, might not be able to do what you want, might be buggy.
But even if you do all that stuff, you end up with a mess that can be replaced with 5 lines of shell script. And many more people know shell scripting than figuring out the arcane BS that goes on inside that tool.
It's the eternal lowcode story.
> 'doesn’t make the beer taste better'
I'd say it did. Having a CI/CD pipeline where you don't have to wait for other people's builds, the build logic is identical to what's running on dev PCs, and everything is all-around faster, and more understandable (you can read the whole source) makes testing easier, and surprises less frequent.
All in all, making a hour-long CI/CD turnaround time into 5 minutes or less has been an incredible productivity boost.
If they were a little more chill then I'd think they could make much more money. I personally would pay a few services, even as an individual, right now, if I knew I could always get a good database / JSON dump of everything at a 5-minute notice, and build my own thing on top of it.
They don't get this psychological aspect at all.
In a language context: Immersion learning where you "live" the language, all media you consume is in that language and you just "get" it at some point, you get a feel for how the language flows and can interact using it.
vs. sitting in a class, going through all the weird ways French words conjugate and their completely bonkers number system. Then you get tested if you know the specific rule on how future tenses work.
Both will end up in the same place, but which one is better depends a lot on the end goal. Do you want to be able to manage day-to-day things in French or know the rules of the language and maybe speak it a bit?
Its more then a huge cost, its often insane... We are not talking 10x but easily 100x to a 1000x. Its like when i see some known database makers that scale, write how they can do a million writes per second. Ignoring that they rented a 1000 servers for that, each costing $500 per month. That same software is also 10x to 100x more slower, then a single postgresql database in reads.
So you ask yourself, how many companies do a million writes per second. Few ... How much of those writes may have been reduced by using smarter caching / batching? Probably a factor of 10 to 100x...
The thing i like about scalable solution, is that its way easier to just add a few nodes, vs needing to deal with postgres replication / master setup, when the master node got moved / need to upgraded.
For fun, i wrote my own ART database, and a LSM database using LLMs ... Things do 400 a 500k inserts / second on basic cheap hardware. So wait, why are some companies advertising that they do a million inserts/s, on 500k/month hardware? Some companies may need this ability to scale, as they will not run a 1000 server but maybe 10.000, or more. But 99% of the companies will never even smell close to a 100k inserts/second, let alone a million.
People forget that network latency is a huge thing, but the moment you want consistency and need something like raft, that means now your doing not just 1x the network latency of a write but 4x (send write, verify receive, send commit, verify commit, confirm).
Even something as basic like sqlite vs postgres on the same server, can mean a difference of 3x performance, simply because of then network overhead vs in-function. And that network overhead is just local on the same machine.
And even for the cases where you it is, even with a modern language like Go that makes it easy, you still have tons of OS specific complexity. Service definitions, filesystem operations, signal handling, autoupdates if you want them, etc etc.
While it wasn't perfect, I'd argue software got much worse, and I blame SaaSification and the push for web-based centralization.
Take for example, Docker. Linux suffered from an issue of hosting servers in a standardized, and isolated manner.
The kernel already had all those features to make it work, all we needed was a nice userland to take advantage of it.
What was needed was a small loader program that set up the sandbox and then started executing the target software.
What we got was Docker, which somehow came with its own daemon (what about cron, systemd etc), way of doing IPC (we had that), package distribution format (why not leave stuff on the disk), weird shit (layers wtf), repository (we had that as well), and CLI (why).
All this stuff was wrapped into a nice package you have to pay monthly subscription fees for.
Duplicating and enshittifying standard system functions, what a way to go.
I think in a couple of years we are going to same type of mess. We are already seeing a bunch of shitty AI companies getting funded with no technical cofounders. Look at a few of the YC companies
One thing I've come to realize is that if something is cheap enough then people won't even want to promote it because if they get a commission on it then it won't be worth their time. So in some cases they will be better off recommending a much higher price competitor. Just go Google around for some type of software (something competitive and commercial like CRMs) and you'll notice why for commercial projects nobody is recommending free or really cheap solutions because it's not in anybody's best interest
Aha. Are developers finally realizing that just writing code doesn't make a business? We actually have a ton of SaaS companies being born right now but they're not making headway, because functionality and good code don't necessarily mean good businesses. Building a business is hard.
Edit: I also feel stumped why so many people give in to this hype that LLMs are good at coding when they can't even do seemingly simple tasks of plain English language summarization accurately as evidenced in https://www.youtube.com/watch?v=MrwJgDHJJoE. If the AI summarizes the code in its own context incorrectly then it will not be able to write it correctly either.
LOL
Same as with "everybody will build their own custom apps for everything now" :-D
The terms weren’t as onerous as it sounds. It was basically if he stopped supporting it or got hit by a bus, we would get access.
Categorically, I cannot think of a single current software product that existed then, that I would rather be using. 90s browsers sucked, famously. 90s Photoshop is barely useable compared to modern Photoshop. Text editors and word processors are so much better (when was the last time you heard of someone losing all of their work? Now we don't even bother with frequent saving and a second floppy for safety). I can remember buying software n the 1990s and it just didn't install or work, at all, despite meeting all of the minimum specs.
Seriously, go use a computer and software from the 1990s or 2000s, you are forgetting. I'm also not convinced on your assertion that software delivery has slowed down. I get weekly updates on most of my programs. Most software in the 1990s was lucky to get yearly updates...
It implies that there will be no need to share libraries (which is said including things like networked SaaS services). You can have your legions of machine developers create all the code you need.
Let's face it, sharing code sucks for a long list of reasons. We accept it because it is a significantly better value proposition than putting human labor into duplicating efforts, but if that effort diminishes to almost nothing, things start to change in a lot of cases. There are still obvious exceptions, of course. You probably couldn't throw your machine developers at building a Stripe clone. It's far more about human relationships than code. But bingo card creator?
It says nothing about creating software nobody wants or needs.
To me an algorithm is just something used to compute a result based on some rules - but apparently it has some different meaning for you that you just take for granted
All of that being said, I do think what you're describing is happening, or at least will happen. I just don't think people placing bets on it happening counts as evidence.