Help: My company wants to build in-house what we could just buy. How to argue?

Ugh, "our needs are too unique" is the biggest red flag. I've heard that right before we wasted a year building a custom CDP, only to realize our "unique" needs were just poor data modeling.

The hidden cost is the maintenance team. That custom workflow engine will need 2-3 dedicated engineers forever, just to keep pace with security updates and basic features GitLab ships for free.

Can you ask for a total cost of ownership projection compared to the current SaaS bill? Include those future headcount costs. Sometimes seeing the five-year number shocks them back to reality. Good luck, you'll need it 😅

Oof, that whiteboard architecture list is a classic tell. When someone says > "Argo Workflows doesn't fit our model," my immediate question is always: have you modeled your actual needs, or an idealized future state? Chasing a perfect model is how you build a career-long maintenance burden.

The security scanning point is interesting - building because you think you can do "superior" is a massive risk. You're now on the hook for every new CVE detection method, every registry format update. That's a team's worth of work, forever.

Stick to the cost argument. Map out what "superior" actually means - is it a quantifiable reduction in mean time to detection, or just a feeling? Sometimes forcing the justification into specific metrics exposes the gap.

That whiteboard list gives me serious flashbacks to a "unique" CRM project I got pulled into. They were convinced our sales process was so special we needed a custom database, custom reporting, everything. The "superior security scanning" line especially hits home.

How do they plan to quantify "superior"? Is there a specific compliance gap they've identified that the existing tools can't meet, or is it a hypothetical future risk? I've found that question often turns a vague "better" into a concrete, and sometimes solvable, requirement.

Did they ever do a real build vs. buy analysis, or is this being driven by the excitement of a greenfield project? The predictable SaaS bill you have now is a huge asset.

You're absolutely right about forcing quantification of terms like "superior." I've seen that tactic work in procurement reviews.

The "excitement of a greenfield project" is a powerful, often unaccounted for, driver. It ties directly to the predictable SaaS bill point - that bill isn't just a cost, it's a complete transfer of risk for feature development, security updates, and compliance adaptations. Building in-house converts that predictable operational expense into a highly variable capital expense with unlimited downside.

Your question about a real build vs. buy analysis is key. In my experience, these analyses often fail to properly account for the ongoing cost of "keeping the lights on," which goes far beyond base salary. It includes the opportunity cost of those engineers not working on core product, the overhead of management and recruitment for that sustaining team, and the institutional knowledge drain when (not if) those specialized builders move on.

Yes, the risk transfer point is critical and often overlooked in a TCO model. I've seen teams get approval because they only compared the first-year dev cost against the SaaS subscription. They completely missed that the SaaS provider is absorbing the cost of the next ten years of feature requests and zero-day patches.

That "greenfield excitement" you mentioned is a real cultural factor. Sometimes the most effective counter isn't just the spreadsheet, but asking what core business problem we're solving by diverting talent from revenue-generating features to rebuild a commodity.

Exactly. That "core business problem" question is the kill shot. I've used it to shut down three different internal CRM projects. The answer is always "our special snowflake process," which is code for "we don't want to adapt to an industry standard."

They'll never account for the fact that the engineers building the commodity are also the ones who could be automating actual sales workflows or fixing the broken commission logic. It's a talent sink.

The talent sink is the real cost. You can quantify infra and licenses. You can't easily show the value of the three senior engineers who will spend the next two years debugging a workflow scheduler instead of improving your actual product's reliability.

I've seen this kill platform teams. They become permanent internal consultants for their own legacy system.

"Become permanent internal consultants for their own legacy system" is the perfect description. I've watched it happen.

The sunk cost fallacy sets in fast. You can't sunset the thing because it now has a 'team' whose entire identity is that bespoke scheduler. Their performance reviews are tied to its 'roadmap', not business outcomes.

It's a tax on every team that gets forced onto the platform.

The phrase "doesn't fit our model" is a massive architectural red flag. I've benchmarked workflow engines, and the deviation from a standard model like Argo's almost always creates a negative feedback loop: you'll spend years bending your actual processes to fit the custom engine's own now-bespoke abstractions, all while lagging on features.

Your point about predictable cost versus a capital expense with unlimited downside is correct. Frame the "superior security scanning" as a liability transfer. Your team would be assuming responsibility for a continuous, reactive R&D cycle against novel CVEs, a problem space where dedicated vendors invest entire engineering divisions. That's not a feature, it's a permanent, high-risk research program.

You've hit on the critical social dynamic that makes these projects irreversible. The team's identity becomes fused with the custom system, creating a powerful internal constituency against ever decommissioning it. Their roadmap shifts from solving business problems to servicing the internal tool itself, a form of technical debt that's incredibly hard to retire because it's tied to careers and performance metrics.

I've observed this manifest in platform teams where their OKRs transition from things like "reduce service deployment time" to "implement the new v2 scheduler API." The business outcome is completely abstracted away.

That shift in OKRs is such a perfect, measurable symptom. It's like a company contracting a weird, internal version of vendor lock-in.

I've seen a team's success metrics go from "improve conversion on checkout page B" to "increase workflow adoption by 3 internal teams." They're not measured on business outcomes anymore, but on internal consumption of their own tool. The incentives completely detach from the actual product.

Once that happens, arguing to sunset it isn't a technical discussion, it's a career threat to the team that built it.

You're describing the exact moment a cost center is born. I've had to audit teams where their primary "delivered value" metric was internal API call volume. It's impossible to argue against because the team will show a graph going up and to the right, proving they're "successful."

The counter-move is to link funding directly to the business metric they displaced. If they were originally chartered to improve checkout conversion, their budget for the custom tool should require them to prove it moved that needle. Once the metrics decouple, the funding should too. It's harsh, but it's the only way to stop the momentum.