I would consider:
- What are Fibery’s principle costs related to usage by its customers (i.e. what features, user actions, etc. use the most actual resources that have an associated real-world cost)?
- What is the pricing for the tools most similar to Fibery (as a whole, not the many it replaces) and especially what price structure do they use?
- What is the target market(s) and how confident are you of this assumption?
- What pricing will the target market users accept? (the biggest unknown, though comparison pricing gives some ideas)
Obviously there is no direct way to satisfy all of these factors, to map them all to the same output figures and pricing formula and have it make equal sense for all factors.
It is also a challenge that Fibery is somewhat unique and potentially attempts to replace so many other products. Or least can be used to replace many others. Some of the products it can replace are quite expensive, others quite inexpensive. And since it is flexible, it is not like “modules” you can charge more for, aside from specific integrations. It is more quantity/resource or special features that you can use to differentiate (SAML, etc.).
My point is that pricing Fibery is understandably difficult. 
If it costs little to let people use Fibery for free with an unlimited number of types, entities, etc., then let them. If it actually could cost the company notable resources if, say, 100k people started using Fibery for free (I know, right now you could only dream of such numbers, but let’s say big changes to make Fibery more intuitive are really successful 
), then consider some high but useful limits there on the Free version. I know Notion tried this then abandoned it, but A: they are in hyper-growth mode and have tons of funding and B: their market is definitely different and their strategy too, they rely heavily on user-to-user promotion, aesthetics-driven marketing, etc. To enable these they needed no limits, I think, and could afford it (well, sort of - what about those performance problems? 
) due to funding.
All that said, my particular take on it:
- I agree with the basic free version limits, but suggest as above some possible resource-based limits as well (e.g. X number of max Entities or Types, etc.)
- I like @rothnic 's idea of a cheap plan for personal use that removes some of those limits. Integrations still seems less important for these users, so limits on that are OK. Arguably rules and reports should maybe not be limited, though I know they become a perf issue, potentially. Limit on audit history makes some sense to me though.
- I agree with simplification, and I think you should consider that true Enterprise-level user needs may not be so easily or fully met/satisfied by a “tier” for them. Many companies do “Enterprise: contact us” and probably for good reason and, after all, you are a “high touch” company by nature. This gives you a chance to figure out their needs, perhaps some sense of budgets, etc. If a 1000 person company is interested but does not want to pay $13,000/mo or even $8000/mo because many users will only e.g. occasionally edit data, but they need SAML, maybe you are willing to offer them $6k/mo for 1000 users, knowing their expected usage patterns. So you get a $6k/mo customer instead of a $0k/mo, because you were able to understand their large-scale needs and make a deal. Maybe?
- Team tier looks good with 30 days audit history, but I disagree with rule limits, though again I understand it could be a resource issue. I think it would be better to not have such limits there, and instead do analytics to see how much people actually use. If many people actually use over 100, then maybe this is something you can (or even must) charge for, but if in practice most do not use 100 or more, then putting the limit there just turns people off for no good reason.
- Limits on use of integrations is interesting, but I am not sure if the number of integrations is the right way to limit. If there are integrations that are with expensive products, you might consider those to be more “premium integrations” or something (find some way of framing it that feels right to you, if not “premium”). You might even just tack on extra monthly cost for some integrations, e.g. Hubspot which is an expensive and deep product, or JIRA.
The most intuitive pricing model to me would seem to be something like:
number of products replaced by Fibery x average price of products replaced x 0.5 or maybe just total cost of products replaced by Fibery x 0.5. I posted an example scenario on Twitter a while back where, with the existing pricing model, the company I am consulting with would have paid the same to use Fibery or their other tools, and since Fibery was not as good as their other tools in some respects, there was not a lot of incentive to move. Assuming the Team tier would work for them (I think it would), pricing under your originally-proposed model above would now be $160/mo, which is actually almost exactly my formula above (basically half the cost of the tools they might replace). So… that’s interesting. 
