Your CTO wants to build custom software. The price tag is $300K-$500K. Your job is to figure out whether that number makes sense — and if it does, how to present it to the board in a way that doesn't get laughed out of the room.
Most custom software business cases fail not because the investment is bad, but because they're built wrong. They lead with features instead of outcomes. They compare against doing nothing instead of against the real alternative. And they ignore the costs you're already paying.
Here's how to build a business case that reflects reality.
Start With What You're Already Spending
Every custom software project replaces something. Maybe it's a collection of spreadsheets. Maybe it's three SaaS tools duct-taped together. Maybe it's manual labor — people doing repetitive work that software should handle.
Before you evaluate the cost of custom software, calculate the cost of the status quo. This is where most business cases fall apart — they treat the current state as "free" when it's anything but.
Direct costs are the easy part. Add up your current SaaS subscriptions, per-seat licenses, integration middleware, and any outsourced data processing. For a mid-market company, this typically runs $150K-$400K annually across the tools that custom software would replace.
Indirect costs are where the real money hides. How many hours per week do your people spend on manual data entry, report generation, or reconciling information across systems? The average knowledge worker spends 28% of their workweek on manual data management that should be automated. At a fully-loaded cost of $85K per employee, that's $23,800 per person per year in lost productivity.
Opportunity costs are the hardest to quantify but often the most significant. What revenue are you not capturing because your systems can't support it? What customers are you losing because your onboarding takes three weeks instead of three days? What decisions are you making late because your data lives in silos?
A Forrester study found that mid-market companies spend an average of $1.2M annually on workarounds for software that doesn't fit their processes. That's not a technology problem — it's a finance problem hiding in operational budgets.
The Three-Part ROI Model
A credible business case needs three components: cost avoidance, efficiency gains, and revenue impact. Present all three, but weight them by certainty.
Cost Avoidance (High Certainty)
This is the most defensible part of your business case because it's based on costs you're currently paying.
Calculate the 3-year total cost of ownership for your current stack. Include license fees, integration costs, customization fees, training, support contracts, and the IT staff time spent maintaining the patchwork. Then calculate the 3-year TCO for the custom solution: development cost, hosting, maintenance (typically 15-20% of build cost annually), and internal support.
For a $400K custom build replacing $180K/year in SaaS and integration costs, the math looks like this over three years:
Current state: $180K × 3 = $540K direct costs, plus ~$120K in integration maintenance = $660K. Custom solution: $400K build + $70K/year maintenance × 2 = $540K.
That's $120K in direct savings before you count efficiency gains. The build-vs-buy framework gets more detailed on when these economics favor custom.
Efficiency Gains (Medium Certainty)
This is where you quantify the time your team gets back. Be conservative — boards discount efficiency claims heavily, and they should.
Map the top 5-10 manual processes that custom software would automate or streamline. For each one, document: how many people perform this task, how often, how long it takes, and what the error rate is.
A realistic example: your operations team spends 15 hours per week reconciling data across three systems. Custom software with automated data flows eliminates 12 of those hours. At a blended rate of $55/hour, that's $34,320 per year. Multiply across 5-10 processes and you're looking at $150K-$300K in annual efficiency gains.
The credibility trick: present efficiency gains at 60-70% of your calculated value. Tell the board you're discounting by 30-40% for adoption friction and optimism bias. This makes your entire model more believable — and if you hit 100%, you look like a hero.
Revenue Impact (Lower Certainty, Higher Upside)
Revenue impact is speculative, so present it as scenario analysis rather than a projection.
Custom software enables revenue in ways off-the-shelf can't. Faster customer onboarding means shorter time-to-revenue. Better data means you can identify upsell opportunities you're currently missing. Automated workflows that scale mean you can grow without proportionally growing headcount.
Frame this as: "If custom software enables us to onboard clients 40% faster — which is conservative based on similar implementations — and our average client lifetime value is $50K, then reducing our 12-month pipeline by even 2 weeks across 50 clients generates $96K in accelerated revenue per year."
Don't make revenue impact the centerpiece of your case. Make it the upside scenario that sweetens a deal that already works on cost avoidance alone.
What the Board Will Ask (And How to Answer)
"Why not just buy another SaaS tool?" Because you've already tried that. Document the SaaS tools you've evaluated and why they don't fit. The most common reason: your process is the competitive advantage, and SaaS tools force you into their process. If off-the-shelf software is costing you more than it saves, that argument is already made.
"What if the project goes over budget?" All software projects carry this risk. Mitigate it with phased delivery. Phase 1 delivers core functionality at 40-50% of total budget. You evaluate results before funding Phase 2. This limits downside exposure. Include a 15-20% contingency in your budget — and tell the board you've included it. Transparency builds trust.
"What's the payback period?" For most mid-market custom software projects, the payback period is 14-24 months when you combine cost avoidance and efficiency gains. Revenue impact can shorten this to 10-14 months but don't promise it. Present the conservative case: "We break even at month 18 on hard savings alone. Efficiency gains and revenue impact accelerate that."
"Can we do this incrementally?" Yes, and you should. The days of 18-month waterfall builds are over. Modern consultancies deliver working software in 2-4 week cycles. You can start seeing value in months, not years. Present a phased roadmap: Phase 1 (3 months, $150K) solves the most painful problem. Phase 2 (3 months, $150K) extends to adjacent workflows. Phase 3 (2 months, $100K) adds optimization and reporting.
"What happens if it fails?" Define failure criteria upfront. If Phase 1 doesn't meet specific, measurable targets, you stop. Your maximum exposure is Phase 1 cost, not total project cost. This is why smart companies start with a focused first use case rather than boiling the ocean.
The Presentation Structure That Works
After reviewing dozens of successful software investment proposals, the structure that consistently wins board approval follows this pattern.
Open with the problem, not the solution. "We're spending $1.2M annually on workarounds for software that doesn't fit our business. Here's where that money goes." Show the bleeding before you show the bandage.
Present the status quo as a decision. Doing nothing isn't free. Frame the choice as: invest $400K to solve the problem, or continue spending $660K over three years to manage it. The board isn't choosing between spending and not spending — they're choosing where to spend.
Show the math, then discount it. Present your full ROI model, then apply your conservative discount. "Our model shows $450K in annual benefits. Discounted 30% for adoption risk, that's $315K — still a 14-month payback on a $400K investment."
End with the phase gate. "We're requesting approval for Phase 1: $150K over 3 months. We'll present results to the board before requesting Phase 2 funding." This removes the all-or-nothing dynamic that kills proposals.
Common Mistakes That Sink Business Cases
Comparing against perfection. Your custom software won't be bug-free, won't launch on day one at full capacity, and won't solve every problem. Compare it against the realistic alternative — your current messy, expensive, frustrating setup — not against a theoretical perfect state.
Ignoring change management costs. Budget 10-15% of project cost for training, documentation, and adoption support. The best software fails if people don't use it. Change resistance is predictable and manageable — but only if you plan for it.
Treating it as an IT project. Custom software that transforms a business process is a business investment, not an IT expense. The business owner should sponsor the project. The CFO should frame it as capital expenditure with measurable returns. IT is a partner, not the owner.
Make the Case With Confidence
The strongest custom software business cases don't sell technology — they sell the elimination of a known, quantified pain. Your board doesn't care about APIs, architectures, or development methodologies. They care about whether this investment returns more than it costs and whether the risk is manageable.
Build the case on what you're already spending. Add conservative efficiency gains. Present revenue upside as a bonus, not the foundation. Structure the investment in phases that limit exposure. And discount your projections before the board does it for you.
If you're building a business case for custom software and want to pressure-test your assumptions, book a discovery call. We'll help you map the real costs and build a model your board will take seriously.
