Lessons From Selecting SaaS Products: Where Is GitOps?
How this motivates me to build a new product
If you're connected with me, you know my passion lies in building things. For a significant part of my career, that has meant deeply engaging with SaaS (Software-as-a-Service). I've worked in various environments, from agile startups to larger corporate structures, and I've certainly experienced my share of both successes and challenges in selecting and managing the multitude of SaaS products required to run our own SaaS offerings. It's a dynamic landscape: the average company uses 106 SaaS products. Personally, I've evaluated dozens, if not hundreds, of these. Every single one, whether a great fit or a ‘failure’, provided valuable insights.
Examples of SaaS products that have been influential to me:
Hosted OpenTelemetry with dash0.
Auth platform Ory.
Creating certificates with ZeroSSL.
Analytics platform PostHog.
Managing authorization permissions with Permit.io.
Doing HTTP health checks with UptimeRobot.
Managed MongoDB without (direct) use of a hyperscaler.
Most tools simply are inspiring, demonstrating precisely how things should be done. Others, however, offered valuable lessons in what not to do, which in turn helped sharpen my own vision even further.
A quick note: this article isn't focused on open-source versus commercial tools today; that's a discussion for another time! For this post, I'm concentrating on commercial companies that offer a clear value proposition: exchanging money for time by solving a specific problem, ideally in an innovative and inspiring manner.
My biggest takeaways revolve around how we configure and manage these crucial SaaS tools, and the ongoing tension between ideal automated workflows and reality.
What Defines a "Good" Product in My View?
Firstly, I seek a balance between effective marketing and a working solution that actually solves my prolem. Both elements are vital. Marketing strategies are evolving rapidly; with AI generating content at unprecedented speeds, capturing genuine human attention has become increasingly challenging.
Once a tool captures your attention, it must deliver – quickly and easily. The best products go to great lengths to lower the barrier to entry:
Exceptional Tutorials: They understand diverse learning styles, offering various formats like videos, blog posts, and interactive guides.
Accessible Support: This includes vibrant Slack communities, responsive social media engagement, and prompt response times for questions.
A Sensible Free Plan: The intention is clear: the credit card will follow after the tool has proven its ability to solve a real problem.
Seamless Self-Service: For engineers and DevOps professionals, this is non-negotiable. We generally prefer not to involve dedicated customer success teams for basic setup. While excellent support is invaluable for complex issues, an ideal product is designed to facilitate its own adoption and integration. That is the true "happy path."
The Integration Process: Beyond the Initial Setup
Having evaluated numerous tools over the years, I've observed a consistent user journey. It's a path familiar to many engineering professionals:
The Problem Emerges: A specific challenge or operational need arises.
The Search for a Solution: The user actively researches and discovers potential SaaS tools. Good marketing is vital.
Evaluation & Initial Adoption: The user consumes documentation, reviews, and case studies, then tries the selected tools (e.g., downloads, signs up for a free tier/trial).
The Integration Hurdle: Formal company processes begin, including security reviews, procurement, IT approval, and other checklist items. A project is started and executed to make it happen.
The Happy Outcome: The tool is successfully integrated, solving the problem effectively and leading to user satisfaction.
That "Integration Hurdle" in step 4 can be quite demanding. All depending on the specifics off course: company size, size of the problem. But in all cases, even smaller startups, there will be some form of requirements for new tools. This often translates into a checklist that every new product must effectively pass.
My Personal Checklist for SaaS Integration
Even without a formal procurement team, any company will perform some sanity checks before adopting a new tool. Based on my experiences, here's my personal checklist – the key criteria I consider when evaluating a new product for adoption:
Authentication & Authorization: How are users and permissions managed? Can it seamlessly integrate with our existing identity provider (SSO)? How do we maintain this?
Active Maintenance: Is the tool actively developed and supported? Does it receive the attention necessary to remain relevant, secure, and performant?
Data Management & Security: Where is data stored? Are sensitive components encrypted, and who holds the encryption keys? Which geographical regions can access the data, and is the tool hosted by a U.S. entity (considering implications like the CLOUD Act)?
Is the core of the product open source?: This is a significant factor for me, even if I'm not self-hosting. It speaks to transparency and potential for deeper control or understanding.
On-Premises Option: Is there an option to run parts of the product on-premises if required? This provides flexibility for specific compliance or security needs.
Vendor Lock-in & Open Standards: Can we easily transition to another tool if a superior solution emerges? Does it leverage open standards to facilitate data portability and interoperability?
Predictable Pricing: Can we accurately forecast usage costs? Is the pricing model clear and transparent, allowing for reliable budget planning?
Configuration Management: This is an area of particular interest for me. What configuration settings require maintenance? Is it critical to test these configurations? Are separate staging environments necessary and possible? What is the process if something breaks? Can track who made recent changes? Can we revert?
It's important to note that this is a broad list, and the relevance of each point can vary significantly depending on the SaaS tool's scope and the data it handles. However, I've personally experienced every single one of these points becoming a critical factor in past adoption decisions.
My Core Focus: The Configuration Conundrum
Among all these checklist items, configuration settings are where I find myself most deeply engaged (or, at times, most challenged!). I've observed a myriad of approaches to configuration management within SaaS products, and frankly, many leave room for improvement. Ideally, I'd prefer to manage all configuration directly from my own Git repositories, treating it purely as code – a concept I've come to deeply appreciate through programming and things like Infra as Code and GitOps. Some SaaS products1 have options to facilitate this: but most don’t. And let’s be honest, in the real world it’s not always worth the effort: you again grab your mouse and click together a working solution. And another SaaS tool is implemented through ClickOps. Is this wrong? It did saved you valuable time, so don’t feel guilly. But wouldnt it be fantastic if both ClickOps and GitOps could be connected?
The variations in if and how products enable automation are vast. It feels like there's a significant opportunity to advance in this area, making configuration not just possible, but genuinely easy. And did I mentioned how much time is lost by dev teams that need to create these configuration pages? And how about ‘failing’ tools because of a user that is clicking in wrong places?
Moving Forward: Beyond New Standards
As the classic XKCD comic humorously illustrates, attempting to create a new standard often simply adds another to the existing multitude. That is absolutely not the objective.
Instead, our upcoming product is designed to significantly ease the burden for engineering teams in adopting and adhering to existing best practices and standards. We are building a solution that will empower SaaS builders themselves to make their products more straightforward to integrate and manage for their own customers. Our goal is to bring much-needed clarity and efficiency to the SaaS stack.
Stay tuned – I am genuinely excited to share more about how we are addressing this challenge head-on.
Examples include the MongoDB Atlas Operator. Beyond specific operators, tools like OpenTufu and CrossPlane are designed to automate configuration management across various SaaS platforms by interacting with their APIs.