What is a Software Platform vs a Product?

What is a Software Platform vs a Product?

platform productBlog by Bobby Bartlett

I hear the word platform thrown around a lot today in our space. It seems that every software company, especially in the CRM/ATS space, seems to call themselves a platform. I think it is misleading and cheapens solutions that are ACTUALLY a platform. A great article on Forbes titled “What’s The Difference Between A Software Product And A Platform?” by Adrian Bridgewater did a great job of getting to the bottom of the topic if you’re interested in going more into the technical and historical aspects of the topic. I will try to break this down more in terms of the staffing industry’s software solutions.

 

What is a Software Platform and What is a Software Product?

According to dictionary.com, a software platform is a noun that is a major piece of software, as an operating system, an operating environment, or a database, under which various smaller application programs can be designed to run. A software product is any delivered software solution that can be used to solve a problem. For example, the Salesforce platform, which TargetRecruit is built on, has a whole developer toolkit and language that allows developers to use tools like JavaScript, Apex, Visualforce Pages & Components, Lightning Components, and other tools to build functionality on top of what Salesforce and TargetRecruit have already built. Also, the code that you build on the platform is hosted on the same multitenant server that your TargetRecruit instance sits on. For all of our competitors that are fortunate enough to have a serviceable API, you could integrate functionality from another product into their product, maybe even use an iframe to make it appear that the 3rd party vendor’s product has integrated functionality, but ultimately that code will be hosted elsewhere.

 

Why Does This Matter?

Fair question. You might be saying right now, “Who cares? All I want is to be able to see the information from the 3rd party product in my CRM/ATS system. Where it lives does not matter to me.” If you’re thinking this, it is likely you are incorrect. Here’s why: In a perfect world you will buy an off the shelf CRM/ATS product that covers 100% of your business’s technology needs to the end of time and your recruiters will spend 100% of their time building relationships and making money. Since the world is quite imperfect, it is more realistic that your firm will need a flexible solution that sometimes needs some special sauce or a piece of functionality that is very low on your vendor’s list of priorities to build. If you buy a platform instead of a product, when you build, or “code,” the new functionality into the tool, and it is built in a consistent language and hosted on the same servers, you will be giving yourself a much better chance that when an update is pushed by your vendor in the future, your customizations will not break. For example, since Salesforce developers use the Salesforce platform’s robust developer toolkit and the code is hosted on Salesforce servers, everything is essentially kept “in-house.” 

 

On the flipside, if you or your CRM/ATS vendor are to build a one-off customization, this would need to be hosted on a separate server elsewhere (i.e. Amazon, Azure, IBM Cloud, etc.) which will mean someone is paying those hosting fees, and it is most likely going to be you in one way or another. Also, since the new code is not going to be built in a consistent language and the tool is not a platform, when the CRM/ATS vendor pushes out a new update, it is far more likely to break your custom one-off code. This reality is pretty much unavoidable.

 

Coding Yourself Into a Corner

This is a saying in the technology space for when you over-customize. Consider this scenario: Your staffing firm has a large percentage of engagements that need to be tracked under a specific purchase order (PO). The middle office portion of the CRM/ATS solution your firm uses does not track hours against a PO. This causes immense additional manual work for your team and often creates mistakes which cause your most important clients to get very upset which puts people’s jobs at risk. Your firm pays the CRM/ATS vendor or a consulting partner $200/hr to create a custom one-off to create functionality to handle PO tracking. Six months and $25,000 later, your precious new functionality is done and you now have a streamlined way to track hours against a PO. Hurray, problem solved, at least temporarily. Three months later, your CRM/ATS vendor pushes out an update without your knowledge that breaks your precious customization. Ouch! What do you do now? You’re not going to throw all that hard work and money away and risk the poor optics, right? Plus, there’s nothing too crucial that you need in this update, or at least you convince yourself of that, so you have your vendor pull the update back, which costs you $3,000. You can bury that easily in your budget though. You’ve officially coded yourself into a corner! I’ve seen this happen many times with cloud and on-premise solutions alike. The updates keep coming and you can’t possibly consider throwing your entire back office team off by going back to manually handling POs or they will all revolt. This is not a dramatization, this is a common scenario due to the lack of platform capabilities in our space.

 

Native Integrations vs API Integrations

This should probably be an article in its own right but native integrations are a hallmark of a true platform product like TargetRecruit. Most solutions today allow for 3rd party vendors to pass information through an API, which is a fine way to build an integration. This is actually how many of our partner’s integrate with TargetRecruit. Our platform also allows to connect in natively built software solutions, such as Accounting Seed (GL) DataTrim (Dupe Check), and Sirenum (Scheduling) directly into the the customer’s existing org since those solutions are also built natively on Salesforce like TargetRecruit is. We also have partners like Groove.co (sales enablement) and Essium (onboarding) that have built native integrations so their data can actually sit live in our platform. There is no one or two way data sync necessary because the integration is native so the data is real-time. Also, their functionality is undetectable within TargetRecruit in the sense that you are not looking at a different user interface within our tool when you see their functionality.

 

Should I Choose a Platform or Product?

There’s a time and place for every product I’ve seen on the market, and I do not consider TargetRecruit to be the right fit for everyone. Sometimes an out-of-the-box product works and the longer you can fit your firm into that box the better. Trying to make a “product” work like a “platform” can and has gotten many business leaders in our space into a lot of trouble though so it is something to have your antennae up about when choosing your next staffing technology solution. Am I looking at a platform or a product and even though the product fits me today, will it fit me a year or two from now? Also, how disruptive will that change to a new CRM/ATS solution be should I need to make it again sooner rather than later? These are all important questions to consider.