Which budget models work best for app feasibility studies

A feasibility study for an app is, at its core, an exercise in honest estimation. You are trying to answer whether a product can be built, whether it can pay for itself, and whether the numbers hold up under scrutiny. The quality of that answer depends less on how much budget is available and more on how the budget model is constructed. Get the model wrong and even a well-funded project heads in the wrong direction before a single screen is designed.

The budget model is the skeleton of a feasibility study, everything else hangs from it.

We see this clearly in our work on the niche trading platform, where revenue was commission-based rather than a flat fee. That single characteristic changed everything about how the feasibility model had to be built. We had to model user acquisition per month, monthly churn, average transaction frequency across a user's lifetime, the conversion rate between downloads and active revenue-generating users, commission rates, platform fees, and estimated dispute amounts. Without that structure, the one-, three-, and five-year forecasts we produced for investors would have had no credible foundation.

The model you choose signals how well you understand the product. A travel booking app, a subscription wellness platform, and a commission-based trading tool all generate revenue differently, carry different cost structures, and face different risks at launch. Applying the same budget model to all three is a bit like using the same map for three different cities. The format is familiar but the details are wrong, and you will get lost.

Why the budget model matters more than the budget figure

A budget figure tells you how much money is available. A budget model tells you whether that money is the right amount for what you are trying to build, and whether the revenue case holds up if you spend it. These are different questions, and only one of them is worth spending time on at the feasibility stage.

We have encountered competing agency quotes that were so low they raised immediate questions. Upon looking more closely, it became clear those agencies had asked very few questions before quoting. They were pricing to secure the work, not to reflect what the work would actually involve. The figure looked attractive. The model behind it was empty. Projects quoted that way do not stay at that price, because the estimate was never grounded in a real understanding of scope to begin with.

The budget figure also has a way of anchoring thinking before any real analysis has been done. Clients arrive with a number in mind, often gathered from a few informal conversations, and that number then shapes every subsequent decision rather than the other way around. A feasibility study exists to test whether the number is right, not to confirm it.

What a model does that a figure cannot

A model shows the relationship between cost, scope, and revenue over time. It lets you run scenarios, adjust assumptions, and see which variables carry the most risk. A figure standing alone cannot do any of that. Two projects with identical budgets can have completely different risk profiles depending on what the money is buying and what the revenue case depends on.

The main budget models used in app feasibility studies

There are three broad approaches used in app feasibility work, and most real projects end up drawing on more than one. Each has a different starting point and a different set of assumptions, which makes the choice of model a decision about where you are most confident in your data.

• Top-down modelling starts from total addressable market size and works inward to revenue share
• Bottom-up modelling starts from the specific features and resources the product needs and builds the cost from there
• Revenue-based modelling starts from how the product actually earns money and works backward to what the build must cost to make the economics viable
• Benchmarking uses comparable products as a proxy when direct data does not exist

In practice, a sound feasibility study uses at least two of these and cross-checks one against the other. A bottom-up cost model paired with a revenue-based projection is a common and sensible pairing. Benchmarking usually supports the revenue side rather than the cost side. Top-down models are more useful for investor conversations than for internal planning, but they have a place when the market data is solid.

The worst feasibility studies we review tend to rely on a single model applied without checking its assumptions against anything else. A standalone top-down projection with no bottom-up cost anchor is particularly common, and particularly misleading.

Top-down models: when they are useful and where they mislead

A top-down model begins with the total size of a market and then estimates what share a new product might realistically capture. If the addressable market for a fitness app category is £500 million and the model assumes a 2% share, the projected revenue is £10 million. The logic is clean, which is part of why it is so widely used in investor decks.

The problem is the share assumption. New apps typically capture only 0.1 to 1% of their addressable market in the first year, according to AppTweak, whereas founders and early-stage teams regularly assume 5 to 10% in top-down calculations. That gap between assumption and reality is not a rounding error. It changes whether the business is viable at all.

Top-down models make ambitious numbers look reasonable by hiding the share assumption in plain sight.

Where top-down models are genuinely useful is in framing the scale of opportunity for investors or for internal alignment on whether a market is worth entering. They are a macro sense-check, not an operational plan. The mistake is treating them as the primary model for a feasibility study rather than as one lens among several.

Where top-down modelling breaks down

Top-down models have no mechanism for capturing the specific characteristics of a new product entering an established market. They cannot account for how a cold-start problem will affect early acquisition, how churn will behave in the first six months, or how a commission-based model changes the relationship between user numbers and revenue. For commission-based products in particular, a top-down market share figure tells you almost nothing about actual earned revenue.

If you are using a top-down model, always pair it with a bottom-up cost estimate. The top-down figure frames the opportunity; the bottom-up figure tells you whether you can afford to go after it.

Bottom-up models: building costs from what the product actually needs

A bottom-up model works from the specific requirements of the product outward. You list the features, estimate the development time for each, apply the relevant rates, and sum the result. It is the most direct method for estimating build cost, and when the scope is clearly defined it produces the most reliable numbers.

Development is consistently the largest single cost driver in mobile app projects, typically accounting for 50 to 70% of total spend according to Create Anything, 2025. A bottom-up model makes that visible. You can see exactly which features are driving cost, which means you can make informed decisions about what to include in an initial release and what to defer.

On the football-focused social media app we worked on, the client wanted a streamlined MVP release but had a budget that did not match the premium experience they expected. A bottom-up estimate made the gap visible early. We had multiple conversations about which features were essential for launch and which could come later, but the client chose to allocate budget to areas we considered lower priority. The project did reach a completed product, though with feature compromises that a clearer initial model might have avoided.

The limits of bottom-up modelling

Bottom-up models are only as good as the scope they are built on. If the scope changes, the model changes with it, and the original estimate becomes a historical artefact rather than a useful guide. This is the central tension in bottom-up modelling, and it is the reason scope discipline matters so much when this method is used.

Build your bottom-up model against the minimum scope needed for launch, not the full product vision. That gives you a credible baseline and a clear picture of what each additional feature actually costs.

Revenue-based modelling for commission and transaction-driven apps

Some apps generate revenue in ways that make simple flat-fee or subscription modelling inadequate. Commission-based and transaction-driven products require a different approach, because the relationship between user activity and earned revenue is non-linear and depends on a chain of connected variables.

On the niche trading platform, we had to model user acquisition per month, monthly churn, average transaction frequency across a user's lifetime, the conversion rate between downloads and active revenue-generating users, commission rates, platform fees, and estimated dispute amounts. Each of these variables influenced the others, and a change in any one of them could shift the five-year forecast significantly. That is a materially different exercise from projecting subscription revenue, where you multiply subscribers by a monthly fee and adjust for churn.

Revenue-based modelling asks the product to prove itself from its own earning mechanics before a line of code is written. That is its real value in a feasibility study. If the model cannot produce a viable revenue projection under realistic assumptions, no amount of additional investment changes that fundamental problem.

Building the variable chain

The key is to make every variable in the model explicit and to agree on the assumptions behind each one. For the trading platform, we built the projection so that any of the input variables could be adjusted independently, which let us show investors a range of scenarios rather than a single forecast. A best case, a base case, and a stress case built from the same model are far more credible than one optimistic projection dressed up as a plan.

Benchmarking against comparable products when no direct data exists

When a product is genuinely new in its category, there is no historical data to draw from. Benchmarking fills that gap by using comparable products in adjacent markets as a proxy for what realistic performance might look like.

To validate the revenue forecasts for the niche trading platform, we analysed the market for products performing some aspects of what the platform would do. We used their revenue and subscription models as a baseline, then adjusted upward or downward depending on how established those products already were. Where a comparable product already had strong traction, we scaled our projections down significantly to reflect the reality of launching a new product into that same space. A new entrant cannot assume it will perform like an established one, and a model that implies otherwise will not survive contact with a careful investor.

Benchmarking is most useful on the revenue side. Cost benchmarks are harder to trust because they depend heavily on team composition, geography, and the specific technical decisions made during build. A revenue benchmark drawn from a product with a similar model and a similar market is a reasonable starting point, but it must always be treated as a floor or ceiling rather than a target.

Adjusting for launch position

The adjustment for launch position is where benchmarking goes wrong in feasibility studies. Teams benchmark against a successful comparator and then apply its performance metrics to a new product without scaling them down for the cold-start reality. The benchmark is used to make projections look achievable rather than to test whether they are. Using a comparator's numbers as a ceiling rather than a target produces a more honest model.

Why scope assumptions are the weakest link in any model

Every budget model rests on a scope assumption, and scope is the variable most likely to change between feasibility and build. A model built on one set of assumptions does not automatically update when those assumptions shift. The gap between original scope and delivered scope is where most budget overruns live.

The sports club app project is a clear illustration of this. The client rejected an incremental release strategy from the outset. Despite our advice to launch with a single sport, a single platform, and an MVP approach, the client insisted on launching everything at once. What should have reached market in three to four months never launched after twelve to fourteen months of development. The budget almost doubled. Every one of those outcomes was forecast and communicated early. The scope assumption in the original model was never the problem. The problem was that the scope assumption was discarded and replaced with a much larger one, but the project structure did not change to reflect it.

We warned them early on that the budget would get wildly out of control and that they were in danger of ending up with a product that was never ready to launch. Unfortunately, that is exactly what happened. They burned through the entire budget adding feature after feature and never got anything on the app store.

Scope creep and the model

Scope creep does not usually arrive as a single large decision. It arrives as a series of small ones, each of which seems reasonable in isolation. A budget model built during feasibility has no defence against this unless it includes a mechanism for tracking scope changes and their cost impact. Without that, the model becomes irrelevant as the project progresses, and teams lose their reference point for whether they are still on track.

The cost of locking a model too early

There is a version of rigour in feasibility work that tips into rigidity. Locking a budget model before enough is known about the product creates a false sense of certainty. Teams then make decisions in service of protecting the model rather than in service of building the right product.

On the dating app project focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component and focus solely on the onboarding process. Skipping that discovery meant the messaging feature that was built was a generic one that allowed automated and fake messages, which directly contradicted the core premise of the product. The entire messaging section had to be rewritten. That cost approximately £15,000 in additional budget and two months of extra work. The decision to skip discovery had been a budget decision, an attempt to protect the original model. It ended up costing more than the discovery would have.

Treat the feasibility model as a living document through the early phases of a project. A model that absorbs new information is more useful than one that resists it.

Locking a model too early also creates problems on the bootstrapped social football platform we worked on. The client originally planned to launch on both iOS and Android. As scope increased and design kept changing, budget became critically strained. Midway through the project, we made the decision to pause Android development and reallocate all remaining budget to the iOS product. The client launched iOS only, which addressed roughly half the potential market. That outcome was not in the original model. A model with more flexibility built in would have flagged the Android risk earlier and allowed a more deliberate decision rather than a forced one.

Aligning budget model to launch strategy

The budget model and the launch strategy should be designed together, because each one constrains the other. A phased launch strategy requires a model that accounts for multiple spending cycles and multiple revenue ramp-up periods. An all-at-once launch requires a model that front-loads both cost and risk.

The sports club app project showed the consequences of a misaligned launch strategy in the most direct way possible. The all-or-nothing approach meant there was no intermediate milestone at which the product could have been tested, revenue could have begun, or the budget could have been reassessed. Every pound was committed to a product that never shipped. A phased model would not have guaranteed success, but it would have created decision points at which the direction could have changed.

On the bootstrapped social football platform, the iOS-only launch was in a sense a form of phasing, though it arrived under pressure rather than by design. A model that had anticipated the Android scope risk from the start could have built a deliberate phase one and phase two structure, with Android as a funded second release rather than a casualty of budget strain.

Revenue timing and the launch model

Launch strategy also affects when revenue begins, which directly affects whether the financial model is viable. A product that launches with a narrow feature set may begin earning sooner than one that waits for full scope. A feasibility model that does not account for revenue timing, and the cash position during the pre-revenue period, is missing one of the most important variables in the whole exercise.

What a credible feasibility budget model should produce

A feasibility model that has been built properly produces more than a number. It produces a set of outputs that allow a team, a founder, or an investor to make a real decision about whether to proceed and on what terms.

The trading platform feasibility work produced all of these. The multi-variable revenue model meant we could show investors what happened to the five-year forecast if churn was higher than expected, or if the conversion rate from download to active trader was lower. That kind of transparency builds credibility precisely because it acknowledges uncertainty rather than hiding it.

A model that produces only a single number is a wish dressed up as analysis, and a careful investor or a sensible internal team will see through it quickly.

Conclusion

Choosing the right budget model for an app feasibility study is a decision about honesty. A top-down model can make a speculative market share assumption look like a revenue plan. A bottom-up model built on unstable scope can give false confidence about a cost estimate. A revenue-based model that does not account for churn, dispute rates, and conversion will produce projections that look credible but collapse under scrutiny.

What the trading platform work, the sports club project, and the social football platform all have in common is that the model was only as good as the discipline behind it. Where the discipline held, the model produced useful outputs. Where it did not, the consequences were measurable in months of wasted development time and tens of thousands of pounds in avoidable additional spend.

The projects that go well tend to combine a bottom-up cost model with a revenue-based projection, benchmarked against comparable products where direct data is thin, and tied to a launch strategy that creates real decision points rather than committing everything to a single outcome. That combination does not eliminate risk. Nothing does. But it means the risks are visible, named, and factored into the decision rather than discovered after the budget is gone.

If you are at the feasibility stage of an app project and want to build a model that can actually be trusted, let's talk about your feasibility study.

Frequently Asked Questions