I imagine you're going to have people trying to automate the whole GTM lifecycle, but eventually the developer that thinks they can bootstrap a one man enterprise without actually doing any kind of social interaction will run into a wall.
But you are not limited to only using LLM for coding.
I agree that marketing and sales is as important as product and technology, but they are not necessarily safe.
What are the higher-order effects when anyone can do this, and *aaS becomes a market for Lemons?
In the very long term, software will become a commodity, as you mentioned. Process and workflow may move into JIT delivery for the need at hand, in theory the data layer will be comprehensive and clean and the days of clicking around a bunch of stuff to fulfill process needs will move into a lower latency activity like...talking to your agent.
I saw a quote today by Brian Eno(1995) that said: "So the question becomes not whether you can do it or not, because any drudge can do it if they're prepared to sit in front of the computer for a few days; the question then is: of all the things you can now do, which do you choose to do?" and it resonated with me a lot.
This is true when you had to work hard for those ideas. Now you have LLMs. It means more people can sling a lot more crap at walls with fewer barriers to entry.
- nearly every enterprise IT project is a failure anyway
- "can i do this for free?" savvy people write "thing i don't want to pay for github".
- ??? "stupid smelly nerds!" (https://www.reddit.com/r/github/comments/1at9br4)
okay, what was the actual obstacle? it's really simple: in order to use something FREE, you had to touch GITHUB, which meant GIT. and people hate git.
today, with LLMs:
- "can i do this for free?"
- LLM dutifully does the needful, using projects it finds and code it learned from github, and doing the prosaic tasks of launching them for you, whatever that means.
people are getting way up into their heads about what matters, psychosocial and management and whatever bs. chatgpt is FREE. it will fix your problems for FREE. people will put up with ANYTHING for FREE.
the real innovation is laundering all that inaccessible, pre-existing solution space into a format that doesn't require transiting git and giving it away for free.
don't believe me? all of the most profitable SaaS businesses in technology are the packaging, deployment and customization of pre-existing open source free software, whether it is linux, kvm, postgres, etc. they are factories to turn stuff that is inaccessible because it is in GIT, which SUCKS - that is the hard part for people to wrap their minds around, that GIT sucks - into websites you can pay for. now LLMs do that.
A CTOs job isn't to save money but to spend money effectively. Saving money by increasing risk is not neccesarily a prudent move.
In some sense having customer able to prototype what they want is a good thing. I did it myself as i was at the time on that side, and having a quick-whip-it tool was a good thing to quickly get some feature that was missing in the major software before that major software would add it (if at all). (And if one remembers for example Crystal Reports - while for "reports", it and the likes were in many senses such quick-whip-it tools for a lot of such customization that was doable by the customer.)
So, after initial aftershock - "Ahhhh, we don't need software companies anymore!" - we'll get to the state with software companies still doing their thing just with a lot of AI as specialization is one of the main thing in modern economy and AI becomes most powerful tools of the trade. (and various AI components themselves will be part of software delivery, like say a very fine-tuned model (hosted or on-premise) specific to the customer and software - Clippy on steroids)
(Of course some companies wouldn't survive the transition just like some companies didn't survive the transitions to client/server, cloud, etc. while some new companies will emerge like Anthropic has today or Borland had at the time)
LLM coding is going to create a cambrian explosion of these tools. It’s going to be very interesting to see the remnants of this wave 30 years down the line.
American capitalism hides the depressing fact that rarely does the best succees.
AAI momentum is parallel to just buying lottery tickets and doing so with the belief that you know the real odds, so one can overwhelm with quantity of tickets.
Even if you can build it in a day B2B SaaS will continue to prosper because they sell peace of mind, reliability and compliance. Not features.
Also due to economy of scale it will always be cheaper to buy something from a vendor that sells it to many clients than to DIY it.
You build a Twitter. Profiles have posts, posts can have images, etc. It's very easy to model the database.
But then how do you make money with it? Now you need to build a separate system for advertising? Or do you want to sell subscriptions? Which means you need to build a separate system to handle payments. This is usually the big one, because when you handle money, what happens if there is a bug and you charge someone without delivering anything? How do you prevent fraud? How do you handle disputes?
Someone posted something illegal. What do you do in this situation? Do you call the police? The FBI? What kind of data do you give the authorities? How much data SHOULD you have been logging in the first place in case something like this happens?
One user doesn't like you so he bought a botnet to DDoS your website. How do you handle this? Are they mass posting? Mass creating accounts? Is it possible for them to exhaust all the usernames possible and then nobody can create an account anymore?
Your website is online but if the server blows up you'll lose all the data in the database. You need backups. You need a system to ensure the backups are actually working. But then some guy from the UK said he wants his posts all deleted. What are you going to do now, because his posts are also in the backups, and you don't want to touch those.
Trolls are posting things against the ToS. Who handles these things? Shadowban? So there needs to be a shadowban system? Moderators? So there needs to be a moderator-only section of the website? Should this be integrated with the main website or not?
Then you look at this horrendous mess of 6 paragraphs and you think back about the first paragraph that already did everything you wanted from Twitter. All these other systems, most of the work, and all you actually wanted was the first paragraph.
Use stripe, cloudflare, whatever the legal equivalent of these stuff, S3.
Yes they might take most potential profit, but you'll also not have a huge payroll.
What actually happens in a startup is you encounter these problems one at a time as they arise.
Prototype maybe. Go to market maybe not so. It's giving false hope. You're just taking more shortcuts with prototyping.
They could just download GIMP or find cheaper alternative, that was always an option
Also: In my life the easier it has gotten to create and run software, the more software people have wanted and the more they have been willing to spend on it.
I really don't think it's not going to become "these prompts are specs" and then you have processes of reviewing implementations. It's one thing when you have randos building stuff and they leave etc. Having stored prompts and managed code that uses tools is a different beast.
Although the proponents of this idea argue that companies will create and (!) maintain many tools in-house.
It’s not so much about running a business, since you don’t sell anything and only have internal customers.
people who write this BS - one never don't understand SAAS fundamentals, they only see what's on the screen and forget the complexity that lives on the backend - forget the costs of running such a SAAS
before it was low-code will kill SAAS, then Visual UI builders, now its A.I
just like it was before that crypto will kill Trad-Fi
people who say these things - have tied their identity into it so they whole-heartedly believe the bullshit they say even though reality doesn't match
to anyone curious read the 10k (Annual Report) of any public SAAS - Salesforce | Workday etc - people should admire these companies for the machines / ecosystem they built - and also learn the good & mistakes to avoid i.e the bad
those annual reports tell you how the revenue generation machine works, how much revenue is expected 2+ / 3+ years from now - their weaknesses | headwinds and also tailwinds - how those companies grow and continue to grow etc
I hear all of the cost savings benefit, but I never see the team factoring in their own time (and others time) needed to set up and maintain these systems reliably long term.
Something IC’s at company often struggle to understand is the reason why companies often prefer to buy managed solutions even when “free” alternatives exist (read: the free alternatives are also expensive, just a different type of cost)
No one, you pull an engineer off the production issue to debug the log server, because you need the log server to debug the production servers.
See the problem?
Edit: to be clear I’m no fan of Datadog and I wish self hosting were an option. I want this path for our company, but at least on our team we just don’t have enough (redundant) expertise to deploy and manage these systems. We’d have to hire an extra FTE.
If you mean you are experiencing two totally unrelated issues at the same time, then I don’t think that’s a reasonable thing to really assign much value to as it’s incredibly unlikely.
Half of $30k/mo trivially pays for an engineer you hire to only manage such a cluster for you and just works an hour a week unless a pager goes off if you truly need that level of peace of mind. If you’re hiring for such a position I have a few rock star level folks who would love such a job.
The hypothetical problems people imagine for on-prem infrastructure get really strange to me. I could come up with the same sort of scenarios for cloud based SaaS infrastructure just as easily.
In my experience the systems/tools needed to debug production issues are often only used when they’re needed.
Which now means you need health and uptime monitoring on your log server since without that, it might break randomly and no one notices until you need it.
> The hypothetical problems people imagine for on-prem infrastructure get really strange to me
It really comes down to the people and whether you have the expertise on the team. And whether the team can realistically manage the system long term. It’s typically safer to spend more money for the managed service.
(It’s a safer decision, not necessarily better)
More importantly, with a third party service I'd be very surprised if both went down at the same time and it wasn't a further upstream issue like AWS. If its my own logging service and it went down during a prod outage, I likely didn't properly isolate my logging service in the first place.
Beyond that, and Im aware this is very much application/company dependent, theres plenty of SaaS companies that offer horrendous or no support no matter what you pay. We used to use splunk for monitoring and logging. Paid a ton of money because we were handling financial data and needed tracibility and reliability. We constantly had to put out fires that were caused by their unreliable platform. It was not a good experience.
Ultimately, we jumped ship to Prometheus. We pay a fraction of the price and spent less time on it.
The problem is all these SaaS companies have cut costs so much that all their support has been reduced to useless offshore at best and at worst a chatbot. They do go down and don't work and often times there's simply nothing you can do. The worst offenders will seize upon the moment and force you to upgrade a support plan before they will even talk to you, even if the issue is their own making.
Unless you're a huge customer and already paying them tons of money, expect to receive no support. Your only line of defense if something happens and you're not a whale is that some whale is upset and they actually have their people working on the problem. If you're a small company, startup, or even mid-size, good luck on getting them to care. You'll probably be sent a survey when you don't renew and may eventually be a quotient in their risk calculus at some point in the distant future, but only if you represent a meaningful mass of customers they lost.
How do you calculate the time spent on an internal tool like this, actually? (I’ve never been in management). Realistically your team inevitably will have some downtime, maybe some internal tool maintenance can be fit in there? I mean it obviously isn’t fully “free” but is also shouldn’t be “billed” at their full salary, right?
What? My team wouldn't have any downtime even if we had 10x the amount of people.
If you work at a company where you have times where you don't have work to do, you should polish your resume because it means the company will go under.
I think most software companies need to be doing less. Deleting code, refining, and making their product genuinely useful as opposed to "able to technically contort to client needs".
Using an open source self hosted solution should be the industry standard, encouraged position, by default. Our industry does not gain overall from using DataDog but only from truly open source solutions that utilized AGPL licenses that allows everyone to move forward together + share lessons together + contribute together toward a common goal of better observability.
Why are we acting like it's hard to set up? This isn't the 1990s, it's 2026. Tooling has gotten quite good over the last decade.
Also corporations stupidly spend money all the time, they over spend too. I recently left a company that was paying SalesForce $10mil a year in licenses when only 8 people in the entire 3,000 person company was using it. I doubt that was the only single instance across our industry too. There is a massive amount of waste and graft in enterprise sales.
I honestly doubt it if you replaced grafana for 10,000 DataDog customers they would notice the difference.
Because the current generation of “full stack” engineers are great at spinning up react apps, but struggle with infrastructure and systems management. It’s really not any more complicated than that.
On a typical 8 person engineering team, maybe 1 or 2 people will know how to deploy anything to the cloud if you’re lucky.
The expertise just isn’t there at most companies.
When management realise that the vibe coded projects are not maintainable, SAAS will be as popular as ever
Paper forms have some amazing features that software really can't compete with. And also some significant downsides that software fixes.
However, they dont have a choice. The sentiment of shareholders is that they want their cash (yes it is their cash that managers re-invest on their behalf) to be invested in AI-related projects.
So...... you get what you get, and investors will get what they deserve. But they will still blame the management in the end ;)
They are not stupid, far from it, most are (very) high functioning sociopaths. And out and up there its everybody for themselves first.
But I think it’s plausible that SaaS companies will be easier to start with AI coding, and with lower costs (thanks to AI) they will be able to get into the black with a smaller addressable market. So each one can have a different mix of fewer features, for different segments of customers, at lower prices.
The result would be a loss of pricing power by the incumbent do-everything big guys: no more baked-in 10% annual increases. Which is still a pretty big change in their economics. And therefore valuations.
AI could change that for good.
what if the expensive SAAS offering is just as vibe coded and poor quality as what a junior offers?
If your senior developers can slap together something better than an expensive SAAS offering you want them directing that energy at your core products/services rather than supporting tools.
And the people deciding to buy the expensive SAAS tools are often not the people using them, and typically don't care too much about how crappy the tool may or may not be for doing the job it's advertising as doing.
A typical SaaS customer will use many pieces of software (we mostly call them SaaS now) across its various functions: HR, accounting, CRM, etc. Each one of those will have access to the same pool of senior devs and AI tools, but they will pour more resources into each area and theoretically deliver better software.
The bigger issue here is the economics of the C-suite have not changed here. Assume a 100 CPG company uses 10-20 SaaS apps. Salesforce might be $100k/year or whatever. 1Password is $10k. Asana $10k. etc. They add up, but on the other hand it is not productive to task a $150k employee with rebuilding a $10k tool. And even with AI, it would take a lot of effort to make something that will satisfy a team accustomed to any modern SaaS tool like Salesforce or Atlassian. (Engineers will not even move off Github, and it's literally built on free software.)
That's before I get to sensitive areas. Do you want to use a vibe-coded accounting system? Inventory system? Payroll? You can lose money, employees, and customer perception very rapidly due to some bugs. Who wants to be responsible for all their employee passwords are compromised because they wanted to save $800/mo?
Then, the gains from cutting SaaS are capped. You can only cut your SaaS spend to zero. On the other hand, if you have those engineers you can point them at niche problems in your business niche (which you know better than anyone) and create conditions for your business to grow faster. The returns from this are uncapped.
TL;DR; it's generally not a great idea to build in-house unless your requirements are essentially bespoke.
The gains is generally more seen outside of monetary as these SaaS solutions where holding us back for achieving our goals and improving our services to our customers. As in the end of the day our customers do not care if "insert SaaS" is having issues, it will always be our problem to own.
The second question is a valid one, and I think it will somewhat raise the bar of what successful SAAS vendors will have to offer in coming years
At the end of the day these decisions are all series of trade-offs, and the trick is understanding your requirements and capabilities well enough to make the right trade-offs.
Somehow that has not happened yet in 2026.
25 years here. You can absolutely do this. Most software is orders of magnitude more complex than it needs to be.
The junior programmer you are talking about who wanted to rewrite it in a weekend tends to come back with a working program, not empty handed.
1. That's not a great use of the developer's time, and
2. anything in-house increases our training and support costs
2. Company uses it, maybe even starts to rely on it for important business operations, and for a time the employee supports that app.
3. Bugs creep in, feature request pile up.
4. Employee either leaves the company or moves on to another project.
5. Pain
Doing this today, in production, with full trust, is clearly not wise, but the writing is clearly on the wall that this is going to be the norm more and more over the coming years. The times they are a-changin.
And "it will be the norm" is a clear corollary of, absent any significant and unforeseen roadblock, even with the current highly imperfect agentic sausage-making factories we have today, what capabilities will be in like 6-12 months time.
The key here is that the moving target will _never_ be "what can 1-2 people vibe code without any expectation of being the best at what it does?"
(Also: training people on bespoke tools takes much longer than training on configurations of standard tools. Imagine if you had to learn a new source control system at every job, like in the '80s.)
3. Bugs creep in, feature request pile up.
4. Employee continue in the company and request help (or the managers see the need):
4.1 They hire more, but if all are vibe-coders too
4.1.1 The product gets more complicated (no more complex, that good developers can manage!)
4.1.2 Bugs creep in, feature request pile up.
4.1.3 People start to get desperate, not worries! now:
4.1.3.1 Somebody vibe-code a new alternative that solves the immediate problem
4.1.3.2 Bugs creep in, feature request pile up.
4.1.3.3 Needs to sync with the other tools
4.1.3.3.1 Somebody vibe-code the sync that solves the immediate problem
(the saga continue)
In parallel:
4.2 Eventually is obvious that need external help
THEN:
4.2.1 They ask for consultors for build tool, of course, from a company that has embraced the IA!
4.2.2 They build new shinny tool!
4.2.3 Bugs creep in, feature request pile up.
4.2.4 Needs to sync with the other tools ....
AND:
4.3.1 They ask for consultors, to teach them what to do, of course, from a company that has embraced the IA!
4.3.2 New shinny theory of how do the thing with IA is now being implemented!
4.3.3 It require a rewrite of not only past solutions but, a change of how the company behave!
4.3.3.1 Needs to sync with the other tools .......
4.3.4 And it spark beautiful office/political debates around some philosophical whatever that also trigger changes in the structure, hiring or whatever, alienating the people that has been working there, that after months, has started getting the handle of it!
4.3.5 Employees either leaves the company or moves on to another project.
4.3.6 New employees arrive, with a wild new IA tool and different vibes that vibe-coding!
... the saga continues
5. Is now clear that it need to buy a product form a well stablished software provider
5.1 And all of them are now in the IA craze!
.............
lol
Well, with claude, you can download the code, tell it to implement LDAP authentication, and smile all the way to the bank. And for said fortune 500 company, employing an employee to spend 100% of their time maintaining the app at 10k per month is a 15k savings! And because it _doesn't really take 100% of their time_ it's really only like $500 per month? And to be completely honest, how man times did you get Jira to fast-track your issue?
I get it however, the manager angle. It's still a distraction. But the article being referenced still shows revenue going down.
There's definitely a lot of cope in here, mostly because SaaS is keeping them employed... be ready, the crush is "almosthere".
If the cost to the company is $10K a month, the developer's topline salary is $60K, which is going to be a hard hire to make.
And, again, if they can integrate LDAP with an existing software package at that price point, I want them doing something more valuable than that.
But then keep in mind one who built the replacement will become the owner of an application that business doesn’t want to pay for and that person will be cost center for the company.
That person better get marketing and negotiating skills that Atlassian has on board because that person will be responsible for the app and will not be getting salary increases for working on something that is not core business of the company.
Even if you can make LLM to do the app for you.