Our relationship and reliance on SaaS has grown progressively over the past 20 years. Industry after industry has shifted to Software as a Service (SaaS). Most major platforms have a recurring subscription model, or are moving to it. We have the illusion of a preponderance of choice. The reality, however, isn’t quite as rosy. What was initially signed up for 2 years ago is now something that we rely on, but have no control over. SaaS platforms come and go. Services go down. Platforms grow and add all kinds of new features. Most SaaS companies optimize their onboarding experience. It’s the moment they earn our business. But the Software Service experience shouldn’t end there. This is where we lost the “R”. SaaS companies have a RESPONSIBILITY to customers across their entire lifecycle.
We caretake and protect our customer’s identity and data. We are responsible for providing a service that is always there when the customer needs it. But now SaaS solutions are being deployed INSIDE of the applications we build. When 3rd party SaaS becomes a component of what we ship to our users, to our customers, then we have to evaluate SaaS solutions with a new lens: that of end-to-end responsibility.
Everyone Has SaaS Problems
Story time: A story of SaaS designed right that eventually went wrong. When building software, we do the best we can with what we have today. This team was a senior team of engineers and architects building rocket surgery tools for rocket scientists. The team was composed of industry-recognized leaders capable of diagnosing the most complex issues of their platform. The team needed an identity solution so users could log into the service. They were not experts in identity. They built a spec for user identity for the application they all worked on. It was a good spec. When implemented, it worked. Individuals could log in, log out, reset and recover their passwords. The team moved on to the more important parts of the application. They shipped good code.
It worked until they needed to add Role Based Access Control. Adding Role Based Access to individual identity and access control is conceptually quite simple. All users are added to an empty Access Group that isn’t yet affiliated with a group. The spec change was simple. Even better, there were customers interested in purchasing the software IF IT HAD Role Based Access Control TODAY.
However, the Identity as a Service solution that was used needed to be migrated to a completely new configuration to work right. This required migrating one of the most sensitive services the team relied upon: Identity. This required scheduling downtime for all users of the system. In a 24/7 always on world, the team had never had to do this for anything else they built. Role primitives and lookups had not been considered during the initial design, so they had to be added and hooked up throughout the software, a huge development and engineering cost. Then, adding insult to injury, the two separate configurations with the Identity provider had to be maintained for many months to ensure the previous implementation could be rolled back if any issues were to arise in the new service.
This team of expert practitioners cost the company hundreds of thousands of dollars in lost sales and additional development costs because they weren’t experts in a simple subsystem that was essential, but outside of their core competency. Something that became of critical interest once, and only once, then on to be forgotten again. Outside of the business’s unique, strategic business value.
The SaaS Service Provider Didn’t Do Anything Wrong
Who’s to blame? What could be done? The Identity as a Service provider serves plenty of use cases that never need to incorporate Role Based Access Control. In general, it’s best to avoid complexity if you can avoid it. That said, we’ve been doing this for a while now. Building SaaS products. Growing and evolving over time. The patterns emerge time and again. If a team is building a service designed to expand and grow, designed to serve new audiences and increasingly complex use cases. There’s a sweet spot where 90% of the market evolves through. If this team could have relied on a widely adopted and tested product design resources tested and validated across hundreds and thousands of use cases, they could have saved hundreds of thousands of dollars and months of work with a relatively minor tweak to their initial implementation.
The team ended up staying with the same Identity as a Service provider. Years later they never needed to come back and change their identity setup.
Move Fast, Don’t Break Things
Facebook is famous for the product mantra: “move fast, break things”. This worked for years at an advertising juggernaut that offered a free service with a monopolistic chokehold on the market. This, however, doesn’t work if responsibility to the customer’s experience is important to your business. Most businesses can’t get away with this, and, honestly, don’t want to. Ensuring a predictable customer experience builds trust. Breaking the customer experience, simply put, breaks trust.
When designing a system, there are a few key services that most SaaS businesses have to build. If a system has users, you need to have Identity. If the business is going to stay in business, it needs to charge customers for the valuable service it provides. To do that, the business will need a billing system. These digital systems are no longer built using a single, monolithic framework with a single data source. Today’s applications operate with a network of events spanning a multitude of internal services and many external SaaS providers that drive the end user experience and the supporting internal team experiences. To manage all these events, you need a data pipeline to be able to audit, troubleshoot and support an ever growing user base. None of these systems are likely to be in the core competency of the team hired to build the unique vision your business provides. So how can we move fast and not break things while focusing on your product vision?
A New Hope: Solving Solved Problems
To put the “R” back in SaaS so you can build what you want to build for your business, you need resources tailored to your needs, validated across many iterations. Successes and failures. Production tested. Industry vetted. In 2021, a group of experienced software leaders banded together to provide a product experience tailored to this specific need. Dan Shaw, Ahmad Nassri, Jory Burson started an independent software company called Cor Development, Inc., referred to simply as “Cor”.
Cor is the latin root for Core AND Heart. Cor is focused on the needs of Software as a Service providers, of digital application builders, providing them with the resources needed to build and deploy the essential underlying services needed to grow and serve customers throughout your organization’s lifecycle.
Dan, Ahmad, and Jory have worked at companies ranging from early-stage startups to mature businesses to the largest industry players building upon decades of success (and legacy software). Their unique experience combines deep platform building expertise and broad understanding of standardization processes. If your organization uses identity, billing, data events, auditing and logging, then your team needs Cor.
We’ll be there with you. Providing money-saving guidance. Delivering spec accelerating product tooling so you can build it right the first time, migrate to new service providers when needed, and safely end-of-life systems that have served their purpose. At Cor, we work on the solved problems that you shouldn’t have to worry about, so your decisions don’t come back to hurt your bottom line.
In 2021, Cor will change how software is built by allowing your team to focus on their unique business value, by providing you solutions to the solved problems you don’t want to build once again. Sign up to get early access.
