Basically, you’ll want to review the many apis on Trailhead; many can solve similar problems, so compre them and use the right one for the job.
There are other considerations that might guide which apis you use, more on those below:
Choose where you'll deploy the app:
The tools & Apis available to you depend on this. Pick “where” you deploy your app; This could steer which APIs you can or wish to use. Sometimes multiple apis can achieve similar results so use the right tool for the feature in question; compare the apis on Trailhead and in docs. Also consider How expensive are callouts from platformXyz to Sfdc, for example, if building that way.
How much of your app do you want built on sfdc? If you know the setup menu well then you might have good reason for building declarative features on sfdc for your app, for example. Things like defining external ids in the sfdc object manager to make integrations easier is a great way to save time and simplify the work your apis would otherwise need to handle. Same with validation rules, duplicate rules, the list of metadata to build apps goes on. Will you use Named Credential metadata (that as of Jan2021 cant be edited by subscribers of a managed package) or will you facilitate connection to sfdc another way (if part of your app is remote).
Lookup “integration patterns” on salesforce.com blogs/docs, including callins, callouts, and read their security advice)
salesforce app packaging (refer to trailhead)
if deploying your application to salesforce, then you can choose managed, unmanaged , or unlocked packaging; many devs use managed packages for paid apps so that components, classes, triggers, are intellectually hidden from subscribers (Of course front end code is delivered to browsers and cannot be reliably concealed). Read the docs on "packaging" for other differences. You'll find that salesforce "metadata" contained within a "managed package" cannot be edited by the subscriber, but some aspects can be interacted with: For example subscribers can deactivate managed Validation Rules but cannot change their definition. Subscribers can also use the Override tool in the SFDC Setup Menu to relabel managed objects/fields, which is nice if you want to whitelabel aspects of a sfdc-deployed app.
a note about managed appexchange packages
Theres an appexchange “security review” before becoming an “approved” managed appexchange app - Some benefits of passing appexchange security review are: publicity (being listed on appexchange) and that subscriber orgs can grant you support login access which helps you (the packaging org) access debug logs from their org wrt your app. Benefits of passing security review also means your managed package is grantes heightented governor limits compared to being unmanaged.
consider open source
Choosing Open source is great too, regardless of where you deploy or how you package the app, and many people publish open source salesforce apps to github!
navigate and try to predict any Limits
All stacks and apis have limits (that can change with each version) so try to explore those first, and really think about how increasing data volumes will impact your app, daily api limits, governor limits, or your installers governor limits. If your app calls the users' salesforce instance from within a managed package in the same instance then you'll enjoy reduced governor limits, generally-speaking -- as a benefit of being a managed package. If you are calling into unmanaged code you will face stricter limits shared by other unmanaged code that the installer may have built themselves, contracted to have built, etc. Read the primary docs for wherever is hosting your app. As you know, limits can change with every release; the Apex docs and trailhead can guide you around Limits, so can monitoring them in Salesforce (Apex Limits class, System Overview page, tooling api, etc) I think salesforce releases a new api version each 4 months (winter’Xx, Spring’Xx etc). If your app is deployed to salesforce you can expect the file meta to mention the api version in numerical format, as of writing its 50.0 but you can elect your files, such as classes, triggers, etc to use an earlier version if desired. Versions can have different limits/capabilities.
iirc Clari has a presence both as an Installed Package (managed app) and also their standalone webapp thats remote (not in salesforce). Ask them to clari-fy im guessing.
permissions & install experience
Make sure the permissions setup of the install process only grants what's essential, and nothing more. Its lazy app building for install guides to assume “a system admin user" to facilitate the integration and its risky because if the app is bugged it could cause problems. A better approach to planning your install experience within sfdc is to use Permission Sets, Custom Permissions, Custom Settings, and Custom Metadata which are great metadata choices for tailoring install experiences; they allow the installer some degree of flexibility too.
Which features run/require which execution modes
Consider whether install/usage requires the sfdc installer to dedicate a license to facilitate integrations, and/or if users self-auth; Plan which processes/features run on the users behalves vs in system mode such as apex running in “without sharing” mode. Plan which run in sync mode vs async mode (there are tradeoffs with respect to timing, limits, and other nuances you'll want to read in the official docs.
Dont forget to surf Known Issues Idea Exchange & SFSE & Github - in addition to official docs. In my opinion these together help immensely
Lastly, do follow the Idea exchange which lets people vote on salesforce’s SFDC GA roadmap. Some “ideas” are popular, some not; some are undelivered and over a decade old, and some are tagged as probably hitting GA soon (safe harbor); Within IdeaExchange you can often see product management discuss (safe harbor) timelines, or workarounds. Its also helpful to see what was delivered when.
Lex , Classic, both?
Afaik the apis are the same, however Lex and Classic are two different experiences, choose which you build for. Your app could support one, the other, or both; Know how they differ and keep an eye on the differences because they too can change.
Im sure I am leaving things out, so lets see what other SFSE answers come about.
