How Do I Convince My Board to Fund App Development?

How many times have you stood outside a boardroom door knowing you need to ask for a six-figure app budget, rehearsing your pitch and wondering which arguments will actually land with the people who control the purse strings? The reality of getting board approval for app development has changed quite a bit over the years, and after working with dozens of companies trying to secure funding for their mobile projects (from modest £50k builds to complex £300k platforms), I can tell you that the conversation looks nothing like it did when we started building apps a decade ago.

Board members who approved app budgets in the early days often did so based on fear of being left behind, but today they need to see clear paths to revenue or significant cost savings before they'll commit serious money

The fact is that boards have watched countless apps fail to deliver on their promises, they've seen money disappear into projects that never launched or launched to crickets, and they've become considerably more careful about where they place their bets. This means your pitch needs to speak their language from the start, addressing the specific concerns that keep project proposals from getting approved, and presenting information in a way that makes the decision feel low-risk rather than speculative. The good news is that with the right preparation and the right framing of your case, you can turn what feels like an uphill battle into a straightforward conversation about sensible business investment.

Understanding What Board Members Actually Care About

Board members typically think about three things when evaluating any investment proposal, and these apply just as much to app development as they do to opening a new office or hiring a department head. They want to know how this investment will make money or save money (preferably with numbers attached), they want to understand the risks involved and how you plan to manage them, and they want to see that you've done your homework rather than getting excited about a shiny new toy.

The mistake most people make when preparing their pitch is focusing too heavily on features and functionality, talking about how the app will work rather than why it needs to exist from a business perspective. Your board doesn't care that the app will have push notifications or a beautiful interface... they care whether those features will drive the outcomes that matter to your organisation's bottom line. If you're preparing to pitch an app to external investors rather than your internal board, you might find our guide on making your app more attractive to funders helpful for understanding what different types of investors prioritise.

• Return on investment timeline (when will we see our money back)
• User acquisition costs and lifetime value projections
• Competitive positioning and market share implications
• Operational cost reductions or efficiency gains
• Risk factors and mitigation strategies
• Resource requirements beyond the initial build cost

Building Your Financial Case With Real Numbers

Every successful app funding proposal I've seen approved has included specific financial projections, not vague statements about potential or opportunity. You need to break down exactly how much the app will cost to build (including a realistic contingency of 15-20% for scope adjustments), what the ongoing costs will look like (hosting, maintenance, updates, support), and most importantly, how the app will generate value that exceeds these costs. For detailed guidance on presenting revenue projections to investors, our article on proving your app will make money covers the specific metrics and forecasting approaches that carry weight in funding discussions.

When we worked with a retail client seeking approval for a £180k app project, their initial proposal focused on customer experience improvements and brand perception... all true but impossible to measure in pounds and pence. We helped them reframe the business case around three measurable outcomes: reducing call centre volume by 30% through self-service features (worth about £85k annually based on their cost per call), increasing average transaction value by 12% through better product discovery (worth roughly £340k based on their sales volume), and improving repeat purchase rates by 8% through loyalty features (another £200k in retained revenue). Suddenly the £180k investment with £40k annual running costs became a no-brainer that would pay for itself in less than five months.

Build a simple spreadsheet showing costs in one column and quantified benefits in another, with conservative estimates for the benefits and realistic timelines for when they'll start appearing... this single document often matters more than a fifty-slide presentation

Addressing Risk and Security Concerns Head-On

Board members have read the headlines about data breaches, privacy violations, and failed technology projects, and these concerns sit at the back of their minds when evaluating app proposals. The worst thing you can do is ignore these worries or brush them aside with vague assurances... instead you need to show that you've thought through the risks and have concrete plans to manage them.

The key is demonstrating that you've identified the potential problems before they've occurred and that you have sensible approaches to preventing or managing them, which makes the investment feel considered rather than reckless.

Showing Competitor Activity and Market Position

Nothing moves a board quite like the fear of being left behind by competitors or the opportunity to gain ground in a crowded market. When you're building your case for app investment, spend time researching what your direct competitors have done in the mobile space, how their apps are performing based on publicly available data (app store ratings, review counts, estimated download numbers), and where the gaps exist that your app could fill. Understanding whether to build features your competitors have or create something new is crucial for positioning your app effectively in the market.

I've watched funding discussions shift from sceptical to enthusiastic in minutes when someone demonstrated that three of their five main competitors had launched apps in the past eighteen months and were clearly investing in mobile as a primary customer channel

Be specific about what you're seeing in the market. Rather than saying "everyone has an app now", show actual examples of competitor apps, discuss their functionality and approach, talk about what users are saying in reviews (both positive and negative), and explain how your proposed app would be positioned against these existing options. If your competitors don't have apps yet, that's worth discussing too... is there an opportunity to be first in your market, or does the absence of competitor apps suggest there might not be sufficient demand?

Creating a Phased Approach That Reduces Investment Fear

One of the most effective ways to get board approval for app development is to break the project into smaller chunks that reduce the upfront commitment and create natural decision points throughout the process. Rather than asking for £200k to build a complete app, you might ask for £35k to complete discovery and detailed planning, then £85k to build and launch a minimum viable product, then £80k to expand functionality based on user feedback. This approach helps avoid the common trap of including too many features in your first release, which can overwhelm both development budgets and users.

1. Discovery phase (user research, technical planning, detailed specifications) - typically £25k-£50k
2. MVP development (core functionality only, single platform) - typically £60k-£120k depending on complexity
3. Initial launch and user testing period (3-6 months of real-world data gathering)
4. Expansion phase (additional features, second platform, integrations) - budget based on MVP performance
5. Ongoing optimisation and growth (continuous improvement based on user data and business metrics)

This approach means the board never needs to commit to the full budget upfront, they can see real progress and real data before deciding whether to continue, and you can adjust your plans based on what you learn in the earlier phases. The only downside is that the total cost might end up slightly higher than if you'd built everything at once, but the risk reduction usually makes this trade-off worthwhile from a board perspective. If you're exploring different funding approaches beyond traditional board approval, our guide on finding the right type of money for your app covers various funding sources and their requirements.

Presenting User Research That Proves Demand

Board members know that someone in the organisation thinks an app is a good idea (otherwise you wouldn't be in the room asking for money), but what they really want to know is whether your actual customers or users think it's a good idea. The difference between a proposal that relies on internal enthusiasm and one backed by external validation is often the difference between approval and rejection. Before committing to full development, consider testing your app idea without building anything to gather compelling user validation data.

User research doesn't need to be expensive or time-consuming to be convincing. We've helped clients build compelling cases with everything from simple surveys sent to existing customers (asking about their mobile habits and what would be useful in an app), to analysis of customer service enquiries showing repeated requests that an app could address, to interviews with a dozen customers discussing their current frustrations and needs. The format matters less than the fact that you've actually gone out and asked the people who would use the app whether they'd find it valuable. When gathering this research, it's worth considering accessibility needs early in the process - our guide on testing apps with users who have disabilities shows how inclusive research can strengthen your business case by demonstrating broader market appeal.

Include direct quotes from customers in your board presentation... hearing "I would definitely use an app if it let me check my account balance quickly without logging into the website" in a real customer's words carries more weight than any amount of internal speculation about what users might want

Demonstrating Technical Feasibility Without Overwhelming Detail

Your board needs enough technical information to feel confident that the project is achievable and that you've thought through the implementation challenges, but they don't need (or want) a deep discussion into frameworks, databases, or architectural patterns. The balance you're looking for is showing technical credibility without losing your audience in complexity. If you're planning to include innovative technology in your app, our article on testing if new technology actually helps users can help you validate these features before including them in your board proposal.

If you're working with an external development partner, having them provide a brief technical feasibility statement can add credibility to your proposal... it shows you've consulted with people who actually build apps rather than just assuming everything you want is possible within your budget and timeline.

Turning Board Scepticism Into Confident Investment

The boards that approve app funding aren't necessarily more forward-thinking or risk-tolerant than those that don't... they're simply presented with proposals that address their specific concerns in language they understand and with evidence they find convincing. Your job isn't to convince sceptical board members that apps are the future or that mobile is important (they probably already know this), but rather to show them that this specific app, with this specific budget, at this specific time, makes sense for your organisation. As you prepare for launch, consider building early interest by learning how to build an email list before your app launches, which can provide additional validation of market demand for your board.

The proposals that succeed are the ones that acknowledge the challenges and risks rather than pretending they don't exist, that present realistic financials rather than optimistic projections, that demonstrate user demand rather than assuming it, and that offer measured approaches with clear decision points rather than asking for a massive upfront commitment. After watching dozens of these presentations over the years (both successful and unsuccessful), the pattern is clear... boards approve projects that feel well-thought-through and manageable, and they reject ones that feel speculative or rushed regardless of how exciting the vision might be.

If you're preparing to make the case for app development to your board and could use help putting together a proposal that addresses their likely concerns, get in touch and we can walk you through the specific numbers and evidence that tend to work.

Frequently Asked Questions