The SaaS 2.0 Manifesto

With the rise of the SaaS model, apps have come a long way.

SaaS apps bring several benefits, such as:

• You can use apps without going through the process of downloading and installing them on your computer.
• You can share living documents with individuals outside your organization.
• Remote work is much easier.

Alas, SaaS apps have disadvantages.

In this article, several drawbacks will be explained about using SaaS apps and how to solve them.

Caution: This article is protracted and targeted at software architects, UX designers, or individuals involved in the SaaS ecosystem. Please consider The Missing SaaS Platform for a summary of the SaaS 2.0 ideas in simpler terms.

What's Wrong with SaaS Apps

Many SaaS apps are fantastic. Albeit, when combined in the context of an organization, they underperform.

Let's see why.

Users and Documents

Let's go back to a few years ago when organizations used good old desktop apps and could centrally manage users and documents thanks to the following:

• Users and permissions could be managed from a central location with a service like Active Directory.
• Documents could be stored in folders accessible to everyone in the organization.

In contrast, SaaS apps raise the following difficulties:

• Users and permissions must be managed in each app individually, which can become impractical when someone joins, gets promoted, or leaves.
• Documents are scattered across multiple apps, making it difficult to centralize their organization or perform quick searches.

Communication

How do organizations communicate about their projects and documents?

Conversations are spread out across emails, chat apps like Slack or Zoom, and comments within various documents.

This can make working on a project chaotic, especially when a new person joins and struggles to understand the progress.

Effective communication is a common challenge faced by organizations.

Common Features

All SaaS apps have similarities, such as:

• Document organization (e.g., gathering related documents into a folder).
• Document sharing (e.g., sharing documents with staff or an external collaborator).
• Communication regarding the documents with discussions, mentions, reactions, etc.
• Document embeddability (i.e., embedding an app's document into another app's document).
• User management and notifications.
• Subscriptions, invoicing, and payments.
• General settings (e.g., organization profile, language, or appearance).

Apps have similar features, although they are presented differently. It's akin to learning a new language while using various apps. This leads to a poor user experience overall.

Pricing Model

What's more, many SaaS apps charge subscription plans based on the number of users and available features, which may seem simple, but it falls short of expectations.

This pricing model does not address two essential factors:

• Some users use certain apps occasionally.
• The majority of users make use of a fraction of the features.

Therefore, many organizations have to make tough decisions about which apps to use, because they can't afford them all.

The SaaS 2.0 Platform

The existing SaaS apps are built on the Web platform, which is great, but it was not designed to support app development.

In fact, an essential ability of classic desktop apps, which is user and document centralization, is missing from the Web platform. This contributes to the problem mentioned earlier.

To solve this, we need a platform (based on the Web platform) to enable a new generation of apps that can enhance the global user experience.

Let's see what this platform would look like.

Users and Organizations

Everything starts with the users (i.e., the persons), and anyone can create a user account.

Next comes the organizations (a company, an NPO, or any group of persons). Users can create an organization and invite others. Note that a user can be part of multiple organizations.

The platform manages the users and organizations and connects them to the apps.

Thus, when a new user joins, they can potentially access all of the organization's apps and documents.

Documents and Folders

Users can access all the documents from the platform and keep them organized by creating folders.

The platform also includes a search engine to help users locate specific documents.

Communication

The platform gathers all the discussions about projects and documents.

Other Common Features

The platform manages other common features, such as document sharing or user notifications.

Pricing Model

As mentioned above, many SaaS apps charge customers through subscription plans, which is imperfect for many organizations.

We should consider the pay-as-you-go model that most cloud service providers use (e.g., AWS, Azure, or GCP).

This pricing model has proven its effectiveness and has received a lot of praise because it's deemed to be the fairest. No fixed costs and we only pay for what is used.

If we overlook the fixed costs (e.g., design, development, or marketing), what remains for most SaaS vendors are the hosting fees paid to the cloud service providers. These fees are the sole costs that change (except for customer support) based on the number of customers and how they use the apps.

Cloud service providers also have fixed costs. Still, they're included in the variable costs they charge through pay-as-you-go hosting fees.

Since the cloud service providers can offer such a pricing model, the SaaS vendors should invent something similar and eliminate the subscription plans.

This means that all potential apps would be ready for use.

The exact pricing model is still being drafted, but the platform should issue an invoice to each customer, detailing the usage of each app. The app features would be charged with two fees: operation (which includes computing costs and a portion of the fixed costs) and storage (charged per GB).

Furthermore, customers could track the cost of each app in real-time and set limits to avoid unpleasant surprises when they receive their bill.

The cost of the apps should be reduced due to the following:

• No matter how many users, apps, or features, customers will pay for what they use.
• Since many features are implemented at the platform level, customers will benefit from the scale effect.

The SaaS vendors will not lose profit because:

• The pay-as-you-go model has proven to be profitable for cloud service providers.
• Since many features are implemented at the platform level, SaaS vendors could build their apps faster and reduce their development costs.

Apps

The apps are in charge of the document content and all its features.

Some basic information about the document (such as "Title," "Description," or "Author") can be stored in the platform.

Furthermore, the apps can store tokenized texts in the platform to make the documents easier to find.

By relying on the platform to handle many features, the app vendors can focus on their core business, which is documents, and let the platform manage the rest.

Decentralization

Having just one company control the SaaS 2.0 platform would not be appropriate. To prevent this, the platform should be open and decentralized, just like the Web platform it is built on.

In the following section, the overall architecture of the SaaS 2.0 platform will be explained, along with some technical details.

If you are not tech-savvy, feel free to move on to the next section.

In the previous discussion, we simplified the SaaS 2.0 project by referring to it as a "platform." However, the project comprises four distinct component types: identity registry, platforms, marketplaces, and apps.

Identity Registry

A central place to register users and organizations.

In essence, the identity registry provides the following features:

• User (e.g., "john.doe") registration, authentication, and platform association.
• Organization (e.g., "acme-inc") registration, ownership management, and platform association.

Of the four components of the SaaS 2.0 project, the identity registry needs to be operated by a single entity, which should be a nonprofit organization with a governance model similar to other organizations that helped build the Internet and Web platform (e.g., ISOC, ICANN, or W3C).

Platforms

Any developer can create a SaaS 2.0 platform.

Note: While the platform's features can vary, below is what a typical platform would provide.

Whether a single user or an organization uses a platform, they have access to the following:

• User or organization profiles, which contain information such as their name and email address. These profiles are connected to the users or organizations that are managed by the identity registry.
• Marketplace association to make the apps accessible to the users or organizations. Often, a platform will have at least one primary marketplace associated with it, but it can also have secondary marketplaces.
• References and metadata of any app document.
• Folders to organize the documents.
• Communication around the folders and documents.
• Folder and document sharing.
• Document embeddability and other integration abilities.
• User notifications.
• Search engine.
• Platform consumption fee recording in the associated primary marketplace.

For an organization, the platform provides the following additional features:

• Member management (a member can be added through an invitation).
• Member profiles containing organization-related information, such as position or email.
• Groups (a collection of members).
• Member and group permissions (e.g., view, edit, or communicate) related to certain folders or documents.

All platforms can interoperate. For example:

• A user can join an organization using another platform.
• A user or organization can communicate with a user or organization using another platform.
• A document can be shared with a user or organization using another platform.
• A user or organization can move to another platform while keeping all its data.

Last, a platform can be public (i.e., accessible to all users or organizations) or private (i.e., restricted to certain users or organizations).

Marketplaces

Any developer can create a SaaS 2.0 marketplace.

Note: While the marketplace's features can vary, below is what a typical marketplace would provide.

A platform can register one or more marketplaces for each user or organization.

A marketplace provides the following:

• App curation.
• App and platform consumption fee storage, consolidated invoicing, and payment collection for each user or organization handled by the platforms.
• Income redistribution to the app and platform vendors.

Last, a marketplace can be public (i.e., accessible to any platform) or private (i.e., restricted to some platforms).

Apps

Any developer can create a SaaS 2.0 app.

An app can be submitted to one or more marketplaces, and if approved, the app becomes available to all platforms associated with these marketplaces.

An app takes care of the following:

• Document content storage.
• Document content-related features.
• Document metadata recording in the platforms.
• Platform feature usage (e.g., user notifications, contextual conversations, or document embeddability).
• App consumption fee recording in the marketplaces.

About the Semantic Web

The Semantic Web, also known as Web 3.0 (unlike Web3), was envisioned by Tim Berners-Lee over 20 years ago and was recently expanded with the Solid specification.

However, that is not suitable for the SaaS 2.0 project.

While we share the goal of allowing people to keep control of their identity and data, we have different ways of doing so.

Regarding identity, we want to ensure that users have the best possible experience. With Solid, user identifiers appear as "https://id.inrupt.com/johndoe", whereas with SaaS 2.0, they will look like "john.doe".

Additionally, Solid separates data from apps, which seems like a good idea but brings performance issues. In reality, data must be as close as possible to the apps to function at their best.

With SaaS 2.0, apps will be in charge of storing data. To ensure that people own their data, they will have the option of running these apps on their preferred cloud service provider or their own on-premise data center.

As for the promise of interoperability offered by the Semantic Web, we have a different approach that could be qualified as the "Object-oriented Web." The section below provides more information on this topic.

Integration

An essential aspect of the SaaS app ecosystem is the ability for apps to integrate.

For example, a Notion document can embed a Figma document. However, the possible integrations are limited to a certain number of apps (often the most popular) because each integration involves custom development.

SaaS 2.0 will standardize document embeddability and implement it at the platform level. Thus, a document will be capable of embedding any other type of document without requiring custom development for app vendors.

A second integration is the ability to trigger an action in an app (e.g., posting a Slack message) when something transpires in another app (e.g., a customer buys something on an e-commerce website managed by Shopify). This can automate workflows and save time. However, the number of possible integrations can be limited because each involves custom development for every app vendor.

A product like Zapier tries to solve the problem by moving the integration abilities to a platform. Alas, even with a product like Zapier, building, sharing, and embedding integrations can be tedious. According to Zapier's developer documentation, creating and setting up an integration can take a month.

Another way that different apps can collaborate is by aggregating several documents to produce, for example, a report. This can be the most difficult, and few apps offer this ability for limited document types.

SaaS 2.0 takes a different approach to integration abilities. The problem with current SaaS is that integration is implemented on an app-to-app basis. It would be preferable to base integration on standard document types instead of apps, allowing users to benefit from any integration that involves certain documents, regardless of which apps handle them. This approach would also reduce the developers' burden since they only need to expose a document as a standard type rather than creating custom integrations for specific apps.

As part of the SaaS 2.0 project, a standard document type refers to a specific format of data included in a document, as well as a set of actions that can be executed on it.

Consider it as an abstract class in object-oriented programming. An abstract class defines a set of attributes and methods that can be implemented by other classes that inherit from it. Similarly, a standard document type would define a document's basic structure and functionality, which apps could implement.

Creating standard document types is possible for the following reasons:

• The point is not to establish standards for all document types but for the most common ones (e.g., text documents, spreadsheets, to-do lists, calendars, or business documents such as contracts, orders, invoices, etc.).
• We don't start from zero. There are plenty of standards to build on, including the impressive collection of Schema.org.
• While some apps may not be able to standardize their documents, they can still offer custom document types to facilitate integration with other apps.

An additional benefit of using standard document types is that it would make it easier for users to transfer their documents between different applications.

Privacy

Maintaining the privacy and security of user data is our top priority. Each component of the SaaS 2.0 project has been designed to access only the data necessary for its proper functioning.

To protect user privacy, the component types mentioned in the "Decentralization" section above have restrictions. Below are some examples of those limits:

• A trustworthy nonprofit organization with the highest privacy and security standards operates the identity registry.
• The platforms cannot access the content of users' documents.
• The marketplaces have access only to the billing information of customers and app vendors.
• The apps don't have access to users' identities.

Similar to how it works with current SaaS apps, the vendors who create SaaS 2.0 apps will store users' documents and will technically have access to the content. Nonetheless, it may be possible for customers to install these apps on their cloud service provider or on-premise data center. By doing this, users can have more control over their data and ensure that it's kept private and secure.

Implementation

The SaaS 2.0 project is not about building a company that would dominate the world, but establishing an open standard so multiple independent entities can build interoperable platforms, marketplaces, and apps.

An efficient way to establish a standard is by creating an initial proof of concept product and refining it until a standard can be defined.

1Place Inc. intends to create this initial product by designing and developing all the required components, including an identity registry, platform, marketplace, and a few basic apps.

Afterward, an independent nonprofit organization will formalize the standard and operate the identity registry.

1Place Inc. will open-source its software as much as possible using an open-core model.

The NPO will open-source everything with a permissive license, such as the MIT license.

Getting Involved

To make the SaaS 2.0 project a reality, 1Place Inc. needs to raise money and hire talent.

The company is based in Japan, but is open to relocating if the initial investors request it.

Please contact us if you wish to contribute to the SaaS 2.0 project.

If you're interested in the ideas behind the SaaS 2.0 project but want to build a similar project, please don't. If multiple standards are created, they could compete, which is far from ideal.

Instead, let's collaborate. Even if you work for a large enterprise, there are many ways to contribute to the project.

If you are interested in creating a platform, marketplace, or app, please wait until the NPO formalizes the standards.

If you find the SaaS 2.0 project intriguing but cannot commit to getting involved, or if you envision yourself as a user or developer, we invite you to subscribe to our newsletter.