14 ms·

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

• scotty79 9mo ago
  Your profit margin is my opportunity.
• misiti3780 9mo ago
  sorry, what do you mean?
  • vladms 9mo ago
    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.
    • bandrami 9mo ago
      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.
    • dyauspitr 9mo ago
      Depends on the size of the organization.
  • sbarre 9mo ago
    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
    • hbn 9mo ago
      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"
      • sbarre 9mo ago
        Yes that's reverse-implied(??) in the "Pain" step. ;-)
    • pverheggen 9mo ago
      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.
      • runako 9mo ago
        The thing about lower barriers is that it makes it easier for e.g. Salesforce to raise the level of expectations. And that's the moving target. New employees will come from elsewhere and wonder how a company is operating using tools from 2020 when X, Y, Z are becoming industry standard. 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.)
    • 9mo ago
  • bandrami 9mo ago
    If software already exists that does X, X is a solved problem. You didn't hire a developer to solve already-solved problems.
    • misiti3780 9mo ago
      ya, i agree. but in your world, this company will fail https://glue.ai/ https://glue.ai/ ?
      • bandrami 9mo ago
        They're in series A right now, so most likely yes they will fail like most new businesses do. Internal chat is a hugely competitive field with multiple large players (and Teams has had Copilot for a while now). So, I wish them the best, but this is pretty much exactly the kind of "existing product + AI" mashups that will have a tendency to burn out over the next couple of years, just like "our old business but with .com at the end" did back in 1999-2000.
• jonwinstanley 9mo ago
  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
  • bandrami 9mo ago
    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.
    • sbarre 9mo ago
      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.
      • Thorentis 9mo ago
        We need a new one: "Where someone is using a vibe-coded internal tool made by the creative department that keeps needing bug fixes, there's a start up waiting to happen."
      • robocat 9mo ago
        Paper forms used to be our main competitor. Paper forms have some amazing features that software really can't compete with. And also some significant downsides that software fixes.
  • osigurdson 9mo ago
    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.
• mittensc 9mo ago
  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?
  • sbarre 9mo ago
    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.
  • bandrami 9mo ago
    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
    • mittensc 9mo ago
      depends how much the vendor chargers.
  • pm90 9mo ago
    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.
  • g947o 9mo ago
    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.
• baxtr 9mo ago
  This vibe-coding-will-replace-SaaS insanity is the new crypto-will-replace-fiat-money insanity.
  • turnsout 9mo ago
    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.
    • baxtr 9mo ago
      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.
    • scotty79 9mo ago
      SaaS is mostly sales.
      • turnsout 9mo ago
        100%, particularly B2B SaaS
    • fatherwavelet 9mo ago
      There is also an aspect of thinking no one will go to restaurants when anyone can make the same food at home.
  • rishabhaiover 9mo ago
    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.
    • yuiasdfj 9mo ago
• mym1990 9mo ago
  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.
  • re-thc 9mo ago
    > 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.
  • risyachka 9mo ago
    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.
    • icedchai 9mo ago
      Yep. Wait until they realize one of their vibe coded apps validates everything client side and their entire DB is open to the world.
      • scotty79 9mo ago
        Like that never happened with non-vibecoded stuff.
• ozim 9mo ago
  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.
  • NewsaHackO 9mo ago
    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.
    • likecarter 9mo ago
      Yes, but the market is punishing the former right now.
    • girvo 9mo ago
      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
      • anhner 9mo ago
        when it takes 10 seconds to do anything on Jira, it's not hard to see why people want alternatives
• cj 9mo ago
  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)
  • brianwawok 9mo ago
    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.
    • john-h-k 9mo ago
      This is the exception to the rule
    • cj 9mo ago
      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.
      • phil21 9mo ago
        If you’re having a correlated outage like that, then it’s likely you fix the prod issue before the cloud engineers at some giant cloud company even respond to an internal escalation much less fixes an issue. More than likely your prod issue is causing the logging problem. 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.
• snowwrestler 9mo ago
  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.
  • intrasight 9mo ago
    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.
  • camdenreslink 9mo ago
    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.
• dzonga 9mo ago
  & 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
  • mooreds 9mo ago
    Here are the most recent 10-Ks for Salesforce and Workday. https://www.sec.gov/ix?doc=/Archives/edgar/data/0001108524/000110852425000006/crm-20250131.htm https://www.sec.gov/ix?doc=/Archives/edgar/data/0001108524/0... https://www.sec.gov/ix?doc=/Archives/edgar/data/0001327811/000132781125000056/wday-20250131.htm https://www.sec.gov/ix?doc=/Archives/edgar/data/0001327811/0...
• almosthere 9mo ago
  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".
  • bandrami 9mo ago
    > 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.
• groundzeros2015 9mo ago
  > "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.
  • bandrami 9mo ago
    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
    • groundzeros2015 9mo ago
      And both are completely different arguments then your original post.
      • bandrami 9mo ago
        No, those are the two main reasons management don't want to have internal systems belong to them
        • groundzeros2015 9mo ago
          I see. I misread. My mistake. I agree - the issue is not technical it’s the responsibility for the project.
    • wvenable 9mo ago
      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.
      • habinero 9mo ago
        1. No. The point of having engineers is to build product and make you money. They cannot make you money if you waste their time on building internal apps that do not make you money. There's no point in saving $20K on an SaaS app if you use $100K in developer time and miss out on $1M of potential revenue. We get paid the big bucks because we can make companies a lot of money. 2. Haaaa no, that's 100% not how that works. If you buy a SaaS product, the company made that product. They have documentation. They have training. You can hire people who have worked on that system before. If it goes down, they get paged. If you write the tool, all of that is on you to do. If it goes down, you have to fix it. If it screwed up data, you have to fix it. Any time anyone has any questions? Guess what, you're the one they'll ask. All of that costs the company money, because you don't work for free. When you quit, the app is now useless and can't be fixed unless you did a lot of work beforehand. It's best to think of DIY apps like those really really sticky noxious tarpits. It might look safe or easy to get into, but good luck getting out of them. You might end up at the bottom with the bones of everyone else who thought that DIYing it was a good idea.
• puppymaster 9mo ago
  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.
• murukesh_s 9mo ago
  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.
• qkeast 9mo ago
  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.
• jaybrendansmith 9mo ago
  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.
• kstrauser 9mo ago
  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.)
  • noduerme 9mo ago
    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.
    • kstrauser 9mo ago
      Ah, so you’re the one who made that same company’s marketing website!
      • noduerme 9mo ago
        Hahaha. I'm not above that kind of work. Sometimes having a consistent codebase for both things comes in pretty handy if you need to tie em together or just need to spruce up the CSS every few years. I don't intentionally make my work hard for anyone else to maintain. I comment and write tests pretty thoroughly in case someone else comes along. Or in case I get woken up at 6am with a bad hangover.
• noduerme 9mo ago
  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.
  • normie3000 9mo ago
    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?
    • noduerme 9mo ago
      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.
• theptip 9mo ago
  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.
  • majormajor 9mo ago
    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.
    • theptip 9mo ago
      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.
      • majormajor 9mo ago
        I think with a SaaS you're trading user research and workflow design for a certain lack of customization, and that for 90% of businesses that will remain the right call. (And for the ones where it's not the right call, I think the contractor model also makes more sense than in-house LLM-generated-user-tool teams. That's a lot of code to pile up under a very small team for long-term maintenance. Yeah, "the agents can do it," but you're making ever-more balls that the people overseeing the agents will have to juggle over time.) If you're selling honey online, say, how bespoke does your inventory management tool really need to be? And are there no lessons you'd learn from a SaaS tool that you'd not have thought of on your own?
• beefsack 9mo ago
  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.
• zaptheimpaler 9mo ago
  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.
• notyourwork 9mo ago
  Reminded me of big balls and DOGE. Didn’t we vibe code our entire government by now?
• bjclark 9mo ago
  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.
• bitwize 9mo ago
  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.
• rhubarbtree 9mo ago
  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.
• j4coh 9mo ago
  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.
• yasdevae 9mo ago
  [dead]
• chanux 9mo ago
  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.
• wjnc 9mo ago
  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.
  • mooreds 9mo ago
    > 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?
• notarobot123 9mo ago
  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.
• tremon 9mo ago
  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.
• jpfromlondon 9mo ago
  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.
• j45 9mo ago
  Building a project is very different than building a product as a billing engine.
• gnz11 9mo ago
  > 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.
  • habinero 9mo ago
    > 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.
• whurley23 9mo ago
  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.
  • lazide 9mo ago
    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.
• carlosft 9mo ago
  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.
• fhd2 9mo ago
  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.
• JALTU 9mo ago
  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...
  • blubber 9mo ago
    And since you became management, you have refered to software only by the stock symbols of the owning companies?
• pc86 9mo ago
  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.
  • patmcc 9mo ago
    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".
• scoofy 9mo ago
  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.
• saassaver 9mo ago
  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.