Building differentiated apps on a cloud platform - seven dos and don'ts from Sodales Solutions

I've been on my soapbox for years now: enterprise vendors overlook the power of apps built by small/creative/vertically-focused ISV partners - to their own competitive detriment.

Last week, I made that case again, via story of Sodales Solutions (2019 highlights - how Sodales Solutions builds labor relations HCM solutions on the SAP Cloud Platform).

That piece revealed what founder/president Sana Salam and her team at Sodales Solutions has overcome to build a successful Labor Relations Software suite, with 500,000+ users and counting. At the end, I snuck in Salam's tips for other aspiring partners.

But I cut that advisory short - and left aspiring app builders without some of Salam's best - and outspoken - advice. Most SaaS services firms should seriously look into app building, so I hope these seven field lessons provide motivational fuel.

---

1. Design with IT validation in mind

Anticipate the hardcore security and compliance needs of enterprise IT shops. Even though the business is buying the app, IT will validate. If you're building on a platform, whether its Oracle or SAP or Salesforce, your expertise in that platform will be thoroughly tested - especially when it comes to data and role-based security. This is Salam's number one reason why she's seen other partner apps fail. Why? She told me: 

Buying behavior is changing, but there is still a lot of fight between IT and business. So even though the business is buying, IT still comes in and validates. And when they validate, they want to make sure that the technology within the app is going to be eventually supported by the larger vendor - in our case, SAP.

This affects the tools you build with:

IT wants to make sure that this technology is supportable. The number one reason I think a lot of partners who are not successful is because they use some other third party libraries or technologies that are not supported by SAP. And even though the business team didn't care, at the time of IT evaluation, the product got dropped off.

2. Build robust apps that customers can't easily build themselves - not three-click functions.

With enterprise apps, it's a quality over quantity thing. Salam:

A lot of early SAP Store apps were like that:  two clicks/three clicks apps. And the customer says, "Why do I need to pay a licensing fee, when I can build it in three months?" So I think that was a big mistake. I developed 40+ apps that were like that, until I learned this is a mistake.

Salam knows the temptation to push an app out quickly; startup/app budgets can be tight. But she sees a better way: module by module. 

It has to be quality. And if you don't have time or money, which we didn't, to build it right away, what you can do is lower the price tremendously to get customers to buy your first module. Then roll out the second module and then the third module.

That worked out for Solades' Labor Relations Solution (LRS). They now have a full suite of LRS modules, from grievance and appeals to union job bidding.

3. Tech can be copied by others - but not your business content

Brace yourself: tech companies with deep pockets can (and will) match your tech. But there is still a way to differentiate: embed your industry expertise in the app. Salam has seen startups wrecked over this mistake:

I find that the partners who focus on the technology-only apps, which means it could be a mobile toolkit that they built, it could be an accelerator that they built, a connector that they built. Any partner who focuses on a technology-only app, another company, SAP or other players, will come up with something bigger than that, and your entire investment can be wasted. The partners who were successful are the ones who embedded business content by industry in it.

Salam made a key clarification: if you're determined to focus on tech innovation, then you'll want to consider significant seed funding, so that you can scale up your technology quickly. Sodales wanted to self-fund through growth. They focused on apps with unique business content, gleaned from their own customer requirements.

4. Hire salespeople who speak the language of industry, not tech

Salespeople who rattle off tech buzzwords won't be able to sell your app. Hire someone to sell your app that knows your industry. Salam:

If I'm selling to a plant manager, I literally need to hire a plant manager to sell my app. If I'm selling to a lawyer, I need to hire a person with a legal background to sell my app.

The customer wants to hear industry language, not tech language. Salam learned this firsthand in the SAP industry, where pushing buzzwords like cloud comes all too easily:

Don't say things like,  "Hey, we are an innovative cloud company." Customers don't want to hear that language. A lot of partners who have really good products are not able to sell, because when I see their sales and leadership team, it's all techy architect stuff, and they are speaking buzzwords. So we hired end users of labor relations, end users of health and safety to sell our products, and that has worked out really well for us.

5. Respond quickly to all prospects - even if they don't buy online.

Third party apps often struggle for full exposure during an enterprise software sales cycle. So, by the time the customer finds out about you, they could be far down the buying road. To get in, you'll need to move quickly - and you'll be judged by your response time. Salam:

They might be in the middle of an RFP, and suddenly hear about your app. You won't have long to get a demo in front of them.

Salam told me about a big customer that found them on the SAP Store. From first contact, it was all hands on deck:

By the time they contacted us, they had less than a day to evaluate our product. They sent us their scenario within a few hours, and we had to act on it.

6. Figure out the size of the idea, and the potential for growth.

Some apps are too niche, and can't be expanded to new industries or use cases. Example: LRS has expanded to new modules and new markets - expanding the functionality into enterprise health and safety.

I think it is the partner's responsibility to invest time figuring out the size of the idea... invest in ideas that have a potential for growth. Invest in ideas that have potential for growth.

Salam contrasted a security guard app, which could be expanded into security analytics, AI capabilities, and so on: "it's solving a fundamental problem." Whereas:

I see sometimes partners have a one-click approval app. How much further you can go with it? You can go with it to maybe ten or twenty features.

7. Use your best people to build your app - not just someone on the bench.

App design shouldn't be relegated to a "Hey, we should build an app too!" backup resource. Someone with the talent - and power - to move quickly should be the lead.

The person who needs to be in there is the person who cares about it, and is who going to make decisions really fast. Some of the learnings coming back to you are going to happen within hours, and you're going to need to react. 

I changed my pricing models so many times because I could make those decisions. I've seen a lot of partners fail  because they didn't put the right guy or right girl in charge of this transformation.