Do the math - maybe it works in your case. I'd say a key question to ask is "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper.
When doing the math: A common mistake is to calculate the cost of "build" as SUM(compensation of developer team on the project) over the time it would take to build the thing. You should actually use SUM(business value created by developers working on the next-highest impact items on your roadmap). In a well-run business the latter should be much higher than the former.
> If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper.
If it's not a particularly complex problem, but not one that other businesses broadcast how they are solving it, it's quite possible you can solve it less expensively than finding out how other businesses are solving it.
(And, no, finding out how solution vendors tell you other businesses are handling it isn't the same as finding out how other businesses are handling it, since such a presentation, while readily available, will always distort the facts to serve the sales interests of the vendor.)
> If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper.
How does one do that? Do other businesses just tell you how they integrated? I remain highly skeptical of this. Bigger corporations especially are quick to tout their successes but hide their failures (publicly) which makes it hard to know how happy/sad these businesses are with the decisions they made.
It sounds like for your case, the answer to "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" is "yes", so you probably have to build it.
The point is to only build things that are necessary for your product, not to avoid building anything.
When doing the math: A common mistake is to calculate the cost of "build" as SUM(compensation of developer team on the project) over the time it would take to build the thing. You should actually use SUM(business value created by developers working on the next-highest impact items on your roadmap). In a well-run business the latter should be much higher than the former.