How Do You Sell to a Buyer Who Already Built an Internal Tool?

How do you sell to a buyer who already built an internal tool?

Respect the tool, then make the hidden cost visible. Acknowledge that the internal build solved a real problem, show what it costs to maintain and what it cannot do as the team grows, and offer a migration path that keeps their work. Attacking the tool attacks the person who built it, who is often in the room.

In B2B SaaS, your most stubborn competitor is often not another vendor. It is a spreadsheet, a set of scripts, an Airtable base, or a small internal app that someone on the buyer's team built two years ago. It works well enough. The builder is proud of it. And it costs nothing on the invoice, which makes it very hard to replace.

This article covers how I would position a SaaS product against an internal build, from website messaging to the sales conversation, without insulting the people who made it.

Why is an internal tool such a hard competitor?

Because it is free on paper, fits the team's exact workflow, and has an internal champion who built it. Switching means admitting it has limits, retraining the team, and moving data. Each of those is a real cost, and the internal tool wins by default if you do not address them directly.

The internal tool also has a credibility advantage. It was built by someone who understands the business deeply. Your product, by comparison, is generic. The buyer's instinct is that a tool built for them must be better than a tool built for everyone, and on day one that is often true.

What the internal tool usually lacks is a future. It depends on one or two people, it has no roadmap, it breaks when other systems change, and it rarely gets security reviews or documentation. Those weaknesses are invisible until they become urgent. Your job is to make them visible early, without being alarmist.

What should you never say about the internal tool?

Never call it a hack, a workaround, or a mess, and never imply the builder did a poor job. The builder is often your champion, your evaluator, or their boss. Insulting the tool makes them defend it, and a defensive builder will find every reason your product is worse.

The better framing is graduation. The internal tool did its job when the team was smaller or the process was simpler. Now the team has grown, the process has more steps, and the tool is being asked to do things it was never designed for. That story honors the builder and opens the door to change.

I would go further and invite the builder in. Ask them what they would add to the internal tool if they had time. Their answer is usually a list of the exact features your product already has. Now they are describing your value in their own words, which is far more persuasive than anything you could say.

How do you make the hidden cost of an internal tool visible?

Ask about the time spent maintaining it, the people who know how it works, what happens when they are on vacation, and the last time it broke. Those questions surface costs the buyer already feels but has never added up. Let them do the math rather than presenting it.

Maintenance time is usually the biggest hidden cost, and it is often spread thinly across several people. An analyst fixes a formula. An engineer patches a script when an API changes. An ops lead manually cleans data every Friday. None of it shows up in a budget line, but together it can add up to a meaningful share of someone's week.

Key-person risk is the other big one. If the tool depends on one person, the business has a single point of failure in a process that matters. Asking what would happen if that person left is not a scare tactic. It is a question a responsible manager should be able to answer, and many cannot.

How should your website address build versus buy?

Write a page or section that speaks directly to teams who built their own solution. Acknowledge the reasons they built it, explain where internal tools typically hit limits, and describe how your product handles the transition. Buyers searching for alternatives to their spreadsheet should find a page that understands them.

Most SaaS websites only compare against named competitors. That misses a large group of buyers whose real alternative is doing it themselves. A page titled something like moving from a spreadsheet or internal tool to your product, written in the buyer's language, meets them where they actually are.

The page should be honest about tradeoffs. Internal tools are more flexible in some ways, and pretending otherwise loses trust. Say what the buyer gives up, and why most teams decide the trade is worth it. I took a similar honest approach to migration content in how to write a migration guide that wins switchers.

How do you handle the migration question?

Show exactly how their data and workflows move into your product, and offer to do the heavy lifting. The fear of losing two years of accumulated logic is often the real blocker. A clear migration plan, ideally with a mapping of their current fields and steps to your product, removes that fear.

Ask for a look at the internal tool early, if the buyer is comfortable sharing it. Seeing the real structure lets you show how each part maps to your product, which parts your product does better, and which parts need configuration. That specificity is far more convincing than a generic demo.

Be honest when something will not map cleanly. If the internal tool has a custom rule your product cannot replicate, say so and offer an alternative. A buyer who catches you overselling the migration will assume you are overselling everything else.

What does a good ROI argument look like here?

A good ROI argument compares the real cost of the internal tool, including maintenance time, risk, and missing capabilities, with the subscription cost of your product. Use the buyer's own estimates wherever possible. A number they gave you is far more credible than a number from your marketing team.

Keep the model simple. Hours spent maintaining the tool each month, multiplied by a reasonable loaded cost per hour, is a starting point. Add the cost of known incidents and the value of capabilities the team wants but cannot build. Then compare that with your price over a year.

Do not inflate the inputs. If the honest math shows the internal tool is cheaper, the buyer may still switch for risk or capability reasons, and you should argue on those grounds instead. I covered how to build numbers a finance team will accept in how to write an ROI page a CFO will believe.

When should you walk away from a build-versus-buy deal?

Walk away when the internal tool genuinely fits the buyer's needs, the team can maintain it comfortably, and your product would add cost without solving a felt problem. Not every internal tool needs replacing. Forcing a sale here creates a churn risk and a frustrated customer.

The signal to watch is pain. If nobody on the buying team can name a recent problem caused by the internal tool, there is probably no urgent reason to switch. You can stay in touch, share useful content, and check back when the team grows or the process changes.

Walking away well also builds credibility. Telling a buyer honestly that their current setup is fine for now, and explaining what would change your view, positions you as an advisor. When the internal tool does start to strain, you are the first vendor they call.

How does this change your GTM motion?

It means treating do it yourself as a named competitor in your positioning, sales playbook, and content. Track how often deals involve an internal tool, how often you win them, and why you lose. That data shapes messaging, pricing, and even product priorities.

In your CRM, add a competitor value for internal tool or spreadsheet, so these deals are counted rather than lost in an other category. Over a few quarters, you will see whether build versus buy is a minor issue or one of your biggest sources of lost deals. Either answer is useful.

On the product side, the patterns in lost deals often point to missing flexibility. If buyers keep choosing their internal tool because they need one custom rule, that rule might be worth building. The internal tool is a competitor, but it is also free product research.

What should you do next?

Add internal tool as a competitor option in your CRM, write a short discovery script that surfaces maintenance cost and key-person risk, and draft a website section for teams moving off a spreadsheet or in-house build. Then review your last five lost deals for build-versus-buy patterns.

Above all, coach your team to respect the builder. The person who made the internal tool understands the problem better than anyone, and turning them into an ally is the fastest way to win the deal.

I help B2B SaaS teams shape positioning and the GTM systems behind it. If build versus buy keeps costing you deals, reach out and let's chat.