The 6 most important things to know about SaaS+ product architecture
Prepand to the content
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.
Being aligned on these concepts will drive product roadmap, core technical architecture, pricing strategy and product marketing.
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.