Strapi occupies a strange spot: too capable to dismiss as 'just a CMS', not quite a framework for arbitrary backends. After three years running it in production SaaS, I have opinions about exactly where that line sits.
Where it earns its keep
Content-shaped data is Strapi's home turf: marketing pages, help docs, product catalogues, anything an admin edits and users mostly read. The admin panel alone replaces weeks of internal tool development, and non-technical teammates can actually use it.
Role-based access control out of the box is the underrated feature. 'Editors can update but not publish' is one checkbox instead of one sprint.
Where it fights you
Complex transactional logic doesn't belong in Strapi. The moment your business rules span multiple entities atomically — payments, inventory, anything with a saga — you want a plain Node.js service beside it, sharing the same Postgres.
Migrations across environments remain the sharpest edge. Content-type changes made in the admin UI need discipline to move from dev to production; treat the schema files as code, review them in PRs, and never click around in a production admin panel.
My decision rule
If the data is edited by staff and read by users, Strapi. If the data is created by users and governed by business rules, custom API. Most real SaaS products need both — and Strapi coexists happily with a custom Express or Next.js API against the same database.
That hybrid is my default stack for MVPs now: Strapi for the content half, custom routes for the product half, one PostgreSQL underneath.