How to Build a Business Case for Mobile Development That Your CFO Will Approve

Most mobile development proposals that get rejected by a CFO are not rejected because of the cost. They are rejected because the person presenting the proposal has not answered the three questions a CFO needs answered before approving any capital allocation.

Those three questions are: what is the specific outcome, how do we measure it, and what happens if we do not do it. A proposal that cannot answer all three clearly does not survive the first review meeting, regardless of how well-reasoned the technical approach is.

Three reasons proposals get rejected

The outcome is described, not measured. "Improve user experience," "increase efficiency," "modernise the app" are descriptions of direction, not outcomes. A CFO approves outcomes with numbers attached: the customer support contact rate drops from 18 percent to 11 percent, the field technician documentation time drops from 45 minutes per job to 12 minutes, the payment completion rate increases from 76 percent to 91 percent. Without the number, the proposal has no way to be evaluated after the project ships.

The cost of inaction is absent. Most proposals focus exclusively on the cost of doing the project. A CFO evaluating a capital allocation also needs to know the cost of not doing it. What does it cost to leave the current situation in place for another 12 months? Lost revenue, operational drag, compliance exposure, competitive position? A proposal that only shows the cost of action without the cost of inaction gives the CFO no way to evaluate the urgency.

Vendor risk is unaddressed. The most common reason mobile projects run over budget is that the vendor was selected for capability without a delivery track record. A CFO who has seen a project run 80 percent over estimate will ask, before approving the next one, how this vendor is different. If the proposal does not address vendor risk — through references, prior work at the relevant complexity, or a capped risk structure — the CFO is approving a number that may not hold.

The CFO frame

A CFO reads a business proposal through a single lens: is the expected return, risk-adjusted, worth the capital and the opportunity cost?

Every element of the proposal is evaluated through that lens. The outcome section establishes the return. The cost section establishes the capital. The risk section establishes the adjustment. The timeline establishes when the return materialises. A proposal that is missing any of these four is incomplete from a CFO's perspective.

The mistake most proposers make is leading with the technical solution — what will be built, what technology it uses, how it integrates with existing systems. None of that belongs near the top of a CFO presentation. It belongs in an appendix if it needs to be there at all. The CFO's questions are business questions. Answer the business questions first.

The five elements of an approved proposal

Element 1: The problem in one sentence and the current cost.

State the problem specifically and quantify its current cost. "Field technicians spend an average of 40 minutes per job on paper documentation. At 200 jobs per day, that is 133 hours of lost productivity daily. The annual cost at the average field technician rate is $1.4 million in non-billable time." The CFO now understands the problem, its scale, and why it has a dollar value.

Element 2: The proposed solution and what it produces.

Describe the solution in one or two sentences, then state the expected outcome with a number. "A mobile job documentation app reduces average documentation time from 40 minutes to 8 minutes per job. At current job volume, this recovers 100 hours of productive field time per day, with an annual value of $1.2 million." Do not describe the technical approach. Describe the output.

Element 3: The cost of the investment.

State the total investment clearly: development cost, ongoing maintenance, and infrastructure. Break it into the first-year total and the recurring annual cost. Show the payback period: at $1.2 million in annual value, an $800K development cost and $120K annual maintenance produces a payback in 8 months and an annual net benefit of $1.08 million from year two.

Element 4: The cost of inaction.

Quantify what happens if the project does not ship. "Continuing the current process costs $1.4 million per year in non-billable technician time. Deferring the project one year costs $1.4 million in recoverable productivity. Deferring two years costs $2.8 million." This reframes the capital allocation. The question is not "should we spend $800K on this app?" It is "should we spend $800K now or accept $1.4 million in annual avoidable cost?"

Element 5: Vendor risk and mitigation.

Name the vendor, state their relevant prior work, and describe the risk structure. "The vendor has delivered four field operations apps of comparable complexity. We have spoken to two of their clients. The engagement uses a retainer model with monthly delivery milestones, limiting budget exposure to monthly increments." This section is where most proposals fall short. Address it directly.

What not to include

Technical detail in the main document. Platform choices, architecture decisions, integration approach — these belong in an appendix. A CFO who needs to understand the technical approach will ask for it. One who does not will read past it, and the length of the technical section signals that the proposer does not understand their audience.

Projected outcomes without stated assumptions. A revenue projection or cost saving without the assumptions behind it is a number with no basis. State every assumption explicitly. A CFO will test the assumptions. If they hold under testing, the proposal gains credibility. If they do not, the CFO will have found the weakness before approving — which is the outcome you want, not the outcome you want to avoid.

Competitive pressure as the primary justification. "Our competitors have this" is a weak business case unless the competitive pressure is specific and quantified. Generic competitive urgency is easy to dismiss. Specific competitive impact — "Competitor X launched a comparable app in Q3 and our retention in the overlapping segment dropped 14 percent in the following two quarters" — is not.

The single page version

A CFO who has limited time will read one page. That page should contain:

The problem in one sentence and the current annual cost. The proposed solution and the expected outcome with a number and a payback period. The total investment and the recurring annual cost. The cost of inaction per year of deferral. The vendor's relevant track record in two sentences.

Everything else — technical detail, vendor evaluation criteria, project timeline, risk register — is available in the appendix if asked for.

The single page does not need to be convincing on its own. It needs to be clear enough that the CFO knows what they are evaluating and can ask the right questions. The questions are where the case is made or lost. The single page gets you to the questions.