How many SaaS applications do you use frequently? If you're working for a medium-sized company, chances are, that your number of subscriptions ranges from tens to hundreds. So many, that you wouldn't know which tools people on the other end of your org are using, with dozens of inactive subscriptions that drain budgets.
This situation has gone from novel to normal in the past couple of years. Combined with a steady trend of choosing specialized tools that do one job very well (e.g. Linear) over suites that offer everything but end up unable to provide the best experience in any special use case, this led to increasing fragmentation of services used.
The average company uses more than 100 different SaaS applications, so we're not talking about a hypothetical anymore, in fact, to remedy this situation we've seen a whole new category of SaaS spend management / budgeting products emerging (ironically adding more SaaS tools to your stack).
Do you know where to find your service logs? Metrics on system health? Documentation on one of your internal services? The design draft presented for an upcoming feature? The one bug a customer reported and a team member notified you about? In short, a lot is happening in your organization, and if this is extended by another dimension of tools you are using, you can quickly lose track of what goes where.
👉 Categorize, Choose, Reuse
For most tasks you'll work on, there are a lot of services to choose from. Deciding if you should use standalone services for monitoring or use the integrated systems of your cloud provider isn't trivial. I mean, if we're using Slack all day, couldn't we just pipe all alerts and errors into there?
While this might work fine for some time, you'd quickly notice that searching becomes painful, you have a constant stream of spam, quickly transforming your idea into a nightmare.
So sticking with this example, how about we decide that all data related to monitoring, logs, and observability should be handled by one service? We're also past the point of engineering it in-house, as we want to focus on building our product instead of thinking about petabyte-scale log ingestion, so we'll happily take this opportunity.
Performing this kind of orientation process for all areas of your business where you're considering implementing a new tool will force you to think about different alternatives, opportunities to reuse existing tools, and find the best fit for your company.
It's also worth noting that there's no shame in reusing software. As long as it serves its purpose and makes sense for you, go for it! We want to decrease friction while making sure everyone knows which tools are used for different tasks. Ideally, we want to make use of the best tools while being completely mindful of our infrastructure.
To conclude, feel free to use the best tools available to you, but make sure there's a reason for using them, if there are inherent benefits of reusing an existing tool or if that would create more work than necessary, and make an informed decision. Don't try stacking up your SaaS stack like it's Tetris.
🤔 Know What You're Running
This takes us to the next point. If we know which services we run, we can communicate which software can be used, detect if we have expenses without actual usage, make sure to cancel those orphaned subscriptions, and build our stack.
While we briefly covered a new kind of product emerging, focused around monitoring SaaS spend and detecting what you invest your budget in, there's a lot of software we use for free, one-time licenses, or expenditures not covered by this software.
Even if you consider adopting some spend management software, how about starting a document to collect which tools are actively used?
How about creating and maintaining a list with tools, use cases, maybe even people using it so your team knows who to ask (don't overdo it, though, people don't want to spend their whole day as tech support for the service they tried once)?
This way, anyone on your team can check out what to use when, and if anyone ever asks you where that budget went, you'll have an overview of which subscriptions are active, can cancel those that aren't, and finally feel in control.
By the way, you're not restricted to applying this exclusively in a company context! You can monitor which tools you're using personally as well, and I'd strongly recommend doing this. Not only because it's basic budgeting, but also because you want to know where you put your data. Let's have a look at the list of tools I'm using regularly, and the exact use case:
- 📝 Notion: As a wiki, or for writing and storing my blog posts (including the one you're reading right now), I use Notion extensively. While the recent downtimes and performance issues bug me, there's no equally convenient option on the market, so Notion is staying around for a while.
- ⚡️ Linear: For tracking issues and storing tickets exclusively, Linear is the perfect application. It falls right into the type of software specialized around doing one topic well, and shines at that.
- 🐱 GitHub: Primarily for storing and sharing code, GitHub is the go-to platform for anything software development. However, I tend to avoid built-in features like issues in favor of using Linear, as this can be used by the entire org and combine product development, design, and other branches extending engineering.
- 👨🎨 Figma: Anything design is handled by Figma. Sharing designs with your team, creating reusable design systems, or performing other tasks during product development, Figma projects can be embedded in Linear and shared quickly, and working with it is a breeze.
- 💬 Slack: For direct communication, Slack is pretty much the industry standard by now. Although minimizing synchronous communication would be preferable in remote environments. You should also prevent storing any important information you need to come back to later on, as this will be pretty tedious if you need to dig through thousands of conversations
- ✍️ VisualStudio Code / JetBrains Suite / Xcode: As all other parts of the stack are covered, choosing which editor to use is mostly based on current preferences. It doesn't really matter, as you can access your repositories from anywhere, even from the cloud without any local installation.
- 🌎 Vercel: Fast deployments for my Next.js pages (including this portfolio) are pretty neat, so Vercel offers a great experience with another specialized use case: hosting pages and doing that reliably.
- 🏢 AWS: Consistency, usage-based pricing, and core services like S3 make it pretty hard to avoid using AWS. If you've got experience with it already, and aren't building a cloud-agnostic infrastructure, go for it. If lock-in is a business risk for you, that's a different strategy, of course.
- ☁️ Cloudflare: Managing all network traffic and DNS, I often use Cloudflare as the entry point of any project, as global DNS, workers on the edge, and some other features come in quite handy.
- This concludes the list, but for the sake of completeness, I'll mention that I also use boring things like file storage for images and other media.
While we've only got a list, we can extend it with active subscriptions, more service-related information, and think about if we can or should reorganize parts of our stack. Knowing you've got a problem is the first step in fixing it.
🙏 Policies For Control
As one more point, let's think about how we want to enforce boundaries between different services. We might have picked each service with a clear use case in mind: A wiki for sharing product-related knowledge, a cloud provider to deploy your code to, and so on.
For documentation on internal code I noticed repeatedly that the closer your documentation is to your code, the better it will be maintained, and this way people actually leverage it. If your documentation is archived in a drawer at the other end of the organization, do you really think anyone would use that?
Reducing friction means having clear processes in place. Do I need to assemble a list of our inventory? Goes into the company knowledgebase. Am I filing a support ticket a customer opened via email? Straight into the issue tracker. Any documentation on the library we want to share across services? As close to the code as possible.
Once you discussed and decided on the workflow most comfortable for your team, put in some effort to create the systems to assist you in the long run. And don't let things rot: Any outdated information can be disposed of, if it's not important anymore, you don't have to carry it around with you.
Maintaining company-internal systems, whether it's different services or processes, is a lot like regular chores. If you manage to create a routine, track the software you're using, and keep your team informed about what's available, ask what is no longer needed, and everyone, including your bills, will thank you.