The 6 most important things to know about SaaS+ product architecture

Whether you want to build a SaaS+ company from scratch or turn an existing company into a business that can monetize embedded products and services, these are the six key concepts you need to know.

These concepts have technical implications but are as much business logic decisions as architectural ones. A founding team should have a shared perspective on these six issues. Being aligned on these concepts will drive product roadmap, core technical architecture, pricing strategy and product marketing.

You can 10x the revenue of your SaaS company by putting the right building blocks in place from the start. If you build the foundation of your SaaS+ house correctly, you can remodel the interior fairly easily in the coming years.

1. Everything revolves around the transaction

Shopping cart functionality and flexibility at the transaction level are two of the critical technical elements in SaaS+ because a high percentage of revenue typically revolves around the flow of funds on the platform. There are a couple things to think about when building transaction technology:

• Multimerchant cart: Building a shopping cart can get complicated when you’re taking into account more than one merchant in a single transaction, but architecting the cart to handle this from day one will pay dividends when you look to sell multiple SaaS+ products at the time of checkout. Specifically, this technology allows the user to see a single transaction, while behind the scenes there are actually multiple transactions occurring simultaneously, with each vendor individually. This is especially critical if you hope to sell regulated products such as embedded insurance.
• Split transaction/payout tech: An alternative to the multimerchant cart is the split transaction and split payout technology. This capability allows a truly single transaction at checkout, but then carries the burden of instantly associating net amounts due with each interested party and then settling with them by dynamically distributing the correct funds to recipients following the transaction. This is often initially viewed as the more elegant solution, but it doesn’t work for regulated products like insurance where the original transaction has to be with the actual insurance company. Realistically, you need to build both a multi-merchant cart and split transaction capability from day one.

For the end user, it all boils down to the checkout experience. Whether a given transaction is leveraging multimerchant cart technology or split transaction tools, the choice should be invisible to the end user while also accommodating a myriad of different SaaS+ products sold at checkout.

Example: At SportsEngine, we built a commerce system where customers use one shopping cart to check out, but each item is actually being bought separately. The customer enters their payment information only once, after which the platform initiates multiple transactions on their card behind the scenes. So, for example, they can register for Minnesota Hockey and USA Hockey in one step, while also buying insurance and their uniform in the same transaction. One cart, one checkout . . . four independent vendors.

Etsy also allows customers to buy from multiple merchants in a single transaction. The marketplace then splits the payment between the different vendors and themselves. DoorDash’s single vendor shopping cart allows you to add multiple dishes from a single restaurant, but to order from two different restaurants, you need to make separate orders.

2. Single instance of a human

Don’t silo your data. You want to create one profile per person and use it everywhere on your platform. This means: one profile, one payment method, one background screen and one rating system for each human. Build your data model so each person’s profile and information is available across the entire platform. This is the power of the platform.

Customers will often talk you into silos because they don’t want their users to be shared. But you have to fight through that request. It will dilute the power of your platform and data will quickly become unwieldy if one human exists many times in a platform.

Create a structure where the “core profile” data is truly shared across the platform, but each customer can uniquely and privately append specific data to the user profile and that data becomes theirs alone. Most customers will view this as an acceptable solution.

The benefits to “single instance of a human” are enormous. Customers only have to enter their information once and any updates accrue back to their core profile. Their information is easily accessible to them any time they log in. And information flows both ways. All customers will have a more accurate view of their users as the profile grows due to the contributed data from numerous different sources.

Example: A great use case for this would be construction software platforms. An electrician who joins might be associated with one or many construction companies. Let that electrician be part of one or many builders. It’s a benefit to both the electrician and the construction companies. The electrician has to enter their bank account only one time to receive payment from any company. They have to submit to only one background check, which is now easily available to construction companies.

3. The parent-child data model

In data management, parent-child is a relationship between two files. Parent-child hierarchies are used to organize hierarchical information in the data source and they allow for the ability to create multiple profiles under a single account. The ability to architect your data to structure parent-child relationships is super important in a SaaS+ company. When you’re looking at your data model, look at your domain and understand what parent-child relationships will exist and how you’ll model that ecosystem.

Example: USA Hockey is the parent organization of Minnesota Hockey, which is the parent to District 2 Hockey, which is the parent to Stillwater, MN, and Roseville, MN, Hockey. There is a hierarchy of national, state, district and local hockey. How these organizations relate and share information is the parent-child data model.

4. Sister entity relations

Sister entities are multiple entities who have the same parent entity. You’ll want to think through how these organizations can share information within the wider hierarchy. What data can they share between themselves? What layers of data do people need? What layers of data make your platform the most powerful?

Example: We needed to accommodate sister entities across multiple configurations. Stillwater, MN, youth hockey needed to contextually share data with their rivals at Roseville, MN, youth hockey. Without the sister entity data sharing engine, aggregate team standings or player statistical leaders would not be accurate.

We also dealt with single community sister entities. If a family has children who play different sports, then Mom and Dad can have all of those schedules aggregated onto a single family calendar and have a single credit card on file to pay all of their sports bills.

This concept is manifested in numerous variations across industries, but inevitably exists in every SaaS+ environment.

 

5. Shared payment wallet feature

The shared payment wallet feature allows you to create one central payment file that can then be used across multiple merchants and profiles. It provides a ton of value because customers only have to enter their payment info once and can then manage all of their purchases from a single account. The checkout experience is fast and uniform. And you can leverage points and rewards.

This capability is increasingly demanded by the end user and for good reason. The technology is equally useful for the SaaS+ platform. When an end user leverages a single payment method across multiple end merchants and transaction types, an enormous amount of intelligence is derived on their spending behavior. Eventually a picture is painted that allows the platform to better tailor their offers and experiences. This same capability also forms the foundation of tools like rewards and points programs that drive loyalty. There is also significant payment processing interchange arbitrage that presents itself when you can truly understand an end user and their preferred payment method.

Example: Shopify and Amazon are well-known examples of platforms that use a shared payment wallet. You no longer have to have an account with the individual merchants on their platforms — you can use your one central payment wallet to make purchases.

6. Revenue orchestration layer

If you’re building a new vertical software platform with SaaS+ revenue streams, you’d be foolish to hardwire your business or your technology to one vendor. You want to be able to plug and play and swap partners/vendors seamlessly behind the scenes.

This ability allows you to dynamically move volume from one vendor to another for lowest possible cost, highest possible authorization rates and other strategic initiatives. The value of doing this is enormous. It keeps your partners honest and aggressive.

For many years, this type of dynamic vendor orchestration had to be proprietarily built, which is what we did. Now companies exist to do this for you. At Rally Ventures, this is a concept that we so strongly believe in, that we have created and launched JustiFi to do this for payment processing vendors, Yardstik to do this with background screening and identity verification vendors, and Vertical Insure to do this with insurance vendors.

Example: One of the best-known examples of a revenue orchestration layer is the travel booking application Kayak.

Kayak sits on top of the entire travel industry. It acts as an orchestration layer and pulls in rates from the aggregators, from the airlines directly, from the hotels directly and from a myriad of other sources. Once and for all, the consumer is ensured they’re receiving the best rate on every travel transaction.

Ultimately, all of these architectural decisions are in service of more transactions and more funds flow. Yes, it helps you create a great platform that is great for your customers. But it is ultimately all in service of more funds flow. In a SaaS+ platform, the critical statistic is end user transaction count.

More transactions mean more monetized funds flow, more identities verified, more insurance policies sold at checkout and more additive goods and services sold at checkout. All of this activity is good for revenue and good for the core SaaS business, as customers almost never churn when their users are leveraging the platform this way.

It also delights end users, who clearly want and need to transact and are delighted that it was made easy for them.