We need to take a moment to draw a clear distinction – especially for anybody who’s new to the world of SaaS development. The words “tool” and “platform” are often bandied about as descriptors for software types.
Sometimes interchangeably.
But these words do mean different things, and the distinction between them could mark the difference between failure and success – especially, again, for anybody just getting started.
Tools vs Platforms in SaaS
Tools are what they sound like: they have a simple purpose, and they do one thing very, very well. A knife, for instance, cuts.
Platforms, though, are like Swiss army knives. It can do multiple things and has many uses. Essentially, a platform holds many tools and binds them together.
It’s a SaaSpectrum
Now, like pretty much everything else in life, this isn’t black-and-white. A SaaS isn’t strictly a platform or tool. Effectively, there’s a scale or slider between them. As you add more elements or functionality to a tool, it gradually becomes closer to being accurately labeled as a platform; alternatively, platforms could potentially be streamlined so that they are, functionally, tools.
Facebook, as an example, is a platform – and very much not in the ‘gray’. Asana is also a platform, but it has a defined focus as a team management platform, so it is somewhere in the grayscale. So is Google Docs: with its focus being purely on collaborative and easily-shared documents, it is closer to the “tool” line than Asana, but still definitely a platform.
These are all well-established platforms, and to attempt to build something with even half of their functionality would cost hundreds of thousands of dollars because it would still be a very robust platform.
Because of this, my very firm recommendation for anybody who is making their first attempt at building a SaaS is to reign in your initial build goals and focus on making a solid, compelling tool. Don’t attempt to make a platform – the bigger and more complicated the project, the more likely it is to fail, and your first few projects will very likely fail, anyhow.
Tools Can Still Be Robust
Just because tools focus on one thing doesn’t make them “boring” or “situational”. Okay, maybe some are niche, but that’s where you’re going to find your profit – and that goes back to validation!
Take a look at Calendly, for example. All it does is help people schedule time on your calendar. That’s it. But it does a lot within that very tight, limited functionality – it connects over to your Google Calendar or iCal, includes a host of control options such as limitations on certain event types and buffers between events, integrates with a lot of other platforms well, and focuses on making meeting scheduling easy. That’s why Calendly is successful.
Having a strong focal point allows for tools to polish their strengths and make stronger arguments for themselves. They cost less to build, less to operate, and thus can entice customers with lower price points.
Good Tools Still Require a Lot of Work
Good tools still need solid UX design and functionality. If they’re not smooth and easy to use, they won’t be used and it will have all been for naught. It doesn’t have to be perfect, or even as good as an established system like Asana or JIRA – they’ve had time to iron out the kinks. For launching a new system, there are just a few things you want to focus on:
- Make it smooth and easy to navigate
- Make it load fast
- Figure out additional uses for the system so that you can anticipate user needs and optimize for them
A simple, three-point checklist. It looks easy. But once you go to build it, you’ll run into problems, and it will take a lot of time and money to complete.
So if you’re getting started, build a tool first. Don’t try to build a platform. Even if money and time were no object (we both know that they’re not), you also have an experience budget. And while you may learn a lot when you fail, it’s better to fail on smaller projects early on so that your ability to pick yourself up and try again isn’t lost.
Best of luck in your SaaS endeavors!