Thanks to the rise of coding agents more and more buyers have developed the conviction that they can build whatever you’re selling. Build vs buy decisions are becoming a way of life. This post covers how to stack the odds in your favor:
How to spot the signs of an internal build
Why trying to talk them out of it is the wrong approach
How to find out where the build stands
How to propose a solution that doesn’t read as a replacement
How to structure commercials to allay their fears
How to help them sell it internally
How to spot the signs of an internal build
Almost nobody says “we’re building this ourselves” in a sales call. They say other things, and the other things have a pattern:
Requests for decks and technical docs to circulate internally, with no next steps agreed
Repeated asks for features and customizations that increase the scope and push out the decision
The initial champion disappears, gets pulled into other projects, and is not replaced by a new champion
Evasive answers on success or acceptance criteria
Repeated asks for free technical input rather than commercial terms
Don’t try to talk them out of it
The standard founder response to a buy vs build is to sell why buying is good and building is bad: The software is designed for exactly this use case. You’re learning from a large customer base. You shouldn’t spend scarce engineering time on non-unique IP. You’re underestimating the cost of maintenance.
All true. All useless.