4

Suppose a SaaS product charges per project, whereby the first project you own is free. Ideally, users would open up a project and invite a few members to work on it. If more projects are needed, the same user within a team would open up another project which then is charged for.

Ideal Scenario

With above restrictions, nothing would stop a team from rotating project ownership to make use of the free project per user, effectively gaining n free projects for a team size of n members.

Loophole exploited

What criteria could you use to detect such a scenario and how could you fix it?

Things I've thought of

  • You can only be member of at most one "free" project. That's hard to enforce because you can't really label any project "free" or "paid" if you charge for n-1 projects. Which one is the "free" one?
  • Reserve certain permissions for the project owner only. That's not feasible either because in the context of large organisations, there should probably be multiple members with full access.

closed as off-topic by amon, Jörg W Mittag, Blrfl, 8bittree, Eric King Aug 15 '18 at 22:55

  • This question does not appear to be about software engineering within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    "Which one is the "free" one?" The first one established in time, perhaps wherefore with the lowest ID. – Mike Aug 14 '18 at 19:17
  • 5
    I'm voting to close this question as off-topic because it's about legal concerns or business strategies. It is not about a software engineering problem. – amon Aug 14 '18 at 19:54
  • 3
    @amon It's about the right model design to prevent the situation above. Neither the pricing strategy nor legal matters are subject of the question. Please leave it open. – Double M Aug 14 '18 at 22:22
  • 3
    @DoubleM Ironic how the answer you accepted was all about pricing strategy and legal matters. – R. Schmitz Aug 15 '18 at 17:23
  • 1
    @DoubleM I see where your confusion comes from - the implementation would be done with code. The thing is that the code only models the business decisions. The business says "we want 3 licenses per group" and then the code only has to reflect that (and it wouldn't be particularly difficult to code). If the business has to decide on selling pants vs selling tooth brushes, the decision will also need to be programmed for the web shop, but that doesn't make it a decision for the lead programmer. – R. Schmitz Aug 16 '18 at 13:00
8

Change the model to "one free project per organization". Apparantly that is what you really want, and the identity of organizations can be checked to some degree of certainty by things like tax ID, official website/URL and similar properties.

For individuals who don't want to register to your service as an organization, you may offer to use your service with just one member (themselves) per project, or with a very limited number of users per project. It depends on the precise nature of the service how useful or sensible this is.

Moreover, you should primarily protect yourself against abuse of the pricing model legally, by writing this into your "terms of service". Technical measures should be only supporting this. So even if someone finds a technical loophole, they will probably hesitate to make use of it because of the risk of getting excluded from your service or getting sued.

  • Thanks for the advice - that would basically require every user who wants to try the product to have access to details of an organization which is a legal entity, or at least has a website, right? That would probably impose a higher barrier for people to get started, or even be impossible to achieve for individuals. I was hoping to grant one project per account, but with some kind of lock that would snap in above scenario. I do appreciate your advice about the ToS! – Double M Aug 14 '18 at 16:58
  • @DoubleM: you could allow individuals to use your service with just one member (themselves) per project, and allow teams only when registered as an organization. However, it is hard to give you a better advice without knowing more about the precise nature of the service, how interesting/ important/useful it is to individuals, teams and/or organizations. – Doc Brown Aug 14 '18 at 17:33
  • Limiting the amount of members on a free project might just nail it. If you allow a maximum of e.g. five members, a closed group can never go beyond five free projects. – Double M Aug 14 '18 at 22:37
3

First of all maybe it's nothing wrong with your pricing model.

Considering that you are offering a "free trial" like every other SaaS out there, I don't see anything wrong. Any SaaS can have this issue where they could theoretically create infinte accounts just to get unlimited free service.

That's not how business is done with this type of thinking. Don't think about this from a mathematical point of view. think of it from a social point of view. Add different kind of constraints to keep the good customers in.

Constraints similar to what @Doc Brown said. Ask them for CC data, or ask them to give you a call (many ask for a call to give the customer a quote), ask for identitification (company details or whatever), ask them to verify the phone number and send them a code for a free project. In my opinion you should put "social/marketing" type of constraints for this. You can even put some kind of firewall and monitor abuse of the free part of your service.

There are plenty SaaS platforms out there from which you can get some inspiration. Steal the ideas from the big SaaS platforms out there. Their marketing team surely knows many things, tried and tested strategies.

  • That is certainly another perspective to look at it. I'll let it sink in, thank you. – Double M Aug 14 '18 at 22:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.