Fibery vs low-code tools

We are a B2B SaaS company and we want to build an app that aggregate all our customer data (Customer Data Platform) for the following use cases:

  • operational/admin tasks:
    • attributes licences and permissions to Users, based on limits on the Account (ie company) licences purchased => data coming from SalesForce for the licences purchased, and from our user DB.
    • block Users in case of misbehavior
  • analytics/knowledge task:
    • for each Account, see all Users with their licences, monitor licences not used
    • for each Account/User, see all events on the platform (user analytics), all the interactions they had with CSM and Sales, all emails received/opened, interactions they had with competitions, etc => data from SalesForce, Intercom, Customer.io, gmail, Segment.com
    • metrics/charts to measure Account/Users engagement, behavior, etc
    • notification for CSM/Sales for Account/Users not enough engaged
    • automatic campaigns on some data triggers (to reengage for example): emails/intercom in-app messages, etc. => probably not create the campaign in the CDP but trigger via API in Customer.io or Hubspot

=> So a mix of structured and unstructured data

We have started to build the CDP with ForestAdmin:

  • easy to connect to our “data warehouse” that contains Segment.com user analytics, SalesForce sync, Customer.io sync and user roles/permissions for our app
  • CRUD actions on roles/permissions in our app

I wonder if Fibery alone or Fibery + another tool would better for those uses cases but also:

  • Accounts/Contacts/Competition knowledge database
  • Product Management and dec => replace Clubhouse.io, Harvestr
  • Internal tasks, meetings notes, etc => Notion, Google doc and slides, some slack channels
  • potentially replace SalesForce: SF is mainly a DB and workflow built around 4 Types Accounts/Contacts/Deals/Interactions(email, call). Once Fibery allow (via chrome extension or other means) to offer an integration with gmail, SF could be replaced. Quote and discounts computations would be replaced by Fibery formulas and automation. More specialized tasks like pdf invoices, Docusign integration, NetSuite integration would probably have to be built by us.

Fibery could be the primary input and source of truth for Account/Contacts/Users/Competitions/Deals/Interactions/Ideas/Features/UserStory/Meeting notes/Tasks, using the nice features of structured linking + references in text. Intercom sync already there (even if only one-way, the interactions still need to be done in Intercom app)
=> Sales, CSM, Product, Devs will use the same system and better linked data, less systems sync required

Where I see the limits of Fibery:

  • high volume data: do we really want to create a Fibery Type for user analytics? Schema is driven by our app, volume of data is high. It would clutter Fibery, the search feature for example, would the performance be a problem? @mdubakov If you think that this should be sync as Fibery Entities, then do you plan to integrate Segment.com?
  • Admin panel/external actions: CRUD or API calls to external system, in particular interact with our SaaS app. For now Fibery looks more as a knowledge base, that do one-way sync, from the external system to Fibery, not really the reverse.
  • Notifications for calculated metrics or events: notify CSM/Sales when a specific metric reach a threshold.

Low-code tools are doing a bit of what Fibery does (apart of the unstructured/textual data features) but with control on the DB and the code:

  • Internal.io, ForestAdmin: CRUD interface on top of your internal database, similar to djangoadmin as well. Used mainly for internal admin app for SaaS companies
  • Retool: more dev oriented, used to build custom internal applications: complex approval workflow with many rules, with a custom UI, complex permissions.

How is Fibery positioning itself compare to those? @mdubakov do you think Fibery can fulfill my need for the CDP?

2 Likes

It’s an interesting case and we partially use it ourselves to track Fibery usage, but here are my comments:

  1. Fibery was not designed to collect millions of records and that is what you have for analytics. So we suggest storing only aggregated data in Fibery. If you will store every interaction point, most likely Fibery will become unusable in the future and indeed it will clutter search, for example.
  2. Overall this is not the case we are going to support in near future, Fibery focuses on workflows/knowledge management, stats and rough data analytics is behind our scope in maybe next 1-2 years.

However, we are going to add notifications as a part of automated rules, so it will be possible to send emails to sales for some metrics in future. However, these metrics should be calculated outside Fibery and put into a numeric field.

Also we are going to provide a better API on top, like GraphQL that will be easier to use.

Special admin for API and external calls is not in plans so far.

So while low-code is not our focus, Fibery will cover some potential solutions in this space.

2 Likes

Thanks @mdubakov for your answer.

  1. In line with what I thought, Fibery not designed for huge analytics or timeseries. Ideally it could have a block to display those data via iframe or simple table view that call an API (not storing data in Fibery)
2 Likes