The Six Most Important Things to Know about SaaS+ Product Architecture

By Justin Kaufenberg, Managing Director at Rally Ventures and Former CEO and Co-Founder of SportsEngine; and Greg Blasko, Co-Founder of Monoline and Former Co-Founder and CTO of SportsEngine.

Next up in our SaaS+ Series, we’re talking about the core architectural concepts you need to think about when building a SaaS+ company. 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 percent of revenue typically revolves around the flow of funds on the platform. There are a number of things to think about when building transaction technology:

• Multi-merchant 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 multi-merchant 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 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 multi-merchant 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.

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. This happened all the time at SportsEngine. 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 login. 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 the platform 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 only has to enter their bank account one time to receive payment from any company. They only have to submit to 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: The USA Hockey structure. 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: At SportsEngine, 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. In the town of Stillwater, MN, a given family may have children that play hockey, basketball and lacrosse. Stillwater youth hockey, Stillwater youth basketball and Stillwater youth lacrosse are all completely unrelated legal entities, but if they are all on SportsEngine, 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 for all of their children.

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.

At SportsEngine, customers can use their payment method on file for any sport and/or season, even across numerous disconnected organizations. Furthermore, that same card on file can also be used to purchase uniforms, insurance, sports equipment and more.

6. Revenue Orchestration Layer

If you’re building a new vertical software platform with SaaS+ revenue streams, you’d be foolish to hard wire 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 at SportsEngine. 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. For many years, we all booked our airline travel directly through Delta and we booked our hotel stays directly through Hilton. The travel world was turned upside down when aggregator companies, such as Travelocity and Orbitz, allowed you to search all airlines and all hotels with the click of a button. Eventually the aggregator market became saturated and confusing, and a single top level orchestration layer application was needed to make sense of it all — and Kayak was born.

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. The same concept is employed by JustiFi, which sits on top of countless credit card payment processing platforms, ensuring the lowest possible rate on every credit card 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.

This article originally appeared in TechCrunch.