I have multiple side projects that I would never have contemplated building before but whose utility now exceeds the much lower cost to build.
I got a few weeks in to each and then stalled on all of them because the effort and motivation required to extend beyond the crazed early days _is_ still more than the utility I get.
In a professional context, paying someone for software to do something outside my core domain is still the practical option compared to the motivation and effort needed to maintain another dependency.
I've been surprised by how far my motivation has taken me. I have multiple projects now that are so much further ahead than I have ever managed before. I would get stuck on some small issue or key-decision and then would struggle to move past it.
Certainly, I still have those tendencies, but it's easier than ever to push through and build a throwaway version with code that might not be what I end up shipping, but is enough to help me understand the final shape of the solution. Once that happens, I'm unblocked and away I go again.
The mental cost of building throwaway code has essentially dropped to zero for me. Of course, I keep working now until light mode comes on automatically on my Mac, but that's a whole other problem.
To be clear these projects made it way further than they could have without AI. But any blocker that takes me out of the flow can easily become the thing that ends it. Not even necessarily because it’s a difficult problem, but just because I’m no longer getting that AI high.
why not just focus on the 1 you like the most and push through? I agree with you in principle but I think having multiple projects and each being not super important in your mind will not keep you motivated. Instead focusing on one thing that you really really want to solve will usually work better because your motivation comes from within and effort follows. Too many choices can be a bad thing as well when it comes to taking action.
I like that you point out that the cost to build software is still not 0. And in my expirence it’s further from 0 than I would expect. I often find myself thinking I can rebuild a project (or usually improve upon an existing one) in just a few days. And yet when it comes down to making anything well, it still takes time and iteration.
It’s a bit funny because I felt this way before coding agents as well, like you could clone something in just a few weeks. But in practice my expectations are rarely accurate.
I find myself fixing the spec of my software often, and that makes lots of existing code obsolete. Creating working code is getting cheaper with AI, but creating great specs which make the software easy and intuitive to use seems to be more difficult for AI.
Why? Because you have to actually use the product to discover what is wrong, or sub-optimal, with it.
Yeah exactly, I literally don’t know how to change my spec until I’ve gathered more data.
I was building a transaction classifier recently and I initially thought it would be a trivial “solved” problem. Throw transactions into a tiny local LLM, let it classify. But that approach was too slow, and not accurate enough. I didn’t know that though until I tried and then needed to change the spec.
You'd probably get much further along by fine tuning a small BERT style encoder model based classifier for it. IMO, even something as simple as training a linear classifier on the CLS token embeddings from a frozen encoder might work.
So wait ... you're not even going to train based on what you want, just "throw into"? Did you actually put in work on a very clear and accurate prompt with a full manual on what to do?
Throwing a tiny little LLM at it helped me assess that it was far too slow for me to reasonably use at the scale I needed. So it didn’t really matter how accurate the prompt was. I was more just pointing out that I didn’t know if would be too slow without trying it. I maybe could have done some simple math in retrospect, but trying it out was easy enough
I feel like the build threshold discussed is _extremely_ optimistic?
> But does that always hold true? Let’s take the other side for a second by examining a much higher-priced SaaS product. Gemini reports that the price of a fully loaded Salesforce seat is ~$500/mo. Say you need 50 seats, that’s $25k/mo!
> For that price you could have 1.5x engineering resources (25 / 16.7) working on your clone full time. Once again, a CRM’s a reasonably complex piece of software and a rebuild wouldn’t be trivial, but no matter how you construe it, this is closer to a “build” decision, even for a smaller company. (And with Salesforce down 30% YTD, the markets seem to believe it too.)
If $25k for salesforce is too much, my view is that your first thought should be to look for a cheaper competitor, not build a thing?
Ok, you vibed your own. Great! Now you need custom integrations for everything, you can't hire out of the market, you have to re-train everyone and all new starters, you have an extra thing to HA, monitor, back up etc. People can't google for answers about it anymore. This is before we can talk about what it actually costs in terms of bikeshedding, roadmap creation, project management, product management etc etc. Plus compliance, security, your org policies and relevant regulations if you're storing personal information. Think of how many meetings it would take to get this done, the political costs, and how much it costs to get consensus in big companies.
There is also RISK. Nobody is gonna get fired for choosing SalesForce, but there are many different angles by which building an in-house solution for something considered commodity (tho an expensive one) can go horribly wrong.
The more subtle cost is _brain space_. Human engineers have context limits too; switching projects has costs, and you can't put ONE engineer on the thing and expect it to be sustainable. You need about a minimum of four people to understand anything you expect to maintain and operate long term.
Your org's capacity for engineering focus is precious and IMHO you should try really hard not to use it on non-core stuff unless you have to.
I don’t know if it will continue to seem euphemistically optimistic until after the Sun burns out or quantum solves NP.
There is a range of information quality to sort out, but frontier coding models are learning a great deal from interacting with effective developers that the models can then model their agents on.
But they’ll never YOLO. Life goes on outside us and all around us ;)
“Build vs buy” assumes that there are only two parties. If it’s easier to build internally, then it’s easier for a 3rd party competitor to enter the market and bid the price down. I think the "zone of viability" is real, it just narrows and shifts downward.
The author hints at this in a footnote:
> It does, however, pencil out to use a different product instead. In this particular case, it’s easy: use Linear instead of Jira.
I wouldn't underestimate the community effect of software. There are plenty of features that get shipped because a small but important minority requested them, only to benefit the long tail of users who never knew to ask for such a feature but now find it indispensable. If everyone is building their own isolated solutions, how does this positive externality manifest itself?
Much of the business world sees that as very high risk.
In their eyes, community moderation is an inverted pendulum that eventually falls over. Either one niche and unprofitable direction dominates, or the community turns it into an incoherent junk drawer of features. You're also opening yourself up to competitors poisoning the whole thing. To investors, it signals a lack of vision.
Feedback isn't inherently good or bad, but it can be unnecessary risk if you already know you have a solid product that meets the most common use cases with the strongest demand.
This is why successful products tend to be very mediocre. They're the average of all insights considered. Doing anything else is leaving money on the table.
To answer your question, nobody wants their product to become the platform that launches your directly competing product. That's suicide. You're asking to ride someone else's coattails.
Perhaps as open source software, but it would require building a community that agrees on some common procedures about what to build and how to use AI.
As someone who built a niche SaaS I can see both sides of this.
If you are looking to replicate the exact same feature set of an existing product - buying would almost always be a better choice.
But it's rare for avg customer needs to perfectly match product features. Most often they need 20-40% of the product + some custom, business specific logic that's missing and is later fixed with spreadsheets/integrations. In that case it depends on how mission critical this software is.
I'd say investing into the core software that runs your business might very well be worth the effort, even if it's 10x between build vs buy.
This is quite an interesting one to me because dotnet has a couple of job queues, with hangfire (hangfire.io) probably being the main one. I've used hangfire for years and it's OK, but it was lacking a few critical features for the current project I'm working on. I've tried extending hangfire before and it's quite unpleasant to work with, so I decided to go down the LLM build route https://github.com/hackf5/sheddueller. It took about a week to build the service that did everything I need. The code is good enough and it was definitely the right choice. The real benefit is that I can add any features that I need and make it work in harmony with the main project.
> One user there posted about how his company had been spending $400/mo on Atlassian’s Jira. He’d felt personally slighted by this outrageous bill, so he’d had his team build a new internal task tracker using Claude.
I dislike Jira as much as anyone but these anecdotes are far removed from what I've experienced. Opus 4.8 continues to trip itself up over trivialities that go beyond one-shotting a most basic CRUD app, let alone implementing something complex you yourself don't understand.
Too bad there is absolutely no way of steering the output and it's a completely random slot machine, as so thoughtfully explained by lots of people lots of time, who for sure know what they are talking about.
Every new line increases dramatically the complexity of the software which requires more cost and most maintenance. If you stop at a single tool this is still manageable.
Imagine now that you do the same for 10 other products - all critical systems. You will end up running the tools to save on imaginary money. Even then, software vendors can simply undercut and offer the software cheaper because they use agents too.
So building everything in-house is not the right way to go unless you have no other option - which was always the case pre coding assistants.
If you ask engineers of course they will say yes. It is yet another nice toy project and interesting challenge. But decision makers need to learn to say no - more often they used to.
I think this is a well thought out understanding of your specific snapshot in time. However these are indeed exponential times. It may be more realistic to do your calculus on time shifting assumptions, especially given how clear you are about the development time and life cycle of the product.
Also, some software businesses use a ton of aggregated or hard to get data which needs to be synthesized and that doesn't go away even if the llm driven coding is cheap.
Be careful with making decisions about your livelihood based on a rational calculus. As you correctly point out, there is a threshold for which a programmer or company should not even blink at the cost of software. It's often the case that if the software they're buying saves one single hour of productivity, it's value-positive... and yet they won't buy it. Individual devs are notorious for refusing to pay a cent out of their own wallet, turning up their noses at anything that isn't offered open source and completely free. Enterprises manage to saddle what should be a no-brainer trivial expense into dozens of hours of bureaucracy that cost two orders of magnitude more than the expense the bureaucracy is for.
Your customers are more irrational than you are, and your appeal to them will likely need to resonate with them on an emotional level rather than logical one. I would argue that marketing is the hardest part of entrepreneurship, by far.
Yes, I roughly agree with all of this. In fact, for most of my existence, I'm been one of those cheap programmers.
The circumstances that led to me trying to push River for the next few months were somewhat accidental, and it felt like a good moment to at least make a go of trying to make it work. I'm not committing the rest of my career/life to any particular decision one way or the other.
I'll reiterate too that I believe we're still quite early in the LLM age and are still waiting for the other shoe to drop. All LLM-generated software feels free at the moment because it's still novel and the exhilaration of accomplishment when you build something complex inside of a few hours is addictive beyond words. However, within a year or two I think we're going to have a lot more software, all of which needs maintaining to some degree, and we're going to become a little more reluctant to generate new projects to add to the heap. This'll cause an adjustment back to a more compromise position.
(Also, could be completely wrong about all of that, so take it for what it is.)
Another aspect Ive been talking about lately with the huge burst of AI productivity recently, is that its much simpler to point AI at the things that have been hanging out in the back of your mind. The things you started and got stuck. The bugs you sort of have an idea on but cant sit down and think through.
These are the obvious first targets to point AI at when onboarding. And it plows through a ton of the low hanging fruit. Then where are you after that? Suddenly productivity falls off a cliff and you are left in reality: good ideas are hard to come by and theres more to business than software.
The future is going to see an uptick in overall productivity for sure. And AI will tighten feedback loops enormously, in really positive ways. But current trajectories are already starting to come down to reality, and businesses are slowly realizing they still need to put in the hard work.
Unrelated: love your stuff. Ive gotten a lot out of your articles and I really appreciate you posting such well written content.
Plus, too many companies don't spend their money in a logical fashion. As a manager, you can direct your $200,000/year engineer in any way you want, but try to spend any amount of money on a new SaaS product and procurement might huffily demand hours of your time and weeks of delay to authorize even $40/month, let alone $400/month.
That said, I think the path Brandur is describing is well-trodden and proven out by projects like Sidekiq.
Some of my past employers were pretty good about authorizing small and medium expenditures quickly, or in some cases not requiring any authorization at all.
This feature almost always went away as the company grew and the abuse became too much to ignore. I thought it would be safe to trust developers and to deal with isolated abuse when it came up, but the number of people who see any spending perk and treat it like a target they need to maximize is way higher than I ever thought.
There are a lot of examples of this, like companies that offer to pay for dinner if people have to stay late. This seemingly always turns into a game where people hang out in the office and scroll on their phones until the allowed time arrives, then they take their dinner and leave. This doesn’t happen at small companies where you can witness what people are doing, but cross the threshold to big company and many people start doing whatever they can get away with.
There was a big story a few years ago about how employees at a big company were even caught using this perk to order their home groceries because the DoorDash like service they used had launched a section where they could get those things delivered with their food. It was crazy that employees making mid six figure salaries were still brazenly breaking the rules for personal gain of a couple hundreds of dollars per month.
This is one of those things that makes me go insane at the last three companies I worked at and the reality is there's just an in group of people whose purchases are basically auto approved, and anyone below our out of this group might as well pound sand.
This creates so many weird inefficiencies that I have seen an entire billion dollar companies analytics run on free google sheets + compute because they couldn't figure out what to use for five years.
Thankfully, most devs aren't the one making purchasing decisions in B2B. I haven't seen any change in the build vs buy equation for real businesses tbqh, and in B2B, those are the customers you want to target anyways, not the indie devs who think they can build Dropbox in a weekend. In B2C, I can definitely see this being true, but I have very little experience there so anything I say here is more on gut-feeling than anything else. But I have over 10 years of experience in B2B, and I've never seen businesses more eager to buy, to free teams up to work on the things they're experts at -- myself included.
If we can show that the hour of productivity saved is worth more, would the individual dev still want to build it because they like tinkering with it. The individual dev would value the time of playing with the code more than the time of productivity saved?
I think people are more rational than given credit for. Their decisions are not necessarily rational for the company, but they are often pretty rational for themselves.
And some bureaucracy is often necessary to evaluate security, data protection agreements, etc.
Some companies are not efficiently allocating resources and so projects sit in legal/security review for longer than is reasonable, but it makes sense that individual developers don't have unilateral authority to use 3rd party vendors.
Thanks applfanboysbgon, this is the type of comment every HN commented should aspire to!
Packed full of insightful comments that cut against the grain and are logical even if unpleasant to hear, delivered with kindness and a thoughtful, caring tone, and backed up with strong justification.
Did I mention delivered with kindness?
And it mirrors my experience. The struggle has me convinced that to sell anyone anything your offer has to be so overwhelmingly good they’d not just win from having it but lose from not having it. It’s why the slick salespeople of old would talk for minutes at you just to get you to buy a thing once - non stop talking attacking your objections from every angle before finally moving on to the price. Sure, as the person offering the thing you see the value - but your prospect just showed up to your site, they’ve got an Amazon purchase to finish on another tab, the baby is crying in the other room, and there’s an outage. Sorry - your thing does what again?
Dismissing software non-buyers as irrational, or asserting certain purchases are "no-brainers" is missing the mark.
Acquiring new software is a major commitment beyond just the price tag. It means integration, continuous maintenance, dealing with forced UI updates, supply chain exposure, and so on.
Every seasoned dev (unless very lucky) has dealt with bad software acquisitions, almost all of which seemed to be great deals at the time of purchase.
This is so true, and it’s true of libraries, OSS, etc. I frequently build instead of using a library simply because I’ll know and can fix the warts, I’m automatically in tune with the state of the code, and I’m in control of maintenance. Of course if the code is too big (TLS library like OpenSSL) then it changes. But I still try to avoid external stuff just because of the costs you listed.
Brandur of course knows more than me, and his framing sounds correct. I would be worried about whether the TAM of Go + Postgres is enough for business sustainability, but that says probably more about my fears than the reality in this huge market called “internet”
If your choices are "use Jira" vs. "build task management software with an LLM" then you are already in a losing proposition. Go spend some time with Redmine before building your own. Redmine is free, far better than Jira, and already includes the features you don't yet realize you need.
I recently asked Claude to duplicate Google Docs. It practically threw up. I tried to have it write a plan, decompose it, deobfuscate it.
It gave me all sorts of reasons why this was a terrible idea. I've never seen it resist a task so directly and relentlessly.
It knew.
One point worth considering is that tools like Jira and Salesforce have dozens of screens and modals. But you only ever look at one at a time. So the enormity of the ask "duplicate Jira" is hard to see in its totality.
With Google docs, the entirety of the tool is almost one screen. It resists decomposition. So the true gravity of the request is more in your face.
You say you want to duplicate Asana or Service Now or Jira or Zendesk? Great, here's the keys to the car, a tank of gas, and a quarter to call me on a payphone when you get there. Oh wait payphones don't exist anymore...but it doesn't matter because you're never getting there.
These software platforms are built by thousands of engineers over more than a decade of dedicated work. They are they way they are for reasons. To think someone can duplicate them with some clever prompting is to completely fail to understand the scale of the problem at hand.
I'm not sure I'm following you. What does 'duplicate Google Docs' mean? We already have OSS rich text editor (ProseMirror) and CRDT implementations (yjs, automerge). Are you talking about replicating every single enterprise Docs has? Integration with a large suite of other services you control? Replicating the business model too?
'duplicate Google Docs' spans everything from providing the actual service to replicating the world and becoming Google.
I was looking for a dead on feature for feature exact replica including look and feel. You are 100% correct there are some excellent tools and libraries that duplicate most (all?) of the features. But I was playing around with the idea of what it would take for a perfect replica (for science of course). Turns out it's really hard even if you jump start it with those libraries and an existing reference implementation.
That was the point of my comment... Robust commercial software is hard.
I get this a lot. Yeah, you can have an LLM copy what I've built, no it's not going to be as good unless you also spend the equivalent of the amount of hours I've spent on it.
Not a SalesForce dev, but there is a bit of oversimplification what CRM SaaS is today.
Almost everything integrates with SF today and most often understanding, replicating and maintaining these integration pathways may need more than 1.5 engineers. You then bring 3 engineers (to cover absences) and buy enough tokens.
And we haven't even scratched other parts: disaster recovery, security, legal (CCPA/GDPR), etc
I would say that the main reason to buy corporate software is to delegate responsibility to a 3rd party. By doing in-house you take the legal, regulatory responsibility of pretty sensitive records, that will definitely bite you in the future, or will easily inflate the build costs
Corporations will be quite happy with really simple features if they're packaged right. I'm selling software that mostly does things that a good programmer could whip up in a couple of days or weeks, but what cost me most of the development time wasn't the features but all the FUD around them e.g. SSO, multitenancy, audit logs, corporate design support, ... Most enterprise software could be replaced with simple scripts and command line tools if they had this enterprise layer. I'd wager tons of SaaS is just simple open-source software and libraries behind a management layer.
There's another dimension to the Salesforce CRM "build" argument; which is to reduce your 25 seats down to 5, and expend Eng resources to building "agents" to automate many recurring data-entry CRM tasks.
This is also the reason the stock has hit a 3-year low. Not because CRM can be replaced entirely. But because the seat count can be reduced 50%+.
I find that younger software engineers sometimes take the attitude of: Why would I pay for that when I could easily just do it on my own? As they grow and gain more responsibilities that flips to: Why would I build and maintain something on my own when I could pay someone else a few bucks to do it? At least I feel I went through this change as I grew professionally...
So many things I am completely capable of doing on my own I simply don’t want to. I have better things to do. More valuable things.
This right here is the key difference! Yes anyone can vibe code a replacement for many apps - but will it still run 2 years later (assuming they get it 'running' in an prod environment at all
A few months ago I had a conversation with a friend who runs a small company doing about $10M/year. He was thrilled about being able to drop his $40K/year Salesforce expense. One of his employees, let's call him Joe, a customer service person with some coding experience, used AI to create a CRM for the company that addressed most, if not all, of their needs.
He, the CEO, saw this as saving $40K per year. Until I asked simple questions:
What happens when Joe leaves?
When he goes on vacation?
If he has a health emergency?
The LLM isn't going to magically maintain the software, evolve, fix or support it.
What are you going to do?
The obvious conclusion was that he likely had to hire another person to work with Joe on this in-house CRM and, at a minimum, have redundant project ownership. Backup for development, maintenance and support.
The easy conclusion was: This will save him $40K a year until he decides to hire another person, at which point this "free" software will cost him $150K per year, $110K/year more than what he was paying Salesforce. If he does not hire a second person to work in the internal CRM, he might get lucky and things could be fine for a few years or he will have to face a crisis at some point when Joe is no longer around and nobody knows the first thing about his mini-CRM, not even the LLM.
I wonder how many people are falling for this trap these days. The allure of zero-cost software vs. the reality of introducing risk, technical debt and organizational risk.
To be sure, we are using LLM's extensively. However, until this is better understood, in the realm of software development it is constrained to what I would call "advanced auto complete" at the file level rather than anything resembling project-wide work. When we do write full applications, they are often relatively trivial internal tools that a person could complete in not much more than one week. In other words, easy to understand and code if another engineer had to jump in and none of these utilities are mission critical.
Something to bear in mind when planning to attack a market where the existing vendor charges a high price (Salesforce in this example) -- they can reduce their price in the future.
Good luck on your new endeavour! Selling to devs is hard, did you consider building in public? That would def help get traction imo.
Your point about considering API design and overall architecture would definitely differentiate among the all AI slop out there
Not everyone is a 200k engineer. Even kids with some hacker skills or university students with time > salary, who have access to LLM's, will start making cheaper alternatives and get into business that way for themselves.
In business you should focus more on how much you can make than on how much you can save.
If you are lucky to have talented staff on your payroll, they should put their hard work into things which increase business revenue and profit, not things which reduce expenses. Unless there's an expense which is outrageous.
If that engineer in the article example can build a Salesforce clone, then he can instead build more valuable software which the business can sell for a profit. It could be a Salesforce clone even.
I have multiple side projects that I would never have contemplated building before but whose utility now exceeds the much lower cost to build.
I got a few weeks in to each and then stalled on all of them because the effort and motivation required to extend beyond the crazed early days _is_ still more than the utility I get.
In a professional context, paying someone for software to do something outside my core domain is still the practical option compared to the motivation and effort needed to maintain another dependency.
I've been surprised by how far my motivation has taken me. I have multiple projects now that are so much further ahead than I have ever managed before. I would get stuck on some small issue or key-decision and then would struggle to move past it.
Certainly, I still have those tendencies, but it's easier than ever to push through and build a throwaway version with code that might not be what I end up shipping, but is enough to help me understand the final shape of the solution. Once that happens, I'm unblocked and away I go again.
The mental cost of building throwaway code has essentially dropped to zero for me. Of course, I keep working now until light mode comes on automatically on my Mac, but that's a whole other problem.
To be clear these projects made it way further than they could have without AI. But any blocker that takes me out of the flow can easily become the thing that ends it. Not even necessarily because it’s a difficult problem, but just because I’m no longer getting that AI high.
If you're like me, then much of the utility was in the novelty itself. But I had that problem before AI :)
why not just focus on the 1 you like the most and push through? I agree with you in principle but I think having multiple projects and each being not super important in your mind will not keep you motivated. Instead focusing on one thing that you really really want to solve will usually work better because your motivation comes from within and effort follows. Too many choices can be a bad thing as well when it comes to taking action.
I like that you point out that the cost to build software is still not 0. And in my expirence it’s further from 0 than I would expect. I often find myself thinking I can rebuild a project (or usually improve upon an existing one) in just a few days. And yet when it comes down to making anything well, it still takes time and iteration.
It’s a bit funny because I felt this way before coding agents as well, like you could clone something in just a few weeks. But in practice my expectations are rarely accurate.
I find myself fixing the spec of my software often, and that makes lots of existing code obsolete. Creating working code is getting cheaper with AI, but creating great specs which make the software easy and intuitive to use seems to be more difficult for AI.
Why? Because you have to actually use the product to discover what is wrong, or sub-optimal, with it.
Yeah exactly, I literally don’t know how to change my spec until I’ve gathered more data.
I was building a transaction classifier recently and I initially thought it would be a trivial “solved” problem. Throw transactions into a tiny local LLM, let it classify. But that approach was too slow, and not accurate enough. I didn’t know that though until I tried and then needed to change the spec.
You'd probably get much further along by fine tuning a small BERT style encoder model based classifier for it. IMO, even something as simple as training a linear classifier on the CLS token embeddings from a frozen encoder might work.
Yeah, Ive tried a bi-encoder, cross encoder and some small LLMs so far. I think I’ll do BERT soon too
age old machine learning wisdom: start with the simplest model, then try complex ones later
So wait ... you're not even going to train based on what you want, just "throw into"? Did you actually put in work on a very clear and accurate prompt with a full manual on what to do?
Throwing a tiny little LLM at it helped me assess that it was far too slow for me to reasonably use at the scale I needed. So it didn’t really matter how accurate the prompt was. I was more just pointing out that I didn’t know if would be too slow without trying it. I maybe could have done some simple math in retrospect, but trying it out was easy enough
Not every lottery winner has a detailed strategy.
I feel like the build threshold discussed is _extremely_ optimistic?
> But does that always hold true? Let’s take the other side for a second by examining a much higher-priced SaaS product. Gemini reports that the price of a fully loaded Salesforce seat is ~$500/mo. Say you need 50 seats, that’s $25k/mo!
> For that price you could have 1.5x engineering resources (25 / 16.7) working on your clone full time. Once again, a CRM’s a reasonably complex piece of software and a rebuild wouldn’t be trivial, but no matter how you construe it, this is closer to a “build” decision, even for a smaller company. (And with Salesforce down 30% YTD, the markets seem to believe it too.)
If $25k for salesforce is too much, my view is that your first thought should be to look for a cheaper competitor, not build a thing?
Ok, you vibed your own. Great! Now you need custom integrations for everything, you can't hire out of the market, you have to re-train everyone and all new starters, you have an extra thing to HA, monitor, back up etc. People can't google for answers about it anymore. This is before we can talk about what it actually costs in terms of bikeshedding, roadmap creation, project management, product management etc etc. Plus compliance, security, your org policies and relevant regulations if you're storing personal information. Think of how many meetings it would take to get this done, the political costs, and how much it costs to get consensus in big companies.
There is also RISK. Nobody is gonna get fired for choosing SalesForce, but there are many different angles by which building an in-house solution for something considered commodity (tho an expensive one) can go horribly wrong.
The more subtle cost is _brain space_. Human engineers have context limits too; switching projects has costs, and you can't put ONE engineer on the thing and expect it to be sustainable. You need about a minimum of four people to understand anything you expect to maintain and operate long term.
Your org's capacity for engineering focus is precious and IMHO you should try really hard not to use it on non-core stuff unless you have to.
I don’t know if it will continue to seem euphemistically optimistic until after the Sun burns out or quantum solves NP.
There is a range of information quality to sort out, but frontier coding models are learning a great deal from interacting with effective developers that the models can then model their agents on.
But they’ll never YOLO. Life goes on outside us and all around us ;)
“Build vs buy” assumes that there are only two parties. If it’s easier to build internally, then it’s easier for a 3rd party competitor to enter the market and bid the price down. I think the "zone of viability" is real, it just narrows and shifts downward.
The author hints at this in a footnote: > It does, however, pencil out to use a different product instead. In this particular case, it’s easy: use Linear instead of Jira.
I wouldn't underestimate the community effect of software. There are plenty of features that get shipped because a small but important minority requested them, only to benefit the long tail of users who never knew to ask for such a feature but now find it indispensable. If everyone is building their own isolated solutions, how does this positive externality manifest itself?
my experience in b2b SaaS is that a small but vocal minority are usually asking for features that the majority don’t want nor need.
the features that affect the long tail can come from vocal complaints, but the best usually are ones you have to go asking around to find out about.
the really important people to ask have seemed to be the ones who don’t know how to ask or assumed they aren’t allowed to ask or something.
YMMV
Much of the business world sees that as very high risk.
In their eyes, community moderation is an inverted pendulum that eventually falls over. Either one niche and unprofitable direction dominates, or the community turns it into an incoherent junk drawer of features. You're also opening yourself up to competitors poisoning the whole thing. To investors, it signals a lack of vision.
Feedback isn't inherently good or bad, but it can be unnecessary risk if you already know you have a solid product that meets the most common use cases with the strongest demand.
This is why successful products tend to be very mediocre. They're the average of all insights considered. Doing anything else is leaving money on the table.
To answer your question, nobody wants their product to become the platform that launches your directly competing product. That's suicide. You're asking to ride someone else's coattails.
Perhaps as open source software, but it would require building a community that agrees on some common procedures about what to build and how to use AI.
As someone who built a niche SaaS I can see both sides of this.
If you are looking to replicate the exact same feature set of an existing product - buying would almost always be a better choice.
But it's rare for avg customer needs to perfectly match product features. Most often they need 20-40% of the product + some custom, business specific logic that's missing and is later fixed with spreadsheets/integrations. In that case it depends on how mission critical this software is.
I'd say investing into the core software that runs your business might very well be worth the effort, even if it's 10x between build vs buy.
> even if it's 10x between build vs buy
think twice about this lol
This is quite an interesting one to me because dotnet has a couple of job queues, with hangfire (hangfire.io) probably being the main one. I've used hangfire for years and it's OK, but it was lacking a few critical features for the current project I'm working on. I've tried extending hangfire before and it's quite unpleasant to work with, so I decided to go down the LLM build route https://github.com/hackf5/sheddueller. It took about a week to build the service that did everything I need. The code is good enough and it was definitely the right choice. The real benefit is that I can add any features that I need and make it work in harmony with the main project.
> One user there posted about how his company had been spending $400/mo on Atlassian’s Jira. He’d felt personally slighted by this outrageous bill, so he’d had his team build a new internal task tracker using Claude.
I dislike Jira as much as anyone but these anecdotes are far removed from what I've experienced. Opus 4.8 continues to trip itself up over trivialities that go beyond one-shotting a most basic CRUD app, let alone implementing something complex you yourself don't understand.
> Are you crazy?! Anything you ship can be instantly displaced by an internal package built by an LLM!
That's funny, the first thing every LLM I use generally does is install a bunch of third party packages...
Too bad there is absolutely no way of steering the output and it's a completely random slot machine, as so thoughtfully explained by lots of people lots of time, who for sure know what they are talking about.
Actually the math is worse.
Every new line increases dramatically the complexity of the software which requires more cost and most maintenance. If you stop at a single tool this is still manageable.
Imagine now that you do the same for 10 other products - all critical systems. You will end up running the tools to save on imaginary money. Even then, software vendors can simply undercut and offer the software cheaper because they use agents too.
So building everything in-house is not the right way to go unless you have no other option - which was always the case pre coding assistants.
If you ask engineers of course they will say yes. It is yet another nice toy project and interesting challenge. But decision makers need to learn to say no - more often they used to.
I think this is a well thought out understanding of your specific snapshot in time. However these are indeed exponential times. It may be more realistic to do your calculus on time shifting assumptions, especially given how clear you are about the development time and life cycle of the product.
> the internet’s most wretched hive of engagement farmers and master solicitors of fake information and fictional anecdotes, LinkedIn
Great quote!
Ahem. "AI-powered engagement farmers..."
Truly agree with the framing of buy vs build.
Also, some software businesses use a ton of aggregated or hard to get data which needs to be synthesized and that doesn't go away even if the llm driven coding is cheap.
Be careful with making decisions about your livelihood based on a rational calculus. As you correctly point out, there is a threshold for which a programmer or company should not even blink at the cost of software. It's often the case that if the software they're buying saves one single hour of productivity, it's value-positive... and yet they won't buy it. Individual devs are notorious for refusing to pay a cent out of their own wallet, turning up their noses at anything that isn't offered open source and completely free. Enterprises manage to saddle what should be a no-brainer trivial expense into dozens of hours of bureaucracy that cost two orders of magnitude more than the expense the bureaucracy is for.
Your customers are more irrational than you are, and your appeal to them will likely need to resonate with them on an emotional level rather than logical one. I would argue that marketing is the hardest part of entrepreneurship, by far.
Yes, I roughly agree with all of this. In fact, for most of my existence, I'm been one of those cheap programmers.
The circumstances that led to me trying to push River for the next few months were somewhat accidental, and it felt like a good moment to at least make a go of trying to make it work. I'm not committing the rest of my career/life to any particular decision one way or the other.
I'll reiterate too that I believe we're still quite early in the LLM age and are still waiting for the other shoe to drop. All LLM-generated software feels free at the moment because it's still novel and the exhilaration of accomplishment when you build something complex inside of a few hours is addictive beyond words. However, within a year or two I think we're going to have a lot more software, all of which needs maintaining to some degree, and we're going to become a little more reluctant to generate new projects to add to the heap. This'll cause an adjustment back to a more compromise position.
(Also, could be completely wrong about all of that, so take it for what it is.)
Another aspect Ive been talking about lately with the huge burst of AI productivity recently, is that its much simpler to point AI at the things that have been hanging out in the back of your mind. The things you started and got stuck. The bugs you sort of have an idea on but cant sit down and think through.
These are the obvious first targets to point AI at when onboarding. And it plows through a ton of the low hanging fruit. Then where are you after that? Suddenly productivity falls off a cliff and you are left in reality: good ideas are hard to come by and theres more to business than software.
The future is going to see an uptick in overall productivity for sure. And AI will tighten feedback loops enormously, in really positive ways. But current trajectories are already starting to come down to reality, and businesses are slowly realizing they still need to put in the hard work.
Unrelated: love your stuff. Ive gotten a lot out of your articles and I really appreciate you posting such well written content.
"one of those cheap programmers"
"one of those stingy programmers" might be clearer wrt this use of "cheap" meaning "tightwad" not "inexpensive"
Plus, too many companies don't spend their money in a logical fashion. As a manager, you can direct your $200,000/year engineer in any way you want, but try to spend any amount of money on a new SaaS product and procurement might huffily demand hours of your time and weeks of delay to authorize even $40/month, let alone $400/month.
That said, I think the path Brandur is describing is well-trodden and proven out by projects like Sidekiq.
Some of my past employers were pretty good about authorizing small and medium expenditures quickly, or in some cases not requiring any authorization at all.
This feature almost always went away as the company grew and the abuse became too much to ignore. I thought it would be safe to trust developers and to deal with isolated abuse when it came up, but the number of people who see any spending perk and treat it like a target they need to maximize is way higher than I ever thought.
There are a lot of examples of this, like companies that offer to pay for dinner if people have to stay late. This seemingly always turns into a game where people hang out in the office and scroll on their phones until the allowed time arrives, then they take their dinner and leave. This doesn’t happen at small companies where you can witness what people are doing, but cross the threshold to big company and many people start doing whatever they can get away with.
There was a big story a few years ago about how employees at a big company were even caught using this perk to order their home groceries because the DoorDash like service they used had launched a section where they could get those things delivered with their food. It was crazy that employees making mid six figure salaries were still brazenly breaking the rules for personal gain of a couple hundreds of dollars per month.
This is one of those things that makes me go insane at the last three companies I worked at and the reality is there's just an in group of people whose purchases are basically auto approved, and anyone below our out of this group might as well pound sand.
This creates so many weird inefficiencies that I have seen an entire billion dollar companies analytics run on free google sheets + compute because they couldn't figure out what to use for five years.
Thankfully, most devs aren't the one making purchasing decisions in B2B. I haven't seen any change in the build vs buy equation for real businesses tbqh, and in B2B, those are the customers you want to target anyways, not the indie devs who think they can build Dropbox in a weekend. In B2C, I can definitely see this being true, but I have very little experience there so anything I say here is more on gut-feeling than anything else. But I have over 10 years of experience in B2B, and I've never seen businesses more eager to buy, to free teams up to work on the things they're experts at -- myself included.
Build a good product and they will come.
If we can show that the hour of productivity saved is worth more, would the individual dev still want to build it because they like tinkering with it. The individual dev would value the time of playing with the code more than the time of productivity saved?
https://xkcd.com/1319/
and
https://xkcd.com/1205/
I think people are more rational than given credit for. Their decisions are not necessarily rational for the company, but they are often pretty rational for themselves.
And some bureaucracy is often necessary to evaluate security, data protection agreements, etc.
Some companies are not efficiently allocating resources and so projects sit in legal/security review for longer than is reasonable, but it makes sense that individual developers don't have unilateral authority to use 3rd party vendors.
Thanks applfanboysbgon, this is the type of comment every HN commented should aspire to!
Packed full of insightful comments that cut against the grain and are logical even if unpleasant to hear, delivered with kindness and a thoughtful, caring tone, and backed up with strong justification.
Did I mention delivered with kindness?
And it mirrors my experience. The struggle has me convinced that to sell anyone anything your offer has to be so overwhelmingly good they’d not just win from having it but lose from not having it. It’s why the slick salespeople of old would talk for minutes at you just to get you to buy a thing once - non stop talking attacking your objections from every angle before finally moving on to the price. Sure, as the person offering the thing you see the value - but your prospect just showed up to your site, they’ve got an Amazon purchase to finish on another tab, the baby is crying in the other room, and there’s an outage. Sorry - your thing does what again?
Dismissing software non-buyers as irrational, or asserting certain purchases are "no-brainers" is missing the mark.
Acquiring new software is a major commitment beyond just the price tag. It means integration, continuous maintenance, dealing with forced UI updates, supply chain exposure, and so on.
Every seasoned dev (unless very lucky) has dealt with bad software acquisitions, almost all of which seemed to be great deals at the time of purchase.
This is so true, and it’s true of libraries, OSS, etc. I frequently build instead of using a library simply because I’ll know and can fix the warts, I’m automatically in tune with the state of the code, and I’m in control of maintenance. Of course if the code is too big (TLS library like OpenSSL) then it changes. But I still try to avoid external stuff just because of the costs you listed.
> integration, continuous maintenance, dealing with forced UI updates, supply chain exposure, and so on
Not to mention enshittification, predatory prices increases, the supplier getting bought out, etc. The list goes on...
Brandur of course knows more than me, and his framing sounds correct. I would be worried about whether the TAM of Go + Postgres is enough for business sustainability, but that says probably more about my fears than the reality in this huge market called “internet”
But software is never sold to endusers, only licensed
I feel like my HN comments fall now into 3 categories :
- free software exists since the 80s, having software that costs literally 0, not even being "very cheap" is NOT new
- Goodhart's law where we get a new KPI only to make the entire process and ecosystem around it pointless
- the rest (but it's rare)
so... yeah this one is option #1.
I am forced to use jira soon as I was using BB issues and that is expiring soon.
So I'll build something simple for us, that integrates with our systems and how we like to do things.
It won't cost us much since our meagre requirements are nothing comparted to a full fledged Jira replacement.
Without LLMs it would have taken maybe a couple of days effort and perhaps an hour a month to fix any bugs we miss or add an extra overlooked feature.
With LLMs ... we shall see.
We won't set out to solve all of the world's issue tracking problems, so that will save a lot of time.
KISS is the goal.
If your choices are "use Jira" vs. "build task management software with an LLM" then you are already in a losing proposition. Go spend some time with Redmine before building your own. Redmine is free, far better than Jira, and already includes the features you don't yet realize you need.
I recently asked Claude to duplicate Google Docs. It practically threw up. I tried to have it write a plan, decompose it, deobfuscate it.
It gave me all sorts of reasons why this was a terrible idea. I've never seen it resist a task so directly and relentlessly.
It knew.
One point worth considering is that tools like Jira and Salesforce have dozens of screens and modals. But you only ever look at one at a time. So the enormity of the ask "duplicate Jira" is hard to see in its totality.
With Google docs, the entirety of the tool is almost one screen. It resists decomposition. So the true gravity of the request is more in your face.
You say you want to duplicate Asana or Service Now or Jira or Zendesk? Great, here's the keys to the car, a tank of gas, and a quarter to call me on a payphone when you get there. Oh wait payphones don't exist anymore...but it doesn't matter because you're never getting there.
These software platforms are built by thousands of engineers over more than a decade of dedicated work. They are they way they are for reasons. To think someone can duplicate them with some clever prompting is to completely fail to understand the scale of the problem at hand.
I'm not sure I'm following you. What does 'duplicate Google Docs' mean? We already have OSS rich text editor (ProseMirror) and CRDT implementations (yjs, automerge). Are you talking about replicating every single enterprise Docs has? Integration with a large suite of other services you control? Replicating the business model too?
'duplicate Google Docs' spans everything from providing the actual service to replicating the world and becoming Google.
I was looking for a dead on feature for feature exact replica including look and feel. You are 100% correct there are some excellent tools and libraries that duplicate most (all?) of the features. But I was playing around with the idea of what it would take for a perfect replica (for science of course). Turns out it's really hard even if you jump start it with those libraries and an existing reference implementation.
That was the point of my comment... Robust commercial software is hard.
I get this a lot. Yeah, you can have an LLM copy what I've built, no it's not going to be as good unless you also spend the equivalent of the amount of hours I've spent on it.
Not a SalesForce dev, but there is a bit of oversimplification what CRM SaaS is today.
Almost everything integrates with SF today and most often understanding, replicating and maintaining these integration pathways may need more than 1.5 engineers. You then bring 3 engineers (to cover absences) and buy enough tokens.
And we haven't even scratched other parts: disaster recovery, security, legal (CCPA/GDPR), etc
I would say that the main reason to buy corporate software is to delegate responsibility to a 3rd party. By doing in-house you take the legal, regulatory responsibility of pretty sensitive records, that will definitely bite you in the future, or will easily inflate the build costs
Corporations will be quite happy with really simple features if they're packaged right. I'm selling software that mostly does things that a good programmer could whip up in a couple of days or weeks, but what cost me most of the development time wasn't the features but all the FUD around them e.g. SSO, multitenancy, audit logs, corporate design support, ... Most enterprise software could be replaced with simple scripts and command line tools if they had this enterprise layer. I'd wager tons of SaaS is just simple open-source software and libraries behind a management layer.
There's another dimension to the Salesforce CRM "build" argument; which is to reduce your 25 seats down to 5, and expend Eng resources to building "agents" to automate many recurring data-entry CRM tasks.
This is also the reason the stock has hit a 3-year low. Not because CRM can be replaced entirely. But because the seat count can be reduced 50%+.
I find that younger software engineers sometimes take the attitude of: Why would I pay for that when I could easily just do it on my own? As they grow and gain more responsibilities that flips to: Why would I build and maintain something on my own when I could pay someone else a few bucks to do it? At least I feel I went through this change as I grew professionally...
So many things I am completely capable of doing on my own I simply don’t want to. I have better things to do. More valuable things.
Yes, build versus buy. The eternal question!
> and maintain
This right here is the key difference! Yes anyone can vibe code a replacement for many apps - but will it still run 2 years later (assuming they get it 'running' in an prod environment at all
1.) your site looks gorgeous 2.) so does the Bulgarian scene from the top, added it to my list 3.) excellent thinking, I'm wishing you good luck
A few months ago I had a conversation with a friend who runs a small company doing about $10M/year. He was thrilled about being able to drop his $40K/year Salesforce expense. One of his employees, let's call him Joe, a customer service person with some coding experience, used AI to create a CRM for the company that addressed most, if not all, of their needs.
He, the CEO, saw this as saving $40K per year. Until I asked simple questions:
What happens when Joe leaves?
When he goes on vacation?
If he has a health emergency?
The LLM isn't going to magically maintain the software, evolve, fix or support it.
What are you going to do?
The obvious conclusion was that he likely had to hire another person to work with Joe on this in-house CRM and, at a minimum, have redundant project ownership. Backup for development, maintenance and support.
The easy conclusion was: This will save him $40K a year until he decides to hire another person, at which point this "free" software will cost him $150K per year, $110K/year more than what he was paying Salesforce. If he does not hire a second person to work in the internal CRM, he might get lucky and things could be fine for a few years or he will have to face a crisis at some point when Joe is no longer around and nobody knows the first thing about his mini-CRM, not even the LLM.
I wonder how many people are falling for this trap these days. The allure of zero-cost software vs. the reality of introducing risk, technical debt and organizational risk.
To be sure, we are using LLM's extensively. However, until this is better understood, in the realm of software development it is constrained to what I would call "advanced auto complete" at the file level rather than anything resembling project-wide work. When we do write full applications, they are often relatively trivial internal tools that a person could complete in not much more than one week. In other words, easy to understand and code if another engineer had to jump in and none of these utilities are mission critical.
Something to bear in mind when planning to attack a market where the existing vendor charges a high price (Salesforce in this example) -- they can reduce their price in the future.
Good luck on your new endeavour! Selling to devs is hard, did you consider building in public? That would def help get traction imo. Your point about considering API design and overall architecture would definitely differentiate among the all AI slop out there
What evidence is there that building in public has any impact in traction?
I know a founder who has been building in public and it has had zero impact on his inbound.
[flagged]
Not everyone is a 200k engineer. Even kids with some hacker skills or university students with time > salary, who have access to LLM's, will start making cheaper alternatives and get into business that way for themselves.
In business you should focus more on how much you can make than on how much you can save.
If you are lucky to have talented staff on your payroll, they should put their hard work into things which increase business revenue and profit, not things which reduce expenses. Unless there's an expense which is outrageous.
If that engineer in the article example can build a Salesforce clone, then he can instead build more valuable software which the business can sell for a profit. It could be a Salesforce clone even.
“buy vs. build. . . the calculus changed”
was the gun having a smoke?
Hilarious. The shorthand bullet points do clarify my priorities.
https://news.ycombinator.com/threads?id=ares623#48627225
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]