When management realise that the vibe coded projects are not maintainable, SAAS will be as popular as ever
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
what if the expensive SAAS offering is just as vibe coded and poor quality as what a junior offers?
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.
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
Somehow that has not happened yet in 2026.
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.
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.
They are not stupid, far from it, most are (very) high functioning sociopaths. And out and up there its everybody for themselves first.
Paper forms have some amazing features that software really can't compete with. And also some significant downsides that software fixes.
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.
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.
Prototype maybe. Go to market maybe not so. It's giving false hope. You're just taking more shortcuts with prototyping.
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.)
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.
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.
They could just download GIMP or find cheaper alternative, that was always an option
What are the higher-order effects when anyone can do this, and *aaS becomes a market for Lemons?
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.
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)
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!
.............
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.
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.
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.
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)
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
lol
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.
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 ;)
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?
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
What actually happens in a startup is you encounter these problems one at a time as they arise.
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.
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.
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".
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.
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)
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.
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.
AI could change that for good.
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.
- 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.
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.
A CTOs job isn't to save money but to spend money effectively. Saving money by increasing risk is not neccesarily a prudent move.
1. That's not a great use of the developer's time, and
2. anything in-house increases our training and support costs
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.
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.
That's not good enough.
Now that the world has successfully laughed off the "our models are so good they're superintelligent" AGI claims, AI companies and investors have moved on to the "our models are so good they're going to do all your workers' jobs" angle.
The insane investment is for AGI/total job replacement, not developer productivity tools. We are going to be sold pie-in-the-sky claims for a long time until the world wisens up to this rhetoric the same way we did with AGI nonsense.
Absolutely. But this begs the question that businesses want to also sign up to maintain whatever product they've built, on top of their core business.
"Service" is the word that people seem to be forgetting in SaaS. If you roll you own, all you have is software.
A boring one from today was about select, datalist or some custome element (which LLM can prototype) or some JS libs. Good breakdown; links to playgrounds, rough mocks so team could kick tires. It raises points the team had and had counterpoint to help drive decisions.
I came in to work Monday morning, showed it off, and inadvertently triggered a firestorm. Later my boss told me not to do that again because it caused havoc with schedules and such.
So I quit and found a better job. Sometimes the new guy can make a better version themselves over the weekend, not because they’re a supergenius, but because they’re not hampered by 47 teams all trying to get their stamp on the project.
(In before “prime example of overconfidence!”: feel free to doubt. It was a CRUD app with a handful of models on a PostgreSQL backend. They were writing a new Python web framework to serve it, complete with their own ORM and forms library and validation library. Not because the existing ones wouldn’t work, mind you, but more out of not realizing that all these problems were already sufficiently solved for their requirements.)
This niche position has had some interesting ramifications for them and for me. They clearly incur a lot of technical debt once their business relies on bespoke software. On the other hand, they own the software and can get an immediate response or new feature or upgrade from me, limited only by my time. And in the end, this ends up saving them time and money. It gives me a permanent and unending flow of work. But if I die, they're pretty screwed.
One reason I don't vibe code things even now, even simple components that could easily be vibe coded, is that I remember and know where everything is, every function or line of code that might be causing issues, because I wrote it myself. I know right away where to look for a query that might be throwing errors after a database upgrade, for instance.
As a manager I assume you would probably not want to go down the road of hiring someone like that, but for companies of a certain size it's an acceptable compromise. However, I wouldn't want to hire someone like that myself unless they were extremely reliable and didn't rely on AI to write any of their code.
You will trade initial development budget for advertising budget, trying to position your product in proximity with people who are known quantities.
Observability is great, dont get me wrong, but past 3 to 6 months of work on the same thing...I can almost beet the observability tools in timetoresolve.
I’d bet that we skip SaaS entirely and go to Anthropic directly. This means the ai has to understand that there are different users with conflicting requirements and that we all need the same exact copy of the burn rate report.
It’s not about some single dude disrupting the saas market. It’s about largish companies who already have internal dev teams, slowly weening their company off these ginormous one size fits all saas products and building local, tailored solutions.
It’s death by a thousand cuts from the erosion of their highest paying customers.
Companies in most cases don’t want to build SaaS because it is expensive to hire engineers to do it, not because they are allergic to owning teams.
If in-housing becomes substantially cheaper than the alternatives then companies will adapt.
But even if the new equilibrium is to hire a contract dev shop to build something custom to keep avoiding responsibility, this would have the same impact on SaaS.
So I’m pretty skeptical of this first-principles prediction expressing right level of uncertainty.
But I don't think Claude Code is going to prevent an org that thinks they can prompt their way to a replacement for all their SaaS from having internal political bickering that makes them end up with a extra-shitty mega-compromise to try to make all the internal stakeholders happy.
If you've got no vision and no taste, you need to find a vendor who will protect you from screwing up your internal processes and tools.
Internal tools teams have rarely cared much about UX or the day-to-day experience of their poor users. The quick-and-dirty internal-prompt-based one is likely to similarly be unimaginative and unintuitive.
That might turn out to be less than reliable over time, as bots are already screwing up systems with fake information and it's probably going to get worse.
If you can spend $10K/year to keep your in house one alive but $5K/year on the new SaaS option, you stop building your own again.
Whose job had been maintaining a single internal system but had never had the bandwidth to expand their focus.
Companies like that are the ones spending millions a year for large one size fits all SaaS products.
In broad strokes there's two ways. You can count it as an operational expense, or you can count it as capital (this takes more work to do but can have some advantages). If you count it as operations, it's just a big red pit you're throwing money into that you hope is offsetting a larger operational cost somewhere (but this can be hard to quantify). If you count it as capital, you're basically storing all of those hours as an "asset" which then loses value over time (it's kind of like the charge in a battery). The problem is you have to be able to show that this internal tool would, in the case of an acquisition or liquidation, be valued by the new owner at the value you're setting it at.
The problem there being that people are even more hesitant to trust somebody else's internal tool than they are to trust their own internal tool, so I've seen multiple managers think "I sunk a million dollars into this so it must be worth something" but in fact they were just running a jobs program for their team.
Did you talk to anyone about your plans before you brought in the demo or let them know they were solved problems? Often these sorts of reactions come down to your boss not wanting their team to lose their jobs because of the perception that it can all be handled by one person who's happy to work weekends.
Again, and I can’t emphasize this enough, for a Django CRUD app. It was a 4 person-week project turned into a major ordeal. No one should have lost their job; they should have been put to work doing the thousand other more productive things they could’ve been doing instead.
I'm terrible at sales. My clients have only come to me by rererral from other clients. More than half the time, I'll tell prospective clients that there are already SaaS solutions that would be better for them than building something bespoke, and help them find solutions, because I don't want to do work that's already been done.
AI is like sugar. It tastes nice, gives you energy quickly - what's not to like? The gratification is immediate, and if "today is all that matters" it's brilliant.
The problem with sugar (and AI) is medium term. So sure, that junior dev whipped up the whole framework in ClaudeCode, and it's humming nicely. Junior dev gets credit, and after a couple years moves on somewhere else.
Then something changes. Windows. TLS. Code Signing, whatever. We need to update the program to the change. Just a small tweak. Junior Dev has gone (or is otherwise occupied) so we'll get new-Junior-dev to do it. Is he expected to do the change at the code level? Or at the prompt level? Will ClaudeCode in 2029 be able to maintain ClaudeCode Code from 2026? Or will it want to rewrite everything? Will new-junior-dev have the skillset to prompt as well as first-junior-dev? Was the code good enough that a dev could just "take it over"? Or was it "it works, let's use it" standard?
AI makes everyone look good in the short term. But it worries me for what happens in 5 years, 10 years, and so on. Sugar is great, but you can't live (long term) on sugar. Sometimes you need a proper meal plan.
3 engineers arrived - fashionably late. We explained them the situation and all we wanted from them was some GCP offering that would cure our woes and one that would cut our bills. The senior consultant - and presumably the only tech guy (rest seemed to be salesy) wasted our time like a used car salesman - he didn't even understand Google's own product portfolio and recommended us to use something like Spanner - which was totally not the solution to the problem, not to mention, expensive.
My boss and I left the meeting pissed off and he told me - "Neya, you probably know more about the product portfolio than these guys. Let's leave". That weekend, I went with my tried and trusted favorite Db - PostgreSQL - CloudSQL with a custom Elixir middleware based an old CMS I wrote a decade ago. After some trial and error, the solution worked flawlessly (and still does till date on auto-pilot). My client still has the lowest cost in the region - 1/3rd the cost of their competitors...7 years later. Back then, there was no vibe-coding, no AI, no auto-completion. Just pure thinking and experimentation.
All this just to say I agree that the new guy sometimes can make the best solutions to a problem and not always screw up. I always listen to new hires these days (now I'm a fractional / CTO) because you never know who could pull off that 1/3rd cost cutting framework move.
But yes, this brings us back to the point that simply building the tool is only a small part of the process...and it has often been one of the most expensive parts of the process.