Comment by bandrami
22 days ago
It's a tale as old as time that developers, particularly junior developers, are convinced they could "slap together something in one weekend" that would replace expensive SAAS software and "just do the parts of it we actually use". Unfortunately, the same arguments against those devs regular-coding a bespoke replacement apply to them vibe-coding a bespoke replacement: management simply doesn't want to be responsible for it. I didn't understand it before I was in management either, but now that I'm in management I 100% get it.
OTOH, I was hired by an enterprise that was many months into a giant backend rewrite. After wrapping my head around the many plans, I realized they were rewriting Django, badly. One weekend I prototyped the whole thing… in Django. It worked. It met the specs. It was a CRUD app with a REST API.
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.)
In the beginning of my career, I've been once told by my senior management that I should never again:
1. Optimize things so that they work 10 000 times faster because it makes us look incompetent (must be done slowly to show gradual progress).
2. Brag about such optimization (to stakeholders) without first synchronizing this with them (so they can brag proportionally to their pay rate :) ).
This is the prime example of Law 1 of Robert Greene's "The 48 Laws of Power": "Never Outshine the Master."
The core principle is to always make those above you - your bosses, mentors, or superiors feel comfortably superior.
If you display your talents too aggressively, you risk triggering their deep-seated insecurities, which can lead them to sabotage your career or remove you from your position.
Galileo Galilei handled this really well. When he discovered the moons of Jupiter he strategically named them after the ruling Medici family.
By making the discovery about their greatness rather than his own intellect, he secured their lifelong patronage.
However, if your superior is a "fading star" or is clearly about to fall, you do not need to be merciful. In these cases, it may be strategic to outshine them to hasten their downfall and position yourself as the natural successor.
12 replies →
This was the moment I’ve stopped putting any effort in my work.
Sounds like when I was asked to give minimum hardware requirements for something doing backend processing (receive text submitted as print jobs, massage, send to printers).
The requirements as they went out were much higher than they needed to be, because I decided telling them that we weren't stressing anything on the obsolete NT desktop repurposed as the test system might not please everyone.
IMHO I think the best any engineer can do in an org is to ask "what is the highest value problem to solve for the business" and "can I solve it".
"I made this x times better" is not relevant to _most peoples in any org_.
That's the dark secret. Nobody cares how good of an engineer you are _unless there is a fire to put out_. After which you get pat on the back and back to usual business.
There are situations where years of impeccable, high value diligent work is rewarded.
But what is more common is that the rewards go to those who are in politically expedient position to get the rewards. Favourites, culturally aligned folk, etc. And sometimes it's not even about you or your boss, but the politics in the organization at large. "You are not allowed to promote anyone due to budget" is a very common thing.
So I guess what I mean to say is if as an egineer you want to retain your sanity, when at work focus on maximizing business value. If you know a kick-ass solution that is 10000x better than industry standard go with it but know this - nobody will care! Nobody believes _someone in their org_ could have beaten _industry standard_ unless the org is very unique. What you get is small increase in your reputation - and sadly nobody recognizes how hard that was. Maybe you will meet some other engineer at some point who has tackled that same issue - and then you can bond over the solution.
A large part of software ecosystems is about business, politics, and the large scale impact of technology.
Saying this as an IC whose previous tasks at previous employer could have employed _teams_ but since we were allowed to deal with them smartly it was just me.
So if you know a 10000x solution to a problem many people have - that's a good opportunity to consider can it be productized!
3 replies →
Just smear the heck out of them to stakeholders, after implementing something big and climb over these incompetent shmucks and watch their fall
8 replies →
Unless you were working at a startup full of very naive people, I gotta say this sounds made up.
3 replies →
I can relate to this so much. When I was a newly joined Google consultant at a partner firm, we went to their office - some 13 different types of cuisines, different types of game rooms, lounges and what not. A luxury star hotel experience. We were waiting for our meeting on behalf of this one particularly large media client who was bleeding money on Wordpress.
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.
Nice work!
Sometimes those complex solutions are the right tool for the job. And other times, you just need to glue some stuff together, call it good, and start making money.
Experience helps a good engineer know when each approach is appropriate.
1 reply →
Thanks for sharing! Every time I see a post about Elixir and how it Just Works™, I get an urge to learn and build something with it.
2 replies →
It’s funny you complain about the sales pitch the guy gave you, but the comment itself sounds like a sales pitch :)
4 replies →
> Later my boss told me not to do that again because it caused havoc with schedules and such.
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.
I wasn’t politically savvy enough to do that. Honestly, I don’t want to be. The reality was that the project really could have been done in a month by a couple of people. It got turned into an enterprise project with multiple unaligned teams with Gantt charts and milestones and everything.
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.
23 replies →
Omg! Who the hell cares if the "boss" got a heads up. When I'm in engineering or you're in engineering with me, we party the same way: better is better.
The bosses - hell management's job leading into organizational culture - is to stop politics from derailing good engineering and customer satisfaction.
It's not too tough for me. Now that you know where I stand the other side better get it's act together.
Drowning in politics helps nobody including the boss. It's a net loser.
Now I'm practical and empathetic: a surprise can bring heat. But then you breath and get a grip. Cool. But thereafter the right things better get done. Politics for a day - np - politics sapping know how making cynical SE'S think twice? Never.
1 reply →
replace your boss
1 reply →
Oh I have seen this story and was the one who caused this story when I was younger.
In a lot of cases the "new guy" thinks its an easy software and does it on his free time and thinks he did a great job.
In reality the specs are never 100% done correctly. The "new guy" misses some edge cases everybody but him knew because its just company knowledge. A lot of info in the specs was missing since they are not complete and so on.
This over the weekend never works in the long run. The ORM worked for all the happy path and written down cases but then you have cases were the ORM just is not good enough or fast. So you start to add strange code to work around the ORM. The same for the web framework or the validation lib.
To me the author of this comment sounds like the typical "Freelancer" coming in into a company knowing everything better then all the people and then leaving after a few months and now everybody else has to deal with his code.
It swings both ways though. I've seen plenty of older engineers dismiss the "new guys" effort and claim that everything had to be custom written, because there's no way a common framework like Django could cover their use case. The same type of engineer has never once worked with a common framework though, so they don't know what's included nowadays.
Turns out it's a lot easier to build on top of a common framework than do everything from scratch.
2 replies →
I think it's safe to say that ORM in Django is, in fact, better in all possible ways than an ORM someone at some company just wrote. Including speed and handling edge cases.
We only know what OP wrote and he doesn't sell himself as a genius but as someone who was competing with really, really bad ideas.
> 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 99.9% of cases what seems to be "the better" version is better only for the "new guy" or rather his ego.
Those 47 teams hampering doesn't necessarily mean a bad thing, and more often than not actually well justified "stamps".
You only understand those things when you turn from the "supergenius" into an owner who have to take care not only of numbers on screen, but also security, interfacing, management and so on.
Or you don't turn into.
That is often the case, but far from all the time. Other times something is made so needlessly complicated by office politics that it may never get shipped.
4 replies →
Not saying you're wrong in all cases, but there are enough examples of hugely expensive megaprojects which totslly tanked, which would have definitely been much more successful with OPs approach if executed correctly. Not saying they would be done and done within a weekend, that's silly. But the alternative, poorly defined integration interfaces, multiple contractors, multiple stakeholders with conflicting requirements and zero (real) regard for the user is unfortunately fairly common, both in public (city/regional/government) and private bureaucracies.
The examples are legion, and they always seem to have NIH and baroque requirements, and be rather over- than underspecified. I would go so far as to say that these projects are almost never successful (and definitely never on time and budget).
Take this idea and bring your own validation library and forms and UI components to the next job, and you've described what I do. And then you have real lock-in.
Ah, so you’re the one who made that same company’s marketing website!
2 replies →
Yeah, that definitely happens.
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.
Isn't this agreeing with the parent? If Django were the B2B SaaS product, you didn't vibe-code Django, you just used Django. You aren't responsible for maintaining Django itself.
Django wasn’t the product here, though. I used it as part of the toolkit to “slap something together in one weekend”, and that something was the (actual real life) B2B SaaS product, or at least the user facing interface to it.
Rule #1 of power: never outshine the master
> feel free to doubt.
I don't doubt you at all.
I once worked on a project that was a new sign-up process for a large retailer (~90k employees at the time, four figures worth of outlets, quite a few billions in turnover).
There were about 60 people across, I can't even remember, maybe 10 teams that I knew about. One of the managers there assured me that the true participant figure was closer to 160. I was agog.
This project took months, and it had been going for months before I joined. And, as you can imagine, with that many people involved over that sort of timescale, there was turnover: people, sometimes key people, would leave and be replaced - sometimes by others who'd already worked on the project, but sometimes by new people - with the expected disruption that causes.
It was two web pages, plus some back end plumbing across multiple systems.
But, in the grand scheme of things, nothing that complex. I reckon it was a handful of thousands lines of code total across the full stack. I was mostly on the database side and, IIRC, I wrote a few hundred lines of SQL in a couple of stored procedures (wouldn't have been my preferred solution building from scracth but, you know, we weren't, and we had to integrate with a legacy systems that had to keep working as expected).
Overall it took 8 or 9 months from kick off to shipping and I was involved for perhaps 3 months of that towards the end. I was on the call with dozens of other people whilst me and one of the other guys hooked the final pieces together and tested it end to end for the first time... and it worked. There was actual cheering.
Large enterprises are genuinely ridiculous.
It feels like I have worked with you (though obviously not). Had same experiences to the T.
Maybe it's just something that happens to many in web development world, not-invented-here and all...
I had a similar experience where someone that had prior experience with django while we were using sqlalchemy started to design a django-like ORM on top of sqlalchemy. Of course it took him some time to get working, was a hell to understand and extend and most importantly lacked support for basic features.
Fortunately it was limited to a small isolated service but I can imagine the damage on the long term if you continue that route on what becomes a huge monolith after a few years.
I was complaining about SQLAlchemy's insane quirks to a group from my alma mater and one of the grad students said, "Well, the solution to your problem is clear: Write your own ORM." and I had to explain that this startup does not want to get into the ORM-writing business.
I freaking love SQLAlchemy. Those quirks once let me build a sane API on top of a legacy database (ported from Visual FoxPro hourly using a program I also wrote for the task). Some of the fields were values in an XML doc shoved into a DB column because the original programmer thought that was a good idea at the time. I wrote indexes and virtual columns that let other devs query those fields just like everything else.
It has its edge cases, but Alchemy is the greatest thing in the world when you need its exact features.
But yes, I’ve used that line plenty of times: “we’re not in the X-writing business”. I mean, sometimes you can’t help it, but those should be exceedingly rare cases.
I resonate strongly with this story. I’ve seen three people teams get in one month where SAP could not in year, and also let and witnessed incredible number of total fakers in SaaS enterprises.
Big corpo may be too big to fail, not so sure about their whole cohort of partners and fakers.
Also, some people want to work on what's already familiar to them. If building a framework from scratch is what appeals to them, they'll do that even if a framework already exists. Busywork to look productive.
We are certainly closer now to being able to prototype and go to market faster with a product. In one weekend is a little much but I think its hard to deny that building will continue to expedite. What most developers don't think about is that the marketing, sales, customer service are all non-trivial parts of the business/product and all require legwork that is more than just sitting at an IDE. The nail in the coffin is that the data is a large part of company moats, and new products need time in the market to get that. Migration is also a long process and risky...so to get customers, a newcomer needs to provide way more value than what the incumbent gives.
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.
> We are certainly closer now to being able to prototype and go to market faster with a product
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.
The "service" part can still come from internal sources. Plenty of companies have internal support for internal tooling. With a good foundation of infrastructure and a lean team that knows how to build, not just vibe code, there is most definitely some ROI there.
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.
In any usable product making a product is like 20% or less. Enter compliance, security, payments and a million other things.
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.
Yep. It's a funny thing.
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.
7 replies →
Yep. Wait until they realize one of their vibe coded apps validates everything client side and their entire DB is open to the world.
4 replies →
> We are certainly closer now to being able to prototype and go to market faster with a product.
What are the higher-order effects when anyone can do this, and *aaS becomes a market for Lemons?
I think that just because anyone can do it, doesn't mean they will. Lots of people have really great ideas but very few actually commit to execution. Ultimately ROI will go down, deincentivizing the commercialization of that thing someone wanted to bang out in a weekend.
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.
7 replies →
Exactly. Once the market tastes like lemonade, everyone will be afraid of trying new apps in the way that they are afraid to accept phone calls from unknown numbers now.
You will trade initial development budget for advertising budget, trying to position your product in proximity with people who are known quantities.
Tbh I think you’re fundamentally misunderstanding the issue (or I am).
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.
2 replies →
in the 90-ies anyone could easily prototype with tools like Access (and all the other "4GL" tools which were similarly all the rage back then). That still didn't preclude companies from buying their major software from software vendors instead of doing it themselves.
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)
3 replies →
The history of software has been that once it becomes cheap enough for teams to flood the market with “existing product” + x feature for y users. The market consolidates around a leader who does all features for all customers.
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 a market for lemons. We can share info about the lemons and all choose to use the good ones. There's no information asymmetry.
2 replies →
If you can gin these things up in a weekend then why would you bother with a monthly subscription model for software? The only valuable part is the specification and possibly the hardware to run it. If I were a CTO trying to save money I might pay for the labor to develop good specs, but I would prioritize getting out from under software companies with a rent seeking models and 80 to 90% margins
5 replies →
It means the same: random lottery of mass, with everuone else failing.
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 sure hope I never have to hunt down any GTM options myself soon and I can tell the AI to do what it should be doing. However AI adoption may be getting slowed down by profit motives because what Google should have already been doing is letting me git clone the entirety of GTM with all its configs to a local folder so I can treat it like code because it is code. The difficulty with AI adoption will be to make all products be like this so they can interact on a code level instead of me having to press buttons in different UIs to make thing shappen. E.g cloudflare should be letting me git clone its entire config, everything I did in the dashboard, to my folder too.
> 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.
> We are certainly closer now to being able to prototype and go to market faster with a product.
Prototype maybe. Go to market maybe not so. It's giving false hope. You're just taking more shortcuts with prototyping.
This vibe-coding-will-replace-SaaS insanity is the new crypto-will-replace-fiat-money insanity.
It's shocking to me how prevalent this "who needs Salesforce when everyone can just vibe code their own CRM from scratch in a day" narrative has become in the business press. Like, what???
That's not like "Who need Photoshop everyone can just vibe code their own photoshop"
They could just download GIMP or find cheaper alternative, that was always an option
5 replies →
I vibe coded Stripe and Okta in a weekend. Time to deploy to prod and save some money!
That's what happens when business press is all written by LLMs. Maybe the models think too highly of themselves...
It gets eyeballs.
I don't think vibe-coding will replace anything. However, what if AI tools can make skilled developers more productive, particularly at simple tasks in unfamiliar environments? You could see that reducing the engineering costs of simple utility applications. There are tons of pitfalls that many here have pointed to but also maybe opportunities to do things that wouldn't have been cost effective.
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 don't think vibe-coding will replace anything. However, what if AI tools can make skilled developers more productive, particularly at simple tasks in unfamiliar environments?
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.
People really seem to believe that code is the only thing you need to make a SaaS company. It's like thinking a line cook is all you need to open a restaurant. There are so, so many other components to running a business.
I agree!
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.
SaaS is mostly sales.
1 reply →
There is also an aspect of thinking no one will go to restaurants when anyone can make the same food at home.
I don't think it will replace SaaS but I do think it can replace the need for a lot of the consultant work that goes around configuring and integrating the SaaS. It will be much easier to have a spec that defines how things need to be configured and the machines can implement it (using the SaaS as tools). Frankly this is the most annoying part. It's not that the B2B stuff can't do whatever, it's that it never gets implemented in ways that aren't a pain in the ass because it's all handled by people who aren't actually using them.
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.
In my experience this isn’t the case. SaaS systems, at the least the ones that are embracing this sea change seem to recognize that connectivity is key. They are opening APIs and partnering like we’ve never seen. They lack the domain expertise and resources to plumb the last mile. Companies can finally customize and integrate there core SORs at a reasonable price point and if you hire the right people decent technology. It’s a golden era, I do wonder if you’re correct medium/long term but the lack of skill sets to build, deploy, and maintain these solutions is very real. Many can vibe code a great looking app, very few can support it day two even for just a few hundred users.
No serious programmer "vibe" codes. I admit creating SaaS may not be feasible with current infrastructure but you can't ignore the insane jump in productivity that these tools can offer with the right scaffolding.
This website is 70-80% vibe coding frauds pretending to be experts.
There is still a narrative here. Lots of SaaS recurring revenue is built on value-add features that can be easily replaced.
That's a great point about the management overhead of bespoke solutions. Often the goal isn't necessarily to replace the software, but to get a handle on the exploding costs of the 'expensive SAAS software' you mentioned. If you're looking for a way to manage and optimize those subscriptions without the 'weekend project' risk, you might find SaaS-Saver helpful. It's designed to help teams identify waste and optimize their spend automatically.
What I struggle with is developers wanting to leave platforms like Datadog for open source equivalents that need to be self-hosted.
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)
My log bill for Google cloud log would be like 30k. For splunk I like 80k. I self host for 1.5k per month. Spend maybe an hour a month? Easiest money I ever made.
When you’re in the middle of a production down event and your whole team is diagnosing the issue, and your log server is unresponsive, who do you contact for support?
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.
16 replies →
This is the exception to the rule
Do they actually not understand that? They might just be fine with a system that makes them more useful.
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?
> How do you calculate the time spent on an internal tool like this, actually?
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.
> Realistically your team inevitably will have some downtime
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.
3 replies →
If there's ever any use case to leave an expensive SaaS for self hosted, you can find it at datadog
>the free alternatives are also expensive, just a different type of cost
Not if you hire reasonably competent people. These days for vast majority of FOSS services all you need is an ability to spin up a VPS and run a number of simple Docker/Podman Compose commands, it can't be that hard.
Ok so they cost you reasonably competent people. Those are expensive!
2 replies →
I'm sorry but the amount of companies that need something like DataDog is quite small compared to their 30,000+ customer count. Maybe 5,000 companies on Earth truly need something like DataDog, 80% of their customers would be perfectly fine with a self hosted instance of grafana.
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.
> Why are we acting like it's hard to set up?
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.
5 replies →
Because most of them arent trained to think economically... how many people on the planet do you think are aware of the notion of opportunity cost?
& the counter-argument is those SAAS apps being killed by A.I are growing revenue 20%+ YOY
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
Here are the most recent 10-Ks for Salesforce and Workday.
https://www.sec.gov/ix?doc=/Archives/edgar/data/0001108524/0...
https://www.sec.gov/ix?doc=/Archives/edgar/data/0001327811/0...
So you think this downturn will be short lived?
When management realise that the vibe coded projects are not maintainable, SAAS will be as popular as ever
It seems that current advantages would compound with AI. I.e., if I am making a SaaS for Popsicle stick makers today, why I am disadvantaged with AI vs a new competitor in the space? I guess the hypothesis is the Popsicle stick maker will vibe code all of the software that they need instead. For that, we need significantly better AI than we have today - perhaps something like a 1000X improvement. Basically, this is a world in which non-technical grandparents can vibe code anything that they want. This means, it understands what you want without you being able to articulate it well in the first place.
That's not a 1000X improvement in current AI. That's more like a 2x ~ 5x improvement in current AI, which is measured in months.
7 replies →
I don't do tea leaves so I wouldn't commit to that, particularly because I think SAAS was oversold in general even before LLMs came out. But I think the idea that the industry as a whole will shrivel away just isn't feasible, even if there is a correction.
The B2B startup motto of "where someone is using Excel to do something other than accounting, there's a startup waiting to happen" has been shockingly resilient over the decades, and I suspect will continue to be.
2 replies →
In many cases, it's not a downturn, just a return to reasonable valuations. Other sectors should follow
All of the hype surrounding AI will subside when a SaaS company eventually deploys a moltbot version of their software and the company is driven out of existence due to the chaos that ensues.
So… next week then?
1 reply →
I've seen some bad some SaaS that management insists is an integration they need and no one else provides. I can easily see some vibe coded projects replace them.
They will magically realize this when their huge bonuses will be tied to something longer lasting than last quarter/year performance on some very narrow metric (which has nothing to do with sane stuff like adding long term value to some part of the company).
They are not stupid, far from it, most are (very) high functioning sociopaths. And out and up there its everybody for themselves first.
I dont even blame management. I believe most of them are well-aware that much of what is going on right now is pure hype.
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 ;)
My career occupies a weird middle ground where, for 20 years or so, I've catered to smaller businesses that need bespoke solutions (because the SaaS available doesn't conform well to their business logic), but don't have the scale or desire to build and maintain software in-house. Sometimes these are slapped together in a weekend, if that's all that's needed. But in most cases they still become ongoing improvement and maintenance projects for me.
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.
People sometimes fail to appreciate the value of KNOWING the system inside and out when it comes to diagnosis and troubleshooting.
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.
This sounds great if you get on well with your clients. You must be an effective networker and at sales. How do you bill, and how do you price your services?
I bill quarter-hourly at $300/hr for actual time writing or evaluating code. Phone conversations are free, and I take time to evaluate and explain what I'm doing before clocking in. The downside to this is that I make myself available 24/7 should any issues arise. I also don't necessarily charge for hunting down network issues or bugs (because I also host some software for clients). It works out to a good income for 80 hours a month or so.
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.
SaaS companies are effectively both "software maintainers" and "price gouging middlemen" at the same time. The difference between the bid and the ask for SaaS is part of a simple math problem for whether the company should try to create their own version of the software they need. It may be the right decision, it may be the wrong decision, but it will be the right decision for a non-trivial number of firms. And that means SaaS businesses will both lose customers and have downward pressure on their margins. That means valuations of B2B SaaS firms go down.
In my career I've deployed close to 100 different saas products at enterprise level and can tell you that most of the current crop are slapped-together half-finished dross with a huge sales and marketing team.
In the time it takes to deploy semi-bespoke saas, or while waiting for the current licence term to expire it would be very easy to develop a more suitable and much cheaper product in-house, this was true before AI tools and doubly so now.
A huuuuuge part of why companies, especially public companies, especially those in regulated industries like healthcare and finance are willing to pay eye-watering sums of money for a SaaS app that you could get an MVP up in a few weeks time from a competent team with no AI is that they need a phone number to call when something shits the bed at 2 AM on a Wednesday. They need support SLAs without the payroll and headache associated with it. They need someone to sue if things truly go tits up.
Moving SaaS apps in house is a great way for a VP to get a fat bonus or a director to get a promotion but I have to imagine it keeps the CIO/CTO up at night unless they're fully asleep at the switch.
Yep! We sometimes have a choice between the gold-standard and commonly updated open source solution to X and a two-bit hacked together proprietary solution that has 24/7 support at high cost...and we choose the one with support, because that's what our audits basically require. Because then we can say "yes, it's still within the support contract, we have an escalation point".
The problem is right now management is not only insisting on their team vibe-coding bespoke replacements, they’re avoiding paying for other SaaS because they can vibe-code their own replacements, often themselves, and they’ve lost sight of that they probably don’t want to be responsible for it.
This is an incredibly broad statement that just isn’t true in a million cases. Last co we migrated all of our observability from Datadog to Grafana/AMP because it’s much much cheaper. The vendor can charge some premium over the cost to build/maintain but not infinity. SaaS is going to have to get dramatically cheaper to compete with the lower cost of building your own.
Besides rampant failures in communication and skills allocation, wild U turns of requirements were (sometimes, not even real business requirements) were holding back corporate environments doing a decent job.
With AI, I can only see the rate of such changes sky rocketing due to expectations wildly misaligned with reality. Hence we are unlikely to see any meaningful improvements.
what if this time it's senior developers and they actually can slap something together better then the expensive SAAS offerings?
what if the expensive SAAS offering is just as vibe coded and poor quality as what a junior offers?
You're not considering opportunity costs and buyers vs. users.
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.
And it's never just the slapping together. it's the ktlo: a perpetual tax on your eng team for every thing they own.
1 reply →
Clubbing all saas products together just means you can’t really have a productive discussion. Saas products are on a spectrum of quality, from amazing (stripe, datadog) to terrible (fivetran, github). Its upto you as a user to make a call as to which will serve you best, what you should focus your limited resources on etc.
> what if this time it's senior developers and they actually can slap something together better then the expensive SAAS offerings
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.
As my manager said to a young me when I offered to replace our CMS, and promised I could do a good job at it, "you could probably assemble our office furniture too, but I don't want to pay you to do that either"
1 reply →
We have replaced many SaaS with inhouse solutions, but most of these where lacking in quality and where part of our existing core business model which we where not "owning" prior. We can flip the argument where we have lost customers and revenue due to SaaS not delivering
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.
To the first question, if your senior devs can do that there's almost certainly something more directly valuable to your business they could be doing than solving a problem your vendor has already solved
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
depends how much the vendor chargers.
Nice what ifs, but not valid so far. I get the motivation to think/hope so, but thats not the proper business world right now where big money are. Maybe next year it could start becoming true but then market will be a bit different too
You're ignoring the biggest part of SaaS as far as management is concerned.
There's a large, stable entity that management can sue if something goes very wrong.
There are of course exceptions to every rule, and I'm sure some companies have been successful in building their own in-house tooling.
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.
It that works, nobody would be using Jira anymore, because people would just use a competitor that's cheaper or vibe code their internal Jira tool.
Somehow that has not happened yet in 2026.
This is because what management wants and what builders want are not aligned, not because the quality of JIRA is so amazing that no other alternative could ever be created. JIRA is fine but many people I know that use have some qualms with it because the bloat is pretty crazy.
3 replies →
The market seems convinced it will happen, considering its stock price is in the gutter
1 reply →
I think there’s also the classic “I can build zoom in a day” - they get video working between two machines. But it’s the last 80% of the app that takes 99% of the time. Nerds don’t see the whole product, just the happy path of a wee technical challenge.
I totally agree about the management reluctance to just own everything in house.
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.
The companies that already have a strong in-house team will greatly benefit from AI. Many of those who don't are in that situation because managers have PTSD from so many failed projects. Half of all projects fail. That's a lot of emotional trauma.
This was all possible pre-AI. The reasons that some Saas companies win have nothing to do with how quickly or cheaply code can be written for the Saas.
This may be true pre-LLMs, but I think you need to account for the baseline build-vs-buy tradeoff shifting.
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.
You’re forgetting the companies that already had developers.
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.
The same cost savings could be captured by SaaS. Potentially not by incumbents, but by up and comers.
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.
Possibly, but I don’t think it’s certain. For a SaaS to capture, you’d need a forward deployed engineer model. And then I would have ten different FDEs to liaise with, none of whom know my domain.
Vs if I contract a shop, then I have a dedicated team ramped up on my domain who then can vet infra providers and choose the best tech. So potentially still some SaaS, but probably shifting more to PaaS.
Similar to how you don’t hire your Salesforce or SAP contractors from these companies, I would predict this model spreads to other platforms too, and may make OSS viable in more places.
2 replies →
I can't count the times I've told clients and prospects to _not_ hire us to build something they wanted. Because they could just use off the shelf solutions that were cheaper financially, at least in the short to mid term, and much, much cheaper in terms of opportunity costs. I struggle to put even billed hours into something that doesn't make sense to me.
Of course some overdo it. I've seen companies with more random SaaS tools than staff, connected with shaky Zapier workflows, manual processes, or not at all. No backups, no sense of risks, just YOLOing. That's OK in some cases, in others really not.
I suppose it does need some engineering thinking to find the right things and employ them in a good way. Unfortunately even developers commonly lack that.
I'm a manager too, but I'm also the new guy pushing the solution to a human problem: work management. SMAR, ASAN, MNDY, etc. Not only do people not want to be responsible for it (and in some cases simply be "not responsible"), not only is the internal solution "too time consuming", the only answer thus lands on hiring external consultants to implement and maintain massively-overkill-$olution$ in $aa$ like CRM, NOW, etc. which as you know, do not solve the same problems as the aforementioned SaaS.
"Now that I'm in management, I 100% get it." 100% and win or lose I am still going to fight it...
And since you became management, you have refered to software only by the stock symbols of the owning companies?
There's that and then there are companies spending 100k on a software suite just to use that 2 features. So now one of their junior dev solves it and becomes a hero. The truth it always somewhere in the middle.
But this time management has to justify its AI spend.
We've been through cycles of outsourcing and in-housing skill before. This seems similar but for tools and services. Maybe we'll see internal teams taking the reigns back to replace bad-fit SaaS products.
There's still a lot of risk associated with in-housing though (perhaps more than before). That means the real opportunity is for new, leaner B2B SaaS businesses to step in, especially if there's a displacement effect from seeing internally built prototypes of expensive subscription software.
The difference between a vibe-coded prototype product, even a good one, and an enterprise SaaS platform is the difference between a Lightning bug and a Lightning Bolt.
I think the pressure on SaaS margins won't be from customers vibing their way to Figma or DataDog but because gen AI will bring a lot more credible competition in many segments. DD and Figma are probably awful examples because those companies are constantly pushing the envelope, but there are a lot of rent seeking SaaS providers that are going to be in for a rude awaking.
To be fair, re-creating the SaaS solution that simply replicates the features they see can often be done fairly simply. However, there are generally a whole lot of things under the surface. Then there is the whole hosting and maintaining the system, which is its own problem.
Also, management doesn’t have time to fully understand it, which means they need at least one employee who does. And that employee now has leverage.
> "just do the parts of it we actually use".
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've seen this happen with both juniors and seniors. They do come back with a working solution /for the happy path/. Because the happy path is easy. It turns out that most of the complexity sits in the unhappy paths.
I still don’t agree. The trick to good design is getting more things on the happy path. Most of the software I use is small and constructed in this manner.
4 replies →
I agree. Just because you can buy some piece of software doesn't mean you should -- there is a lot of software that exists just to sell more consulting hours and will never fit the business. It's actually not hard at all to code and maintain much simpler alternatives.
Actually having to support multiple businesses with commercial software is hard. I've written a ton of custom software that far surpasses the capabilities of commercial offerings but if were to turn that into it's own commercial offering it would be large undertaking.
Yes, I didn't really doubt the developer could do it, the problems are:
1. That's not a great use of the developer's time, and
2. anything in-house increases our training and support costs
1. The whole point of developer time is to save user time; if a developer can do that then it's worth it.
2. If the in-house software doesn't decrease training time or support costs then there is something wrong there.
5 replies →
And both are completely different arguments then your original post.
2 replies →
If the management is the one actually paying for the software from their own pocket (founder), the tables turn. There are millions of SME owners who are forced to pay for B2B software just out of necessity and not having resources to build it in-house.
AI could change that for good.
I work at a smallish public tech company and while this may be true at some companies, it's not true at all of them. We have almost no SaaS vendors. If we do have to buy software, we're almost only interested in On-Prem.
It almost always devolves into some all encompassing ERP that is meant to solve the needs of all parts of the business and save millions in licensing costs, and we all know how well that plan goes.
Software without support is useless. In the business world, what's being bought isn't code—it's a solution to a business problem, with a throat to choke if things go wrong.
I guess one difference is now you can ask an LLM, trained on an open core product, to generate a license-free version of it.
management simply doesn't want to be responsible for it
That sounds dysfunctional. The purpose of management is to manage risk, not to avoid it. A proper manager would be able to quantify both the risks and the costs, present those figures in an easy overview, and then be able to defend their decision (or advise higher management) using that.
My firm has partially transitioned through this curve. We went went from "fully externally supplied" systems, to an architecture that combines "externally supplied" (core functionality) with "low code" about 6 years ago. I would argue (as a financial manager) that that lead to a more flexible and more affordable architecture. A funny mixed bag problem arose though: the curve of business demands grew harder than that of IT-delivery. So IT delivered more value, but business keeps demanding a faster pace. If I project this line to the future AI will most certainly harm our external suppliers. We keep getting better at DIY development and "low code" will transition towards "no code". Not really "no code" of course, but DIY IT developed tooling.
The age of the business developer has re-arrived.
For the first time in my career, I can point to multi million euro external suppliers, tell my environment "that's basicly an API + authentication from X to Z, let's develop that ourselves" and get a response of "When" instead of "No". B2B SaaS is toast in my perspective, as are boutique firms delivering solutions + consulting. I can create a million euro team easily (that's like five developer years), if they deliver a successful insourcing. And now I feel like writing MBA-slop, but's it's all about growing your IT maturity. All insourced code is future maintenance expenditure. You need to balance that to the benefits.
> All insourced code is future maintenance expenditure. You need to balance that to the benefits.
I love this perspective. I feel like the pendulum has swung too far back to "it's easy to build, it'll be easy to support". But to be fair, it was probably too far the other way a few years ago: "it was easy to buy, it'll be easy to have them support it".
Other than trial and error, how do you think about pricing out maintenance costs for insourced code vs purchased functionality?
Building a project is very different than building a product as a billing engine.
Reminded me of big balls and DOGE. Didn’t we vibe code our entire government by now?
> management simply doesn't want to be responsible for it
The problem with this kind of thinking is that it strips away all nuance. At some point you have to be responsible for something ... otherwise you don't have a business. You are simply a wrapper around your SaaS providers and tightly coupled to their success. The key is knowing when to offload and when to keep it in house. Quite frankly, your average weekend MBA VP simply doesn't have the expertise to make these kinds of decisions. This is why so many VPs exit before things get bad.
> At some point you have to be responsible for something ... otherwise you don't have a business.
Uh, yeah? No kidding. That's why you focus on your core business. If your core business isn't "writing a new and better Jira", don't write a new Jira.
Your profit margin is my opportunity.
Think about it differently - let's say a free OSS product can be installed and you can use ALL features except for LDAP (because that's the paywalled portion that requires you to buy it for $25k / month.)
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".
> an employee to spend 100% of their time maintaining the app at 10k per month
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.
sorry, what do you mean?
1. Enthusiastic employee (vibe-)codes a replacement for a turnkey SaaS product that the company uses.
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
And don't forget the safety in getting to say "our systems are down because of [X TRUSTED SOFTWARE FROM LARGE KNOWN BRAND] and we're just waiting for them to fix it" instead of "our shitty internal tooling is broken and no one knows how to fix it"
1 reply →
This feels like it goes along the lines of "people's vibe code is cluttering up our PR's, people still need to review" -- it misses the boat: models are already capable of getting you up to speed on how the code is organized and works, in as much as you want to or need to be up to speed. They are already helping me cut down review time because I don't need to aimlessly hop around, I have a good starting point that I can scrutinize and dialogue about. Same thing here: employee leaves company -- about 3 years ago you would be right, now the company is left with an unmaintainable mess of legacy code and tech debt. TODAY this just doesn't matter. No one really needs to read that code too closely, it's already easy for agents to digest and explain and modify.
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.
3 replies →
I think you can avoid the pain by thoughtfully designing it to avoid lock-in. You want it so that if needed, a dev can vibe-code a migration tool to the equivalent SaaS offering. AI lowers the barrier for creating these in-house replacements, but it also lowers the barrier for scrapping them too.
1 reply →
Even more accurate (I work in this space):
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!
.............
3 replies →
ya ok, this makes total sense. i agree.
If I understand correctly many organizations will not develop original stuff internally, because nobody internally wants to be the one is shouted at if something goes wrong.
That's a huge part of it. But also you presumably hired a full-time programmer for a reason, and in almost every case that reason was not to have somebody to write and maintain your CRM system. So any system they build and maintain is not just another thing for you to worry about, it's a huge chunk of time that the developer isn't doing what you hired them for.
Depends on the size of the organization.
If software already exists that does X, X is a solved problem. You didn't hire a developer to solve already-solved problems.
ya, i agree. but in your world, this company will fail https://glue.ai/ ?
1 reply →
[dead]
I like to bring up JIRA example. You could replace it in-house yeah it is just tickets with statuses. /s
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.
You guys keep using services like Jira, Salesforce, Stripe, Datadog, etc. While those are definitely the biggest names, I don't think people are referring to those SaaS platforms as the ones they will replace or try to build an inhouse version of. It will be things like ETL pipeline services, data scraping services, maybe some internal analytics SaaS. The niche things that cost a lot because they’re in a sweet spot where only a few people need them, but no one used to have the resources to build them in-house. So, when the salesperson called and offered a perfect solution to their problem, they bought the service. Those are the ones that will be more targeted for in-house solutions.
Yes, but the market is punishing the former right now.
They are though, atlasians stock is in the toilet. The world seems to think Jira will be replaced by AI built in house replacements, for some reason
2 replies →