You were brought in to stop things breaking, so your default answer to a new platform is no, and that is the correct instinct. The argument for this one is not what it adds. It is what it lets you decommission.
Single-tenant deployment, isolated database, documented API surface your team can audit.
The pattern is familiar: a content CMS carrying dozens of third-party plugins, several unmaintained, each with its own release cadence. A marketing request for a form plugin becomes a security review. The review becomes a bottleneck. The bottleneck eventually gets routed around, and now there is shadow IT storing personal data somewhere nobody has assessed.
Meanwhile an ERP integration breaks after a platform module auto-updates, inventory drifts for three hours, and sales takes orders for stock that is not there.
Every plugin is third-party code in the request path, on someone else's release schedule.
Technical debt compounds until the platform becomes unmaintainable rather than merely annoying.
The failure you find out about from the sales team rather than from monitoring.
Single-tenant, API-first, with the storefront as a client of the same documented API your integrations use. Nothing gets special treatment, which makes the system's behaviour predictable.
Single-tenant means your database is yours alone. On a multi-tenant platform your records sit in a shared store, and a misconfiguration, theirs or another customer’s, is your exposure too.
Yes. The architecture is open and inspectable and the API surface is documented rather than reverse-engineered. You should not have to raise a ticket to find out how an integration behaves.
Present, Partial or Missing, each rating followed by the specific observation behind it. Five business days, and there is no call first.