Build vs Buy
Posted by Round_Wasabi103@reddit | ExperiencedDevs | View on Reddit | 51 comments
What are some common questions, trade-offs, and risks do folks think of (both engineering/technical) when deciding whether to build a platform or solution from scratch in-house vs buying an existing off the shelf solution/product to solve a problem?
fuckoholic@reddit
If it fits your use case, then buy, if you have to build custom stuff, then build your own.
engineer_in_TO@reddit
Build to find out why you need to buy, don’t invest too much time but you’ll generally have a understanding of why it’s hard and you can work from there.
_MJomaa_@reddit
Even when you decide to build, you don't have to start from scratch!
Two YC startups used my SaaS starter kit https://achromatic.dev to build their AI startup - that makes me super proud somehow :)
dashingThroughSnow12@reddit
It exists on a spectrum.
For example, your code is running on operating systems that other people built. To someone reading this in 2025, the reaction is “of course”. To someone reading this comment in 1960, the answer would be “oh, that’s rare.”
CraftySeer@reddit
It's almost always better to find an existing solution to solve a problem rather than build it from scratch, whether you buy or find open-source solution. The exception being when that particular problem is your business's particular value prop. Developer hours are too expensive. Other people have already solved most development problems already.
UsualNoise9@reddit
I am not sure I fully agree. Liability and supportability for third party code can carry higher hidden costs than writing in house. It really depends on the specific situation, I don’t think there is a one size fits all answer.
DeterminedQuokka@reddit
This super depends on the case. Some external services are quite bad. And in some cases slow to fix. If you depend on a SLO of 100% uptime this can be a huge problem.
I’ve definitely had jobs where we had to build because there weren’t any options that were reliable enough. But if someone is reliable it’s significantly better to just ask them to fix it.
I actually think AI is going to make this really interesting because a lot of the AI buy options are very unstable but the cost to build is also huge. I’m looking forward to this. Right now our head of AI multiple times has tried to tell me when OpenAI goes down for 3 days every few months it’s because they are doing something really cool so I shouldn’t worry about it.
National_Count_4916@reddit
Liability and support need to be quantified. Is it something you can clone and fork? Is support for defects, and are you actually going to run into them? Is there support for feature enhancements?
Buy / reference in using 3rd party libraries is still a very good value proposition as long as you can mitigate or understand risks. Build still carries cost in your own defects, lost velocity and maintenance
congramist@reddit
Almost always is doing some heavy lifting here, ime.
I have seen some heinous things done with COTS solutions, where orgs just ended up paying devs to build custom software around the pile of shit anyway.
They end up with custom software with a pile of shit at the core that cannot be replaced.
I think it depends on if you’re working on the core of your business or ancillary services.
Round_Wasabi103@reddit (OP)
Can you clarify or expand on what you mean with regards to the exception being the company’s value proposition? Is there an example?
CraftySeer@reddit
Like if you are Excel, then the problem that you want to solve is spreadsheets, you don’t wanna use an open source solution for that, you want to be the best. For authentication and authorization, those problems have been solved.
Round_Wasabi103@reddit (OP)
Ah, that makes sense. You should own your core business and build it.
DeterminedQuokka@reddit
The main question for me is always can I afford to maintain it. And the answer is almost always no. You can only own so much code.
A great example is auth. We buy auth for like 1.5k or something. The cost to us to maintain it is definitely higher than that.
When someone asked if I could in house it I estimated initial cost at 75K and ongoing at 2k a month.
angrynoah@reddit
No one thinks about VENDOR RISK.
Is that vendor still going to be around in 2 years? Are they going to double prices? Are they going to remove features you depend on? Are they going to sue you?
For example, you don't want Oracle as a vendor, under any circumstances, ever. Extrapolate as needed.
Round_Wasabi103@reddit (OP)
I’ve never thought of a vendor suing. Other than contract and service disputes, what are some other cases or examples of vendor suing?
yoggolian@reddit
The usual stories are around failed projects, where one side says the vendor’s software did not perform as designed, expected or sold, the other side says that the customer were muppets who (a) signed off on things when there weren’t actually happy (or understanding what they agreed to), (b) stalled the project by not having the right people and approvals at the right times. Usually the vendor sues when the customer decides that they are not going to pay the (sometime partial, sometime whole) bill at the end.
zacker150@reddit
Vendor risk can be managed through lawyers.
angrynoah@reddit
How is a lawyer going to help you recover from a vendor going out of business? Or losing all your data? Or being acquired by Oracle? (That one has happened to me three times!)
Unstable-Infusion@reddit
Early stage startup: always buy
Mid level company: usually buy, promote engineers to leadership who demonstrate good judgement and don't fall for NIH-syndrome
Mature well staffed company: build in-house, trust the leaders you selected to make good decisions
CarelessPackage1982@reddit
Never outsource your main competency.
ninetofivedev@reddit
Most engineers want to build. The right answer is almost always to buy.
coredalae@reddit
Differentiating business process, probably build.
Anything else, if something exists and costs can somehow make sense, probably buy.
jdsalaro@reddit
If you write comments as you make arguments, I feel for people reading them
What do you mean by my quoted sebtence?
coredalae@reddit
Mostly just to the point,
But a differentiating business process is the thing that your company does that places you ahead of other companies. Aka the differentiating factor.
Those should be business critical and probably should be built in house instead of having someone else do it and inhouse your knowledge
LogicRaven_@reddit
Almost always buy.
A mistake I've seen a few times is underestimating the maintenance cost of build, blinded by the desire to build.
Creating the main functionality would require only X months. But then you need to support, take in new feature requests. There are edge cases. There is tooling - need an admin panel, a decent user UI, need to support multiple input data formats, etc. You quickly end up continously using precious internal capacity on a commodity instead of building your own product.
Consider also vendor lock in and supply chain stability. Some vendors have a tendency to gradually increase prices, the more deeply they are integrated into the customer's ecosystem. Some vendors go bankrupt or get acquired.
How much flexibility you need to replace a component depends on the importance of service and the stability of the provider.
forgottenHedgehog@reddit
I also wouldn't underestimate lack of domain knowledge in the company.
Goingone@reddit
Cost to buy vs time to build (development cost).
Is there a commercial product available that meets our internal needs?
What type of vendor risk does buying expose me to?
….those are the main ones that come to mind.
Round_Wasabi103@reddit (OP)
What are some vendor risks? I can think of support service agreements, quality of the product, maturity of the third-party and whether they’ll go out of business.
notarobot1111111@reddit
Some things we take into account:
You have to think of what sensitive data the vendor will have access to.
If this vendor gets compromised, what are the implications to your business.
If you decide to switch vendor later on, how, difficult will it be to migrate? (Vendor lock in)
forgottenHedgehog@reddit
And how easy is it integrate into the existing ecosystem.
TheOneWhoMixes@reddit
The equation seems really simple at face value, but...
Time to build is typically vastly underestimated. 2 months turns into 10, and woops nothing is optimized so infrastructure costs are 10x what we pitched, and once the PoC was demo'd the whole team was moved over to a new project, which means no ongoing feature work or technical support. How do you buffer the time to build estimate with these things in mind? Maybe your org is just way better than mine about estimating, but IMO we're just universally bad at it as humans.
When these conversations end in a No, I've very rarely seen it come from "it didn't meet our internal needs". Either someone says "well it's missing X critical feature, but we could build that", and the suits hear "that guy can build this entire solution on his own. Kill the negotiations." Or people underestimate the commercial products and overestimate their internal needs.
I'd rather have a product that solves 80% of the problems it claims to solve consistently, with a good UX/DevEx, and decent support, than one that claims to solve 110% of our problems(!!!), but in reality solves 50% of problems and causes even more problems when it goes down or is unusable because, well, documentation wasn't part of the estimate.
Goingone@reddit
Estimating is a larger topic, but it doesn’t impact just one side (although development time is more likely to be off and by larger amounts). Plenty of times I’ve seen UAT/onboarding periods extend well beyond their estimate.
The good “build” examples are usually very one sided. For example, paying millions of dollars a year for something that would take a couple people ~6 months to build. Even if that ends up taking 2 years to build, it’s still easily worth it.
allllusernamestaken@reddit
Maintenance cost is far bigger than the build cost
metaphorm@reddit
it's a common mistake to badly underestimate just how much work goes into building a custom system for anything non-trivial. engineering hours are expensive in terms of real dollar cost and opportunity cost. buy is almost always the right starting point. use an off-the-shelf tool until you can't anymore (due to excessive billing, or lack of needed capabilities). just get started with something, anything, sooner rather than later. the learnings that come out of tool adoption are pure gold.
Icy_Computer@reddit
We generally break it down into three parts.
We start with estimating effort and maintenance costs for creating in house. Then usually double or triple that number, depending on our familiarity on the domain.
The next item is to come up with a cost analysis of buying. This includes up-front cost, yearly licensing, with price increases factored in based on the historical cost of the product.
The final part is to evaluate the vendor. How long have they operated? How quickly do they address CVEs? How often are new features released?
Then we list out pros/cons and make a decision.
DoneWhenMetricsMove@reddit
This is one of those decisions that can make or break a product timeline. I've been on both sides of this many times and here's what I usually consider:
- Time to market vs control - Buying gets you moving fast but you're stuck with their roadmap and limitations. Building gives you control but can easily turn into a 6-month rabbit hole.
- Core vs non-core - If it's your competitive advantage, build it. If it's just infrastructure (like auth, payments, monitoring), buy it unless you have a really specific need.
Total cost of ownership - Everyone forgets the maintenance part. That $50/month SaaS suddenly looks good when you realize you need 2 engineers maintaining your custom solution.
- Team bandwidth - Be honest about your team's capacity. I've seen too many teams bite off more than they can chew and end up with half-built solutions that nobody wants to touch.
- Integration complexity - Sometimes the "simple" third-party solution needs 3 weeks of integration work and custom workarounds. Other times building from scratch is cleaner.
- Risk tolerance - Vendor lock-in vs technical debt. Pick your poison.
One thing I learned the hard way - prototype first before making the call. Spend a few days building a basic version AND integrating the bought solution. You'll quickly see which path makes more sense for your specific situation.
What's the context for your decision? That usually helps narrow down the trade-offs.
illuminatedtiger@reddit
Worked for a company where this was often framed as lead vs standardize. If it's outside of your company's domain and there are no plans to enter or pivot - you're probably going to want to buy. This doesn't consider size, availability of acceptable solutions or integration cost so YMMV.
missing-comma@reddit
I think this also depends on what you're buying.
In the Node/TS/JS realm you may find a lot of "freemium" services where you can use the community version but suddenly your only upgrade is the "enterprise" version costing 100k/year commitment that offers way more than you need.
And then at this point your code didn't abstract it away and you're stuck between refactoring costs or yearly costs due to vendor lock-in.
One-Pudding-1710@reddit
Eternal question and tension between engineers, leadership, finance, etc.
For eg, most telecom operator are wondering if they should buy a streaming platform or build one
morosis1982@reddit
Maintenance. Is this a system you want to or have the experience to maintain?
In general what I do is consider whether it's core to the business. If this is your special sauce, you might want to build it. If it's a side quest and there's an easy off the shelf product, buy it.
I'm working in a team right now that makes a lot of decisions like this. We typically will use a standard info management system like a CMS or PIM for essential entry and crud type services but build the special sauce of what happens downstream with the consumers ourselves.
The other consideration is how well does the use case fit an existing system. I've been in situations where the obvious choice was to use an external product but the options were rubbish. Sometimes this means building your own, sometimes extending with your own build.
UntestedMethod@reddit
Maintenance, support, who is held accountable when something goes wrong
How much customization is needed or how specifically niche are the company's requirements (ie. is there even a viable solution on the market already)
Financial cost
Urgency of delivery
Longer-term requirements... for example, is it possible the company's needs might outgrow the cost-effective tiers of the offering, down the line when the company is already deeply invested in the product as part of their processes
lupin-the-third@reddit
I think DDD encourages to always buy, outsource, or use open source solutions to generic subdomains (fancy word for component/domain and generic just means something solved many times like payments, invoices, etc), unless:
* This is too expensive
* You only need a very limited section of the subdomain that would be trivial to keep inhouse. In this case it is changed to supporting subdomain - a feature that is necessary to support the main product, but can be assigned as lower priority and does not need to be perfect.
* The subdomain actually has non-standard logic or is tightly coupled with the core of the business. In this case it is actually a core domain is must be written in house and kept tidy.
poolpog@reddit
Does your company make money with the thing you are going to build? Build it
Otherwise buy
YK5Djvx2Mh@reddit
Buy while you build. Do this with a lot of different tools, and you can quickly build a product that works, then refine the pieces as you go, with the benefit of cutting costs and avoiding forever increasing licensing fees
originalchronoguy@reddit
A topic that is dear to me. I always bring this up to a point where people think I am weaponizing it.
I have built a lot of things from scratch to a point, I'll be first to admit, it's values diminished vs a COTS (Commercial Off the Shelf System).
I want to be a realist and keep business in check. A lot of projects tend to be ego driven, pet projects.
Mostly because I don't want to be part of those projects anymore. So when something takes too long, I'll be first to multiply the man hours x cost to give value to a feature. $60,000 for a drop-down menu? And I am not wrong. I am being overly conservative because I didn't add in Project management and design overhead. Real cost is more likely $80,000.
When something goes on for months and years, I say, "Why are we spending $2 million dollars" for something that we can buy for $500 that serves 10 people?
Some people hate that but it definitely moves things along and put things into perspective. If we are spending $60k, $100k, $1 million on something with a user base of 10 or 50 or 100, it better be thought out and justified.
This reigns in frivolous vanity features that serve no purpose but gives a UI designer 4 weeks to produce beautiful mockups. My engineering leadership is ok with my stance because well, it is the factual truth. To ground Product owners a dose of reality to scale things back that don't matter.
I will be the first person to kill off one of my babies that I sprung out of ideation, MVP, to production. When it is passed it's expiration, it needs to go to the pasture.
I am not against build-it inhouse. When it serves a purpose and provides value that can't be done with COTS. In-house work does have value but it needs to be weighed in with long term maintenance cost.
elprophet@reddit
I usually go with the Domain Driven Design advocated approach of core, supporting, and generic domains. Build your core domain- obviously. It's, like... your business. If you can't build that, why are you in software? Generic is anything that has "been solved". Database, OS, but also Observability and Orchestration. Buy them (or pick the most popular OSS). Supporting are the kinda glue things that you're not entirely sure- a healthy ratio is about 20% build 80% buy. Dont build a logger, but do add a small shim that normalizes the interface and provides your orgs defaults.
These are, of course, guidelines not rules.
ClearGoal2468@reddit
The buy vs build equation is changing every year. Software gets cheaper to write because tools and frameworks are more powerful and relative labor costs are falling, and business needs to be more flexible year on year.
In China, where labor costs are lower still, businesses are less likely to do saas implementations than in-house builds than in the west.
factotvm@reddit
The difficulty is that you are rarely in a position to effectively evaluate which one to buy until you’ve tried to build it.
dnult@reddit
We built a lot of things in-house simply because nothing off the shelf would integrate easily or required a lot of effort to convert. Licensing costs that go up every year until the end of life announcement comes, was another reason to build what we needed. But it all depends on what youre trying to do - no one size fits all.
SSA22_HCM1@reddit
"From scratch" is almost always a bad idea, but "off the shelf" can be just as bad. Many products require specific workflows and have certain limitations. If those are acceptable to the organization, it can work.
However, if a ton of stuff needs to be customized or adapted, it can be a complete shitshow. Instead of building on some existing open-source framework or product, now you're developing a ton of stuff against (typically) buggy, closed-source APIs with awful developer support.
DrFloyd5@reddit
Advice to my employers don’t ask me I lean heavily into build it yourself.
You can usually make a bespoke solution with about the same level of difficulty it takes to integrate with a custom solution. Big big big “your mileage may vary”.
I worked at a place that paid for a general solution and then proceeded to warp it into a custom solution. They paid quite handsomely. We could have built it from the ground up for far less.
But…
Sometimes companies pay for someone else’s solution not for technical reasons. They pay to shift liability.