Most custom software projects fail, and the single variable that moves the needle the most has little to do with the tech stack, the vendor, or the timeline. It comes down to whether a mature executive is backing the work. That pattern shows up across decades of project research: success rates swing hard on sponsor maturity alone.
So what happens when the engineering leader making the case walks in alone? No CFO nodding along. No CIO to close the deal. Just a director or a VP with a laptop and a business need.
The pitch has to do the work the sponsor would have done. Below are four situations engineering leaders face when selling a build internally, along with practical tips for pitching a new idea at work that address what each one demands.
The Finance-Skeptical Room
Finance leaders don't oppose custom software. They oppose surprise. If the CFO or controller is the loudest voice in the room and no executive champion is translating the ask, the pitch has to arrive pre-translated, in the format finance already uses to approve everything else.
That means a written business case, not a slide deck of features. Spell out the problem in dollars the business already tracks, show the option set (do nothing, buy, extend, build), and put a three-year total cost of ownership next to each one. The HBR guide on business cases is a good template to steal. It forces you to name the strategic goal, calculate ROI, and price the risk before anyone asks.
Walk in with those answers written down and finance stops being the blocker. They become a co-signer.
The Room That Already Bought the SaaS
This is the harder room. Someone in it signed the contract you're now proposing to replace or wrap. Lead with "the tool we bought isn't working" and the meeting turns into a defense of that decision, and you lose.
Reframe the ask around what the SaaS was likely never scoped to do. The vendor covers the commodity majority of the work; the build covers the slice that decides revenue, retention, or margin. Two moves help here:
- Name the seam, not the vendor. Point at the specific workflow the tool can't reach: the report finance rebuilds by hand every month, the field the sales team stuffs into a notes box. Leave the vendor's name out of it.
- Show the workaround cost. Add up the hours people already spend patching around the tool with spreadsheets, exports, and Zapier duct tape. That number is usually larger than the build estimate, and it's the number that reframes the conversation.
The Room Full of Operators Who've Been Burned Before
Every operations leader carries a scar from a custom project that shipped late, blew the budget, or died on a laptop when the one engineer who understood it left. With that audience, lead with risk containment, not upside.
Pre-empt the objections you know are coming. Show a phased build with a first release in weeks, not quarters. Name the vendor or partner and explain how code ownership works: who has the repo, who can pick it up if the relationship ends. Show the test plan.
Show the exit ramp. Operators don't need to believe the project will go perfectly. They need to believe it can be stopped, redirected, or handed off without leaving a crater.
The Room Where Nobody Understands the Technical Problem
Sometimes the people who need to approve the build genuinely can't evaluate the technical merits. A retail CEO can't judge whether an event-driven architecture is the right call. A hospital COO can't score your API design. Pitching architecture in that room is malpractice.
Pitch the user, the workflow, and the outcome instead. A clickable prototype does more in five minutes than a whitepaper does in fifty pages. The Product School guide on stakeholder buy-in is right that a prototype short-circuits abstract debate.
Let non-technical leaders click through a fake version of the thing. They'll approve what they can see. Save the architecture conversation for the engineering review after the money is committed.
Every Room Rewards the Same Preparation
The engineering leaders who consistently get builds approved without an executive sponsor share a habit: they do the sponsor's homework before the meeting. They map who's for it, who's against it, and who's neutral. They pre-brief the skeptics privately, so the meeting isn't the first time anyone's heard the idea. They bring the numbers, the risk plan, and the exit ramp in writing.
None of that is technical work. It's political work, done by someone who happens to run engineering. The pitch that gets approved is the one that already answers the questions the sponsor would have asked on your behalf.
