In NIH-heavy orgs, “build” isn’t a decision. It’s a reflex.
Engineers don’t evaluate buy/partner/build. They default to build—either because they assume nothing good exists, or because they quietly discount the true internal costs until the spreadsheet says what they want it to say.
Sometimes that reflex produces real advantage. Most of the time, it produces a slow-motion transfer of value from your product roadmap into internal maintenance, coordination overhead, and a permanently worse margin profile.
This post breaks down the real costs of NIH (“Not Invented Here”)—the ones that never make it into the deck—and offers a simple framework for when building is actually the right move.
Because when you build, you’re not picking a tool. You’re committing to run a small software company inside your company:
NIH is rarely a feature decision. It’s an operating model decision.
- A backlog
- A support queue
- Oncall
- Incident response
- Security patching
- Documentation and training
- Upgrades and migrations
- Stakeholder management
- Budgetary constraints and annual negotiations
- Internal “customers” with expectations
If you aren’t willing to staff and operate that internal product for years, you aren’t “building a feature.” You’re creating a liability with a UI.
The visible costs are bad. The invisible ones are worse.
You already called out some big ones: larger teams, higher cost, usually not more specialized early, weaker problem understanding than dedicated vendors, velocity drag, margin impact.
Here are more compelling reasons NIH is expensive—grouped by the kinds of damage it does.
1) The economics: you don’t pay once, you pay forever
You trade a vendor bill for a permanent fixed cost
Buying is (mostly) variable cost. Building becomes fixed cost:
- Headcount
- Managers
- Oncall rotation
- Infra and tools
- Security and compliance work
- Support burden across the org
These fixed costs quietly eat into margin profiles.
Your “build cost” estimate is almost always fake
Most internal business cases compare:
Vendor cost (real)
vs
“2 engineers for 2 quarters” (imaginary, probably wrong)
What’s missing:
- Fully-loaded comp (not salary)
- The “extra” engineers who get pulled in when reality hits
- SRE and security overhead
- Incident costs
- Internal training + support
- The opportunity cost of what those engineers would have shipped
- The recognition that this is now a product, and products live forever, meaning you’re stuck carrying this opportunity cost… forever.
If you’re not modeling those, you’re not modeling the cost.
Vendors amortize R&D across a market. You amortize across one company.
A vendor spends $10M building a thing and spreads it across hundreds or thousands of customers.
You spend $1–3M building a thing and spread it across exactly one customer: you.
That is rarely a winning equation unless you have scale and the problem is core to your differentiation.
You create a “second roadmap” nobody planned for, probably staffed by non-specialists
Building doesn’t end when v1 ships. v1 is just when the actual costs begin:
- Hardening
- Reliability
- Monitoring
- Scalability
- UX debt
- Data migrations
- Backward compatibility
- Compliance changes
- Performance tuning
- Feature parity requests
That’s a whole roadmap that competes with your actual product.
2) Execution: you underestimate edge cases and overestimate your timeline
Time-to-value gets wrecked
Buying usually gets you to “works well enough” this quarter.
Building gets you to “almost there” for three quarters, followed by:
- “we cut scope”
- “we’ll do it in v2”
- “we need to refactor the foundation”
Meanwhile the rest of the company is waiting, and your customers see less progress.
The last 10% contains 90% of the pain
Dedicated vendors have already learned the hard lessons:
- weird data
- weird permissions
- weird integrations
- weird compliance regimes
- weird customers doing weird things at scale
Your v1 will look reasonable in a demo and collapse under reality.
You will not upgrade “later”
“Later” is where internal systems go to die.
- Vendors ship improvements, patches, compliance updates, and new integrations as their business.
- Your internal system competes against your real product for investment.
So you end up running a legacy system you don’t love, but can’t replace, and everyone depends on.
3) Org and culture: NIH is a coordination engine
More people means more communication pathways
This is perhaps the most underrated cost. More headcount is not linear productivity, in fact it comes with combinatorially increasing communication overhead.
As teams get bigger:
- alignment time grows
- design review cycles multiply
- decision latency increases
- “who owns this?” becomes a recurring meeting
NIH is how you turn a crisp roadmap into an org chart.
You create “internal product orphans”
Internal platforms often fail in a very specific way:
- lots of dependency
- vague ownership
- low prestige
- perpetual underinvestment
Nobody markets it internally. Nobody measures it like a product. Everyone complains. It becomes a tax on the whole company.
You trap great engineers in maintenance
Engineers join companies to build differentiated things.
NIH often means:
- chasing edge-case bugs
- writing integrations vendors already ship
- rebuilding standard capabilities
- becoming a support org
That’s a morale hit and a retention risk—especially if your competitors are letting their teams build actual product.
NIH rewards ego over judgment
It trains the org to believe:
- “external = inferior”
- “we’re special”
- “we can do it better” (without evidence)
High-performing companies don’t win by building everything. They win by building the right things and buying everything else.
4) Product and GTM: you ship worse product while telling yourself it’s “strategic”
Control is not the same as quality
Early internal versions tend to be:
- less robust
- less feature complete
- less secure
- less battle-tested
- worse documented
Customers don’t care that you “own the stack.” They care that it works.
You lose ecosystem benefits
Vendors come with:
- integrations
- connectors
- partner ecosystems
- talent pools (people who already know it)
Internal tools create bespoke interfaces that your other systems have to special-case. That’s how you build a brittle architecture that only your org understands.
You muddy your strategy and your story
If you rebuild everything, it becomes unclear what your company is actually about.
Are you:
- a payments company
- an analytics company
- an internal tooling company
- a security platform company
The more NIH you tolerate, the harder it is to maintain focus, narrative, and execution. Who loses? Customers and shareholders alike.
You make M&A and partnership harder
Standard tools = “easy to understand” and “easy to integrate.”
Homegrown everything = “this will take longer than we thought.”
Even if you’re not optimizing for acquisition, you are optimizing for future flexibility.
A quick rule: if it’s not a moat, it’s a tax
Here’s the simplest mental model I know:
If competitors can buy it, and it doesn’t directly create your differentiation, building it is probably a tax.
Taxes compound.
So when should you build in-house?
NIH isn’t evil. It’s just expensive. Sometimes it’s exactly right—when it’s deliberate and strategic, not reflexive.
Here are the real “yes” cases.
1) It’s core to your differentiation (your moat)
Build when it’s directly part of how you win:
- proprietary ranking/optimization
- domain-specific modeling on unique data
- workflow logic that is the product, not just enabling it
If you can buy it off the shelf and get 90% of the value, it’s rarely your moat.
2) The market doesn’t meet your constraints
Build when vendors fail real requirements:
- latency at your scale
- privacy/data residency/regulatory requirements
- deep customization that would permanently fight the vendor’s model
- unusual reliability or availability constraints
The key: you tried to buy and hit real walls—not imagined ones.
3) Your scale makes vendor economics irrational
At sufficient scale, certain costs get absurd:
- per-seat pricing at huge headcount
- usage-based pricing at massive throughput
- margin pressure from a vendor take rate
But you only get to claim this if you model fully-loaded internal cost over multiple years.
4) You need a long-term capability, not a tool
Sometimes you build because you need the muscle:
- experimentation platform
- ML platform
- internal data platform
- deployment and observability foundations
You’re investing in “how we build” as a strategic advantage. Leverage is everything.
5) You need a deeply integrated experience that vendors can’t provide
If the workflow is central to your product and:
- vendor UX fragmentation creates real customer friction
- integration overhead becomes a permanent drag
- ownership of the end-to-end experience matters
Then building can simplify the product in a way that actually creates leverage.
6) Vendor risk is existential and cannot be hedged
Build when vendor failure or pricing/terms changes could break the company and:
- you can’t multi-vendor
- you can’t negotiate acceptable terms
- you can’t tolerate dependency risk
In that world, building is a form of risk management.
A practical decision checklist (the one I wish more teams used)
Before you greenlight an in-house build, answer these honestly:
- Is this directly tied to our differentiation? What is the “moat statement”?
- If we buy, what’s the fastest path to value? Are we optimizing for outcomes or pride?
- What is the 3-year fully-loaded TCO (engineers, SRE, security, oncall, tooling, support, incident cost)?
- What’s the opportunity cost? What product work won’t happen because of this?
- What’s the bus factor? Who can operate this in 18 months when the original builders move on?
- What is the “edge case risk”? What do vendors already know that we don’t?
- What happens when requirements change? Who owns updates, migrations, and compliance shifts?
- Can we start by buying and wrapping? (Thin integration layer + option to swap later.)
- Do we actually want to run this as an internal product? Who owns it, and how is it measured?
- What is the kill switch? What conditions cause us to stop and buy instead?
These questions become even more pertinent as we enter the world of agentic AI, where nearly every technical capability addressable via computers is at risk of commoditization.
If your answers to #3, #4, and #9 aren’t clear and defensible, you’re not actually making a good decision: you’re falling into a long term commitment without a plan to get out.
Discover more from Wil Writes
Subscribe to get the latest posts sent to your email.