A central database is essential to automate the right way

We had the names of the projects in 4 different lists. When the company subscribed to a new SaaS, we had to add them one by one. When a new project started, there was an automation to create it on the 3 other SaaS.

When we added a new field for all projects in all SaaS, that was a nightmare.

And then, I recognized the importance of the Single Source of Truth (SSoT). The CEO of Salesforce called it the “4th wave of computing”.

In short, SSoT = central database.

Why you should have a Single Source of Truth

Because you don’t want to type manually the same information on Airtable, Pipedrive and Google Sheets,
Because you don’t want to have:
- Info for products on Shopify
- Info for clients on Pipedrive
- Info for assistance on Freshdesk
Because you want to analyze data with all sources.

When you have one-sided connections (or no-connection at all) between your SaaS apps, data is not updated completely.

For example, let’s say you have a newsletter SaaS and a CRM. They’re not connected. On your CRM, your prospect says he doesn’t want to be contacted again. You cross “not contact anymore” in your CRM. As these SaaS are not connected, the prospect will still receive emails from you, which can lead to a bad reputation.

What is it exactly?

The definition of Wikipedia is: “In information systems design and theory, single source of truth (SSOT) is the practice of structuring information models and associated data schema such that every data element is mastered (or edited) in only one place.”

From Oreilly

Applied to automation, the concept goes like that: if you change a data in your CRM, the data needs to be changed in your central database (eg: SQL, Google Sheets, etc.)… If the data is changed in your central database, it needs to be changed automatically in your CRM.

Common Single Sources of Truth for startups and small/medium businesses

SQL

That was the first way I used it. A good old MySQL database with lots of tables.

The language (SQL) is quite simple, it is very quick and well-structured.

Example: one sales representative updates the phone number of a prospect on the CRM. Then an automation tool like Integromat changes automatically the entry in the database. When the entry is changed in the database, the value is automatically changed in your phone calling system and various other SaaS.

Advantages: universal, speed.

Problem: it is difficult to edit the info directly inside the database.

Ideal solution for large projects, for which you have access to a few developers. SQL is not platform-dependent, so it gives more freedom when dealing with the data.

Google Sheets / Airtable

Google Sheets / Airtable can be used as a database, with each file that can be a table.

Problems:

more difficult to have a structured database,
and you don’t have a whole view as you can with SQL database.

Ideal solution for new projects, which are not completely implemented in the company for the moment. Projects that need to be configured in a day.

Bubble.io

That’s my single source of truth currently.

Bubble is a no-code tool to create powerful softwares.

I works as a SQL database, but you can also edit the information quickly by adding it to a page.

I combines the good features of a SQL database and Google Sheets: you get a well-structured information easily (SQL database), and you can edit that information easily too (Google Sheets).

Ideal solution for already working projects, which have been running for multiple weeks on Google Sheets/Airtable. At some point, you will see limitations on Google Sheets/Airtable because they lack some customizations. That customization can be obtained by building the project on Bubble in 5-6 days if you already know the platform.

Summary: which source to choose

You should try each solution (SQL, Google Sheets/Airtable, Bubble) if you can.

Usually, you should take Google Sheets / Airtable for small projects, Bubble for medium projects and SQL for large projects.

Many people from startups seem to be using “by default” Airtable as a database for various projects these days. However, even if Airtable is great, Bubble is much more customizable (but more complex too).

The costs and benefits of having a well-made Single Source of Truth

Benefits: the Metcalfe’s law

So you want to subscribe to this new SaaS to increase your productivity. It has happened to me a few times.

Your data should be well-organized into cards, to-do lists, all-in-one interface between 100 interfaces, or whatever.

If you don’t have a SSoT, each time you want to establish a connection, you will have to create a new automation script/scenario.

But the problem is: the more you add SaaS softwares, the more you will have to make connections between each piece.

It is the Metcalfe’s Law, and it says that two telephones can make only one connection, five can make 10 connections, and twelve can make 66 connections.

Image from Wikipedia

That’s why more and more people are talking about the SaaS connector overload. It means that if you have 100 SaaS in your company, and there is no central database to keep the updated data in the center, you will have to build a LOT of automation connector.

And it means a LOT of time wasted.

Let’s calculate quickly how much time it would cost to build these connection. Let’s take a 50-people company, with 40 SaaS subscriptions to run the company. Of course each SaaS won’t speak to each SaaS. Let’s imagine each SaaS communicate with 4 other SaaS, and that each SaaS has 3 types of data to update (for a CRM: a contact, an organization, a deal). Let’s say we make two-sided connections between each SaaS that we connect (if you update SaaS1, then SaaS2 is updated, and same for SaaS2 -> SaaS1).

That’s 960 connections to maintain!

If a developer takes 30min to build each connection, and 10min / year to maintain it, it takes 480 hours to build, and 160 hours per year to maintain!

For a senior developer at $70 per hour, that means $33 600 to build, and $11 200 per year to maintain.

Compare that with a central database. For each SaaS, you need to build back and forth scripts to synchronize with the central database for 3 types of data, so 6 in total. That leads to 40 SaaS * 6 = 240 connections.

Times with SSoT: 120 hours to build, 40 hours to maintain.
Costs with SSoT: $8 400 to build, $2 800 per year to maintain.

To sum up, on a 5-year basis, the company :

will save $67 200 (89600 – 22 400),
will get at the same time clean and updated data on each level of the company.

The upfront cost of SSoT

So why don’t people do it?

SSoT has an upfront time cost: you need to structure it properly in a database, which you don’t have to if you manage two SaaS without a central database.

There is also a technical cost: people use drag-and-drop tools like Integromat or Zapier, but many are not developers. They use these tools as business people without thinking about information structure.

While having a central database is essential with large projects, it can be time-consuming when dealing with a new project (when you don’t know if this project will continue for a few days, or a few weeks, or years…).

When you feel that a project starts taking off, that more and more people start using it, you should stop for a second and think about connecting the project to the rest of the company before it is too late!