Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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!
by chasing - 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.
by andreybaskov - “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.
by bze12 - 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?by monkeydust
- 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.
by xyzzy123 - 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.
by ahamilton454 - 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.
by zingar - 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.