If you solve this and provide a great developer experience, including free sandbox accounts and a payments stack so that developers can sell plugins without needing to ever operate their own infrastructure, with namespacing to avoid compatibility problems between apps, then the ecosystem will come.
So, as we go through the multi-tenant path, what you say is very relevant and will be challenging.
Regarding custom entities and custom fields, we plan to introduce a flexible data table backed by a meta-data, quite close to what salesforce is doing ; this article is gold about how they built it: https://architect.salesforce.com/fundamentals/platform-multi.... In short, you have a data table (uuid, objectid, tenantid, field1, ..., fiel500) where fields are VARCHARs and you build your own engine on top of that. This comes with a lot of challenges such as performances (indexation), typing (we lose Typescript/GraphQL power obviously as we deal with flexible data modeling)
Regarding plugins that we want users to be able to create and to activate on the marketplace without vetting, here is the way we see it right now:
1) Front-end: serve a dedicated JS depending on what workspace you are on. Rebuild this JS when you activate / update a plugin
2) Back-end: we will need to execute the code in a separate environment. We were thinking about serverless lambdas for the cloud version and keep it local on the main server for self-hosting ; kind of allowing two drivers (lambdas + local) to execute plugin code in the codebase but using lambdas only on the the cloud).
Would love to chat a bit more about it. We will likely open a Github discussion thread in the upcoming weeks about this specific topic) so we can get the feedback from anyone interested into it
Our products use multi-tenant architecture in the form of 1 database file per company, and a single database server for everyone (by default). It's great for data isolation, as we can't accidentally leak sensitive corporate data from one company's account to another (say, a missing WHERE). It's also great for indexing, as DB queries only touch small subsets of data. And it works well for most businesses (10-100 employees). For large companies (not that many of them), if we detect a lot of activity which stresses the main database server, we have infrastructure in place to migrate them to dedicated servers, transparently to users. It's worked pretty well so far.
https://developers.hubspot.com/docs/cms/data/serverless-func...
- Monaco (embedded VScode inside the target app/platform)
- Typescript
- NPM modules
- Linting/autocomplete including custom fields/objects, so you basically know it's going to work before you even run it
- breakpoint debugging
- Version control with diff view
- Magic utilities to call the platform's own APIs in an easy typesafe way
The breakpoint debugging provides an amazing experience for the embedding app. It's pretty magic. But because the runtimes like Lambda don't ship the Inspector API we had to create a custom compiler to make it work.
We are actively looking to license this stack to other SaaS looking to build platforms.
If you want a demo leave your email and I'll reach out.
That isn't even the big challenge though. The biggest challenge is getting people to build for your platform. If a sales team uses 10+ integrations (it's honestly probably 20-50), then they will pick a platform that supports 9-10 of their integrations.
I had, at the same company, been asked to evaluate building Salesforce apps (using the custom programming language they provide) and contrasting that with building new apps on our own metadata-driven platform.
Developers hate it, business people love it. It won't be going away for lack of paying customers, that's for sure.
Fortunately there is a whole field of business devoted to this problem: go-to-market strategy. Target a niche, offer a compatible product, offer a significantly better product, offer a different product, offer a cheaper product ... the options are endless.
Not all "migration costs" are the same: to quote General Turgidson, "It is necessary now to make a choice, to choose between two admittedly regrettable, but nevertheless distinguishable, postwar environments: one where you got twenty million people killed, and the other where you got a hundred and fifty million people killed."
In the case of software migration costs, the cost of migrating away from a proprietary application-platform with zero-to-little code and data portability, will be orders of magnitude higher than the cost of migrating away from a proprietary infrastructure-as-a-service platform.
This isn't anything new: while Cloud-y platforms like SalesForce present even higher barriers to exercising our rights to data-sovereignty than what we had previously with SAP (because at least with SAP you can defenestrate the machines), it's all too similar to the 4GL vs. SQL wars of the 1990s. I honestly can't think of any orgs from then that regrets betting on a SQL-based RDBMS, while there are still companies out there depending on FoxPro, Progress, or worse...
This is also why I flat-out refuse to use Firebase.
Another hidden-cost of 4GL-like systems is that eventually they run-out-of-steam: hype fades and the vendor becomes stagnant and/or can't attract the best minds in the industry to design and build the platforms they expect others to use, so they lose whatever advantages they might have had which justified their proprietary nature - or an even more insidious version, whereby too many slow-moving companies become dependent on a particular platform that the platform's vendors have to intentionally hold-back the platform to avoid imposing too many fast-moving potentially breaking-changes (Java comes to mind...).
I'm glad to see I'm not the only one with a long memory.
Or maybe that's better described as PTSD.
> Salesforce comes in at the sales side of things,
> SAP invades as a finance app, and
> ServiceNow begins their encroachment as an IT ticketing system,
but they all wanna be THE only cloud platform your company needs.
And Microsoft through the Productivity apps? (Word, Excel...)
Do you have a moment to talk about our Lord and Savior Dynamics 365?
> Microsoft Dynamics 365 is a product line of enterprise resource planning (ERP) and customer relationship management (CRM) intelligent business applications
I don’t have any data to back it up officially, but working in the space it seems like dynamics is taking customers from their competitors (eg SAP) fast too…
Yeah, lots of botched React integrations, misuse of Serviced Workers, nightmare security roles, just to name a few daily problems you will run into when choosing Dynamics 365!
I have never used nor worked at an organization that is built on top of Salesforce.
Just a regular web dev.
You probably do. Salesforce has all kinds of different products from Workday and Slack to Mulesoft and Tableau. Salesforce starts their pipeline by solving one problem, making that work well from a business ROI perspective, and then they pitch you on another and another and another with package pricing. This is basically the Oracle model and how Larry got his blood money.
We are a very M$ bias company, hence, no slack.
I've tried twice to buck this trend at small startups. I was successful in getting the companies to use a lightweight, elegant, user-friendly, not-Salesforce CRM system when they were small (<10 people). And everyone was happy. And in both cases, as soon as the organization got large enough that the professional sales people came on board, they said "what is this garbage where is my Salesforce", and that was that.
This is a VERY hard pattern to break, unfortunately.
Can you please name these softwares?
After another client found that their Batchbook CRM solution was also being EOL'd, I started to feel like going for the biggest most well-known market-leading CRMs ends up being a good choice just from the point-of-view of data longevity and peace of mind.
I really wish 37 Signals open-sourced Highrise, or that CiviCRM or any of the other open source CRMs managed to get to a level of polish and ease of use so that I could ditch Salesforce, but I've yet to find anything that could justify such a move away from the Salesforce behemoth.
Although I agree with the general sentiment, I disagree with this. I've tried out over 100 low-code ui builder over the past year (including creatio,Corteza,ERPNext,Baserow,tadabase,appsmith,nocodb,mathesar,bubble, etc.) and so far none of them have perfected "excel like ease with the power of a database".
If anyone has any suggestions, (that's not on my list https://docs.google.com/spreadsheets/d/15Pg6y11JscBMK-PK06f7... ), please let me know!
We’ve built Lowdefy as a config webstack. Making it really easy to build web apps with yaml or json. You can also extend with npm plugins.
Lowdefy is more low level than a crm. But we’ve used it to build advanced CRMs for enterprises.
EDIT: Oops, forgot to thank you for creating this amazingly comprehensive sheet. I’m looking for a similar thing myself: a self-hostable CRM for a small team that wants some flexibility around custom fields and automation but doesn’t need most of the other common CRM features. My current plan is to try AppSmith, but there are a bunch of entries in your sheet that I haven’t seen before. Thanks again!
* Budibase https://budibase.com * ToolJet https://www.tooljet.com
They’re both more of the AppSmith/Retool sort of thing than Excel, but may be worth a look anyway.
I'm the cofounder of Budibase.
A lot of CRMs seem to evolve into general purpose platforms - Salesforce and MS Dynamics being the ones I am familiar with.