Software Buying Guide for Smaller Teams

SaaS costs scale quickly along with your team. It is easy to quickly go from almost zero to tens of thousands of dollars in monthly bills as your organisation grows.

A small team means that one person can do a lot of cross-functional things without having to think if they are stepping into someone else’s territory. This also means that one person has to make a lot of decisions and the organisation will have to carry many of them for a very long duration. It’s important to not go wrong early on in the journey.

In this post, I discuss how one should approach purchasing various software for their organisation, especially during the initial days when the foundation is being laid out. It is majorly applicable to early-stage startups (usually, pre-series B) when you are all you’ve got. You need to strike a balance between costs, flexibility, and scalability.

How the Costs Shoots Up

One new team member means one new license for `n` software subscriptions.

Confluence is free for the first 10 users, but when you onboard the 11th team member, you start paying for all 11. NewRelic is free when you store less than 100GB of data and the first five users, but costs $0.35/GB thereafter and additionally for each user license. Almost every AWS account has 10-15% of resources that are running idle and can be safely terminated. It’s easy to run into bills amounting to thousands of dollars quickly. The story is similar for most of the SaaS.

The Right Person

Not everyone on your team understands how the pricing works for various software. Not everyone understands how various software works and how they can eventually complement each other to form a well-connected machine that improves the overall efficiency of the organisation.

A person with a deep technical background, enough authority, good working relationships with people across departments, and lots of vested interest is usually the person who should be doing it. In almost all cases, this is your CTO (even if you don’t have that designation yet, you know who this is in your organisation).

Factors to Consider When Buying Software

There are multiple things to think about when you are buying something. Following are the things that help me make decisions quickly and don’t leave me regretting a lot in the future.

The Nature of Data

Think about how hard or easy it will be to switch to a competing product at a later point in time. If a product can easily be replaced later on, you can afford to pay less attention now and switch at a later point in time. However, some software are very difficult to abandon due to the nature of the data they hold. Choose them wisely.

For example, it’s not easy to migrate to a new accounting software or a cloud provider. However, you can relatively easily change your source code hosting service or your product analytics service.

Free Vs Paid

Free isn’t always cheap. Paid isn’t always what you really need.

Can you find an equivalent free alternate that you can operate without much maintenance? Go for the free stuff. However, free is not always cheap. You don’t want to spend days or weeks maintaining it. Choose wisely.

Think Mattermost vs Slack OR Jira vs Trello. Google Docs vs Confluence. We ran Mattermost for almost 3 years before switching to Slack. And frankly speaking, we shouldn’t have.

Limit to Fewer Tools ~ One vs Many

Limiting yourself to fewer tools means fewer ways to shell out money later on.

Most softwares do one task exceptionally well but also do a few more things satisfactorily. Find software that can do more than one job and use it fully. Even if they are not perfect for all the tasks, they can still get the job done. For example, GitHub’s primary job is to host your source code, but it is also a good tool for documentation and basic project management. You can easily avoid paying for Notion or Confluence or Jira and use those features on GitHub. Slack has launched Canvases, Lists this year. I find them pretty useful and regularly use them.

Avoid Lock-Ins

Avoid lock-ins as much as possible. Lock-ins can be contractual(multi-year contracts) or technical (proprietary tech where pricing scales with consumption and it’s just too much work to migrate away). Technical lock-ins are way more costly than the contractual ones. But, all of them are designed to make it hard for you to leave. Don’t trade away your flexibility for a few hundred bucks.

It doesn’t mean that all lock-ins are bad. Buying reservations for your EC2 instances is probably worth it. Entering into a one-year contract to get 30% discounts is probably fine. I’d however be uncomfortable entering a multi-year contract for an early-stage startup.

Enjoy the Perks of Running a Small Team

You aren’t operating on a petabyte scale yet. You probably don’t need 99.99% availability. You probably don’t want hundreds of integrations with other products. You may even afford to lose old data. Take advantage of all this while you still can.