B2B App Revenue Models

One of the the most important considerations for developing any app are how the app will generate revenue for the developer.

There aren’t any rules about what your app’s revenue model should look like. There are many available and what’s important is that it works for you and your customer.

In this post I will focus on business-to-business models, not consumer-facing models. The latter are (I believe) MUCH harder to implement effectively, and you will be up against the big guys (Google, Facebook etc.) who are all vying for your consumer’s finite attention span.

Before we look at some of the revenue models I’ve come across, it’s worth first looking at the underlying assumption:


Are you selling an app or a service?

You should be looking to provide a service. Businesses pay for value and they value a service. Think of it this way by answering the question: “What service are you providing?”.

Step 1: For me, the test of what your service is, is to think of how you would provide that service if you didn’t have the app. How would you solve your customer’s problem? It would probably take the form of a call centre, staffed day and night, 365 days a year – with all your staff working from spreadsheets, documents and making lots and lots calls!

Step 2: Ok, so can you described what service you are providing if you DIDN’T use an app? That’s an important step in realising that your app is just a tool – it’s just the MEANS of providing a service. So, what’s the advantage of using your app? For starters, it means your business can be much more profitable because you don’t have a lot of overhead to cover. Maybe you have a major competitive advantage against other businesses that are providing the same service, but without all the benefits that are inherent to your app-driven model. Your baseline costs are lower, which means that you can bring the price of the service down to whatever price point your customers are willing to pay for that service. If you don’t need to bring it down at all, even better.

Ok, so now you have a good profit potential, or you are able to provide services that businesses find are worth solving when you are able to bring the cost of solving them down.

Step 3: Next question: “Why is your app better than using WhatsApp groups and shared Dropbox drives?”. At first you might feel the blood drain from your face, your mouth go dry and you think: “*Gulp* Um, I don’t know – those are fine and they are free – my app is worthless :’( ”.

But hold on, think about how people use these others tools – what are the problems?

Here’s some:

  • Poor / no links to central database – no version control and multiple versions of the same document
  • Users can change data, delete data, mess up data, steal data etc.
  • No standardisation of processes
  • Poor managerial oversight
  • Chaos


If none of that particularly matters to your potential customers – then I suggest you rather provide solutions to problems where these things do matter! And believe me, there are plenty out there.

Ok, so now you understand A) What service your app is providing and B) Why an app is the right tool to solve it with.


Now let’s look at a few models:

1. Distribute the app for free and sell advertising space

Stay away from this! It’s tempting because it sounds easy and probably soothes fears you have about the value of your service. Incentivising users points to a value-proposition problem that is not sustainable. If people aren’t willing to pay for your service – at some point – then you will be in a perpetual battle with ever decreasing revenue. Starting down this path is putting your whole revenue model on shaky ground. Ad-based revenue is notoriously difficult to build sustainably and you will be in a race to the bottom. Who does your customer become? Not your users, whose problems and values you understand. Your customer becomes your advertisers , who only have one goal – reach more people for less money. At the drop of a hat (or some algorithm), your customers will switch to a cheaper provider. Ads also make for a terrible user-experience, but this you already know.


The only caveat I will provide is that ad revenue might make up an ADDITIONAL income stream over and above subscription fees or similar. I won’t provide any more caveats, lest you think that some super-niche, highly-unlikely situation that I describe fits your situation perfectly!

Here’s another insight – users that only use your service because its free are going to be nightmare customers! Lots of anecdotal evidence points to the fact that low-tier/low-paying customers require a tonne more support than higher-paying customers.


2. Charge a single development fee, with support fee

This is a more traditional model. Customer wants an app, you quote an amount to develop it. You get some portion of the payment upfront with additional payments at pre-determined milestones. Final payment at the end.

I would highly recommend you include an ongoing support fee at either a fixed price per month, or quote an hourly rate. The fixed price per month is usually better for minor fixes, re-doing a bit of stuff if the app needs updating etc.

Do not get caught in the trap of doing further development work/ tweaks and changes for no money. New requirements = new development = additional development cost.

You may be tempted to not charge a support fee to present a lower cost to the client. This is a mistake. You MUST provide support. Maybe AppSheet changes something in the platform, there will be bug fixes, new users, users lose their phone and need help re-installing the app or anything else might happen. Software is not static. It’s not something you will build once and then “set and forget”.

Things are always changing, there will always be something to do.

If you are worried about the cost being a factor, then look at offering a set monthly fee for the first couple of months to make sure the system is up and running, or just build that into the main development fee. After that, charge professional fees for work.


3. Fixed monthly fee aka Software as a Service (SaaS)

You may be very familiar with this model (it’s the one AppSheet uses as well) – customer pays a monthly fee, usually on a per-user basis, for use of the app. Most models offer a “cancel any time option” but I would only employ this is you have a wide client base all using the same app. If you are developing a customised app for a single customer (in other words, you aren’t selling the same app to multiple people) , then build in contract terms and timeframes which lock them in for a period of time – this is the only way to ensure you get a commitment from them to use the app and commit to changing their systems, whilst still compensating you for your time.

SaaS is very hot right now, but it’s by no means a panacea. For smaller companies, paying a lower monthly cost rather than an upfront fee may be attractive because it helps with their cashflow. For larger companies, they seem to prefer (from my experience) to rather have a single, larger payment because it works better with their accounting and budgeting systems. It aligns with the other services they are paying for.

Pro-tip – find out what their annual budget cycle is and then don’t get your hopes up to close the deal unless it’s near the beginning or the end of the cycle. Expect a flurry of emails at the beginning or end of a budget cycle. Try get customers who have different budget cycles.

In both cases, monthly or annual fee, be sure to build in automatic annual cost escalation, ’cause inflation! This catches many people out.

When you are a freelancer or small company, an advantage of charging an annual licensing fee, rather than a monthly fee, is that your billing requires less administration. No chasing up for payment – which is a HUGE time-sink. If you are charging monthly, set up some sort of automated recurring subscription. If customers push back – explain that you can keep your costs down because recurring billing is less admin.


4. Shared risk

I say shared risk, rather than shared-revenue, because the risk lies more with the developer than the customer. The customer is not foregoing income, whereas you, the developer, are. An example of a shared risk model may be some sort of sales app for use by the company’s sales representatives, where the customer gets the app for free and deploys and maintains it, and the developer then gets a portion of every sale the sales reps make, or paid upon some other result the app is meant to deliver. Think of it as shared commission.

This is highly speculative and you are becoming a business partner of that customer. In some cases, it may work, but if you are a sole developer who is relying on income – I would recommend you rather charge once off or recurring fees for work. You will have very little say in how the business operates even though your income depends on it. Furthermore, people love speculation and getting a developer to develop apps speculatively is free labour and they themselves are not sure on how to monetise the service or whether it will even work.

Don’t work on other people’s speculative projects – you have enough of your own to develop, I’m sure!

I’ve tried this once or twice, so I would say it’s good for building experience/confidence or if you are looking to help someone out. Go into it with the expectation that you will never see any money and then you will be ok. If you really want this – rather do it for  for non-profits whose missions you believe in – at least you will feel good helping the world if you don’t end up getting paid, which is almost certain.


There is not “only one”.

There are no rules! It’s perfectly feasible to apply all of these models at once. What’s more of a consideration is what else do your customers buy? What other models are they already familiar with and happy with? Make sure your app provides enough value by solving problems that have enough commercial benefit to the customer that makes it worth it for them and you to solve.

I still believe we are only at the VERY BEGINNING of the enterprise app boom. We are at the same stage when spreadsheet software was replacing physical ledger books and when email was replacing snail-mail. One day soon, it will be as crazy to do many things in business without apps that apps can already replace TODAY. There will be lots to of revenue models to try, to learn from, a few horror stories and many wins – for developers and businesses.

Keep experimenting, keep a cool a head and share your experiences!

Sign up to the StepSheet blog newsletter and be notified when new resources are released!
* = required field