How we calculated the price of ac;pic

How much should we charge for our product? What's the price model that makes sense to our users? We had a long discussion about it and we looked to consider all the important aspects:

  1. What price makes our product sustainable?
  2. What price are users willing to pay?
  3. What price model best serves our users?
  4. Are there disadvantages to this model?

By answering these questions, we’ll be better equipped to have a solid pricing model to begin the journey of our first product: ac;pic, a photo and video organization service.

Here's the entire process we went through.

1. What price makes our product sustainable?

There's one inescapable fact: if the product is not profitable, we can't pay ourselves and cover the costs. If that happens, there's no company, no product, no team.

We began with 2 straightforward questions:

  1. How much do we need to pay ourselves?
  2. How much does it cost to maintain the service and the company?

1. How much do we need to pay ourselves?

If we can't support ourselves, we can't make any of this happen. Conversely, if a project that we love and believe in can pay our salaries, it will grow and prosper with our full attention.

Altocode works in full transparency, which means everybody can see everything we do, we think, and how much we earn. The market shall know our salaries.

We set salary milestones for different stages of the product. You can see them here.

Our first milestone will enable us to work full-time in Altocode. That's a salary of €3,000 a month after tax, per founder. That's around US $3,500 after tax. We're a 2-person team, so that's €6,000 after tax a month.

The next question is 'how many paying users do we need to make €6,000 a month after tax?'

We built a simple table that takes into account:

ac;pic monthly paying users required

For each column of 'net income per user' we have the amount of paying users necessary to reach €3,000 of net monthly salary per founder.

The next question is, 'what should be the target amount of users for the first milestone?'

It can't be very high, otherwise it might take too long to get there and - as a fully bootstrapped company - we only have so much runway. On the other hand, we can't go for a very low number of paying users, because prices might get too high (we haven't added operating costs and taxes yet) and prevent people from becoming paying users.

In the spirit of Kevin Kelly's '1,000 true fans' article, we feel that around 1,500 to 2,000 paying users should allow us to reach our first milestone. If we can't get that amount of paying users in a few months, we have bigger issues than pricing. Still, we needed to continue our analysis to get to a price.

2. How much does it cost to maintain the service and the company?

This is where most companies make mistakes and later on experience a rude awakening. If we don't understand our costs well, our pricing could be way off (either too cheap or too expensive).

What things do we need to account for besides our net salaries? a. Income taxes on our salaries. b. Infrastructure costs. c. Product-related services: design, security. d. Business-related services: accountants, lawyers, banking. e. Working capital. f. Value Added Tax. g. Credit card processing and payments.

Let's go through each of these points in more detail.

a. Income taxes on our salaries: Altocode is based in The Netherlands (this is mainly for 2 reasons: one of the founders lives there, and the EU is a great place to start a company to steward users' data). Income taxes in The Netherlands are anywhere between 30 and 50%, depending on the tax bracket. 40% is a realistic estimation for the first stage of the business.

b. Infrastructure costs: Our service is fully based on the cloud and our main providers are Hetzner and Amazon AWS. There's a very small fixed component to this (hosting, email), but most of this cost is proportional to the amount of space used by our users. This cost will be divided in two parts: that corresponding to free accounts (which will be covered by the company) and that to paid accounts (which is paid by the users themselves as a variable cost; see below).

c. Product-related services: design, security: Neither of us is a designer or a security expert. Those skills (among others) are crucial to further develop a world-class product. We will be very happy to develop close relationships with design and security experts in the future, hence we need to account for them.

d. Business-related services: accountants, lawyers, banking: We have a basic company set up, but we will definitely need to invest in accountants & lawyers to set up a larger company structure as soon as we scale to thousands of users. Same goes for upgrading our type of bank account, as well as opening additional accounts for salaries, setting up processes to deal with invoices, etc. While these costs are somewhat fixed, it is reasonable to consider that they will grow based on the size of the business, but we expect that growth to be less than proportional.

e. Working capital: Any company, and particularly a bootstrapped startup, needs to have working capital (ie: extra money in the bank) in order to grow and withstand crises. Although we're not a profit-maximizing company (in short: we cannot sell the company, we cannot get rich from the company and, as we grow in paid accounts, we'll reduce the price per user), we need to be smart and have enough working capital to invest in the company's growth or cover any hiccups that might happen along the way. You either plan this ahead and have a good chance of overcoming most problems or deal with it later in a do-or-die situation. We rather have the former than the latter, for our own sake and our users' sake.

So, how do we take into account the infrastructure cost, product-related services, business-related services and working capital? We set a cost budget per paying user. Since all these costs are positively correlated to the size of the business, we can infer that the more users we have - especially in the beginning - the more costs we'll have to account for. Of course, these won't be linear, but in the early stages these costs can add up quickly and halt growth. As we grow we'll have to review this cost item, but now we have to ensure a solid service and business survival.

We concluded that these items combined add €2 per paying user.

An heuristic way to think about this is the following: if we have 100 paying users, it is reasonable to have about €200 of monthly expenses; at 1,000 paying users, it is reasonable to have a budget of €2,000.

f. Value Added Tax: We have to make a differentiation here.

g. Credit card processing and payments: We'll use Stripe. It's easy to use, reliable, and has great international coverage.

From Stripe we'll use 2 services:

For The Netherlands, the pricing is a little different than for the United States (you can check it out here).

These are the Stripe fees. Stripe calculates the fees over the final price (after tax). Now it gets a little tricky.

stripe fees for The Netherlands

On top of the Value Added Tax (VAT) differentiation between European and non-European users, Stripe charges us differently when processing a European card, vs a non-European card. That needs to be taken into consideration in the price.

Lastly, we decided that we'll only bill in euros. Our wages are in euros, our costs are in euros, as well as taxes. Having other currencies would complicate things for no good reason.

The price calculation

With all this information we built another table, and built the price from the net income per user, adding all the costs and taxes. We built the price from the bottom up.

ac;pic Fixed price calculation

You'll note that in the costs line (those €2 per user) we affected half of it with Value Added Tax (VAT). We're estimating that half of our costs will be affected by VAT, so only €1 of the cost per user will incur VAT.

An interesting observation (that took us a while to figure out) is that we should charge an extra amount to non-European users for the VAT incurred by those €2 per user. These services accrue VAT, but because we don't have to pay VAT for non-European users, we cannot use their payment to offset the VAT incurred by those services. Hence, we need to charge them extra to keep things fair between European and non-European users. In addition to this, this fairness ensures that both European and non-European users will be equally profitable to us.

Previously, we had circled between 1,500 and 2,000 paying users to reach our initial goal. That meant a net income per user between €3 and €4. With the numbers more clear, we concluded that our best choice is to go with €3 of net income per user.

The fixed part of ac;pic's price will be:

We need 2,000 monthly paying users to reach the first milestone.

What about the storage?

If you followed the cost breakdown you might have noticed that we haven't considered the storage cost for the paid accounts. We accounted for servers to keep the service up & running and the storage cost for free accounts, but the bulk of the cost for a photo and video organization service comes from storage.

The cost we have as of today is €0.05 per GB. We won't make any profit from storage cost. ac;pic's users will pay storage at cost. If it's cheaper for us, it will be cheaper for our users.

This cost would incur VAT, but since the underlying server costs also pay VAT at the same rate, the VATs cancel each other out. That, however, assumes that our users are European. So, a bit paradoxically, we need to add VAT to the cost per GB for non-European users. The only other thing we have to account for is Stripe's fee - since Stripe doesn't discriminate and charges based on the total.

So, considering all of the above, the price for storage in ac;pic is:

ac;pic cost per gb of storage

These prices apply to storage exceeding the free 2 GB.

So, let's say you're using 30 GB, your monthly payment would be: Fixed amount + (30 GB used - 2 GB free = 28 GB).

2. Is this a price our users will be willing to pay?

We'll see when we roll out paid accounts, that's the only way to really find out. Nevertheless, if our users - especially the early ones - only compare us to the major players in photo organization or storage in terms of pricing, it means there's little extra value to our product.

But, on the other hand, unless you need 3 TB of storage - in which case we're not your most cost efficient option at the moment -, our prices are actually cheaper for storage below 147 GB outside the EU or 156 GB inside the EU when compared to Dropbox.

3. This model serves our users

This is a fully transparent model. Our users have clarity on how we price the product, they can control how much they spend and it's clear on where their money is going.

Our own incentives and the users' incentives are 100% aligned. If we'd charge a flat fee - users pay a fixed monthly fee and they get a certain amount of GB -, then our incentives would benefit from the paying users using the least amount of storage possible. More storage is more cost, hence less profit. We would charge a reasonable-but-a-little-high monthly fee and give users a huge amount of storage at their disposal. This creates an abundance illusion. Users believe that they have a lot of space available - which is good for them-, but really don't use that much space - which is good for the company's profit. If all users used all the storage space they have at their disposal, then the company would have to raise prices. There's also another downside to this model: users who use little space are de-facto subsidizing those who use more space. Ideally, no user should have to pay for the cost of another user.

By splitting the price in 2 we align all the incentives:

Also, this creates additional positive incentives:

In the long run, the bigger we get, the cheaper the product gets: the economies of scale are distributed to our users.

It is important to mention that all the company's financials are published and available for review, which deepens our commitment to being a fully transparent company.

4. Are there disadvantages to this model?

Yes. Mainly the flat-rate bias, which is very effective - even when users know they're paying too much. A flat-rate provides certainty. Users know what to expect every month. Always the same. But, as explained above, a flat-rate has a contrary incentive between users and company.

This price model will probably be harder to bootstrap at the beginning. We're not blind to the fact that not choosing the widely used all-you-can-eat flat-rate is a clear counterpoint to what's going on in the market. But, at the same time, that's exactly the point.

Also, unless we're very good at communicating how much a user will be charged at the end of each month, it creates uncertainty. Users need to know how much they'll be charged way before the end of each cycle. Because of this, in ac;pic users can set a storage limiter, which by default will be at 100 GB. That information must be clearly displayed on the interface and with the corresponding alerts. Users have full control on how much storage they use.

Is this model the best option?

This price model allows us to generate a level of income that enables us to work on the company and not lose money. In order to have full control of transparency, user privacy, and decision-making, we have to be 100% bootstrapped. That's in the best interest of the users and the company.

And by aligning our incentives with our intentions, we make sure that we'll go a long way in order to serve our users in a stable and effective way.


Other posts about ac;pic


Back to the blog.