Mod support is the defining feature that makes something a platform rather than simply a product.
Here’s a ranked tier-list of how some of the biggest SaaS platforms are tackling mod support.
There were three major takeaways from this. (Or you can skip straight to the tier list).
The best platforms (Salesforce, HubSpot, Intercom) automatically give you a free dev instance without having to speak to anyone. The others literally make you beg or pay to help them extend their platform! Some require a LOT of paperwork, contracts, NDAs and a significant fee.
Almost every platform requires you to provision a server (strongly gatekept by IT), setup a new repo, build tooling, etc. This is kind of insane in 2024. It is SO difficult to get approval to do this in an enterprise. This requirement makes mods only realistically possible by professional system ingreators.
The best platforms simplify the local setup with a CLI.
Nobody has built a zero-setup approach: giving you a built-in editor so you can just hit an “add a custom feature” button and start instantly. (See our demo for how this can work).
There’s a false-start in mod-support which seems like a good idea but really isn’t.
Some platforms have built their own domain-specific-language. For instance Salesforce Marketing Cloud has “AMPScript”. Intercom has their XML webhook based “Intercom Apps” framework. And main Salesforce has “SOQL” (a worse version of SQL).
These are a huge mistake! I understand how these evolved, but it reminds me of that weird “WAP” mobile web that existed before the iPhone. They really are just a stop-gap.
I think the justification for these is control. But in reality it’s probably because implementing a DSL is easy and building a true Monday-style extension SDK is a very, very hard problem.
It might surprise you but Monday (the flexible project management tool) is the best I’ve seen for mod-support. I think this is a major reason for their breakout success.
Here’s why:
It’s not perfect:
Fun fact: Moddable itself is inspired by Monday’s mod-support! Monday used to run hackathon competitions. I won $5k in one of them. In this experience I was so impressed with their mod support. This definitely influenced my decision to build Moddable. (I wanted to bring those strengths but with a much easier developer experience and zero setup).
Shopify is S-tier. They are clearly a best-in-class engineering org. I could easily write pages on their approach to mod-support. It needs its own post.
They have innovated in the space more than anyone (probably including us).
Let me be clear: their approach could be improved with a zero-tooling setup. But what they have done is still VERY interesting.
Some highlights:
npm create @shopify/hydrogen@latest.Shopify seems like a modern version of Salesforce’s approach. Extremely powerful, but targeting only hardcore dev teams.
You might be asking why does Hydrogen not count as a DSL? It is a superset of React.
People think Salesforce is a CRM. It really isn’t. It’s much more the original enterprise platform for building apps.
Their strength is the power and the “correctness”. Downside is there’s so much legacy that everything is pretty clunky & requires specialized consultants. They’ve made good progress in unifying things towards “normal” standards recently.
There will never be another Salesforce. They pioneered a lot. But the world has moved on. So it has its own very unique ecosystem that sustains it through its sheer size.
HubSpot recently added UI extensions to their CRM. (This is their answer to Salesforce’s APEX.). Turns out I have a lot to say about this. It’s well done but hugely restricted: only a set of allowed components, and a huge list of limitations (even simple basic stuff just won’t work).
A note on “security” here. This is intended to help safety but it doesn’t actually stop a malicious extension from harvesting your data. It’s a bit like the TSA: it’s mostly for making you feel safer.
More importantly, they completely miss a major use-case: power users extending their own instance with one-off mods:
The needs of getting something published for the masses (strict security, review, complexity) are very different from the needs of a power user extending their own instance (speed, ease, flexibility).
Intercom’s mod support is a very, very good implementation of a fundamentally outdated method.
Looking at those pros and cons why is this just C-tier..?
I think it’s the fundamental approach. Their XML framework will only ever let you stitch together the primitives they provide you with.
The craftsmanship is excellent. It’s just the wrong method. (In fairness to them, the modern methods were not practical when they built this.)
I know Eloqua (Oracle’s marketing cloud) very well. I recommend it. Their mod support is a powerful but complex framework.
Their mod-support is very powerful. But very difficult to use.
Disclaimer/interesting note: one of my companies sells add-ons which build a code-editor into Eloqua itself to simplify building custom steps/integrations. This probably set me down the path towards eventually building Moddable!
Mod support in Salesforce Marketing Cloud was ahead of its time. But it has not aged well.
To do almost anything in this platform (even as a user) you need to write in one of their two native scripting languages: AMPScript or SSJS.
No error messages 🤮 When a program in AMPScript/SSJS fails, it simply dies. No error message. No stack trace. No logs. Nothing.
I’ve included SFMC here not to bash them - but to show the perils of implementing a DSL.
What was genuinely ahead of its time has diverged from standards and stood still while the web platform has evolved to the point it makes SFMC feel like working with punch-cards and tape.