Headless CMS RFP questions

A good partner starts from the content types editors actually publish, not from the page layouts. The answer should include a sample model with collections or content types, their fields, relations and the components reused across them, such as an article, author, product or event. Ask for the model as a diagram or schema file before build starts, and ask how changes are versioned in code and reviewed. Confirm whether the model is defined in code (common with Payload) or in the admin interface and exported (common with Strapi and Directus), because that choice decides how environments are promoted.

A useful role matrix lists each role, what it can create, edit, publish and delete per content type, and which locales or brands it can touch. It should also show who can administer users and permissions, and who can see drafts. Ask the partner to produce the matrix as a table before configuration, then test it with real editor accounts. Confirm which role controls are in the community edition and which depend on a paid plan, since Strapi, for example, places audit logs and review workflows in its Enterprise tier.

The answer should name the workflow stages (draft, review, approved, scheduled, published), who moves content between them, and whether scheduled publishing is built in or handled by a job. Ask how the partner records who approved what and when. Strapi's self-hosted plans list content history and releases from the Growth tier and review workflows and audit logs under Enterprise, so a buyer should confirm which edition covers each step. Ask for a test script that walks one article through every stage.

A strong answer names the preview mechanism and the front end that renders it. Typically the CMS passes a draft token or preview URL to the front-end application, which fetches unpublished versions through the API. Payload documents live preview in its admin panel, while Directus and Strapi rely on preview endpoints configured in the front end. Ask the partner which preview path each content type uses, how preview tokens expire, and how preview is kept off public caches. Confirm the approach on a staging copy of your own front end, not a demo site.

Both Strapi and Directus expose REST and GraphQL APIs, and Payload provides a REST and GraphQL layer alongside its local API, so the choice depends on the front end's needs. Ask the partner to explain the query patterns, pagination limits, depth limits and caching headers for each API. Confirm how public read access differs from authenticated write access, and whether tokens are scoped per role. Directus generates its APIs from the database schema, which changes how schema changes reach the API, so ask how that is tested.

The answer should cover where files are stored (local disk, object storage or a CDN origin), how image variants are generated, and who can upload or delete assets. Ask for the storage provider and backup plan, the maximum file sizes allowed for each content type, and how alt text and metadata fields are required. Confirm whether the chosen platform's upload provider works with your object storage, since plugin support varies by product and version. Ask how removed assets are cleaned up so storage costs do not grow unbounded.

A good answer shows whether each localized field is stored per locale in the same document or as separate entries, and how fallback to a default language works. Ask the partner to show one article in two locales with its URL and SEO fields. Confirm which localization features are included in the community edition of your chosen platform and which need configuration or plugins, and ask how translation handoff to an agency or machine translation service is tested before launch.

A partner's fee covers the work the organization cannot skip: scoping, content modeling, front-end integration, data migration and editor training. Scoping defines which content types, locales, roles and integrations are in play. Content modeling turns that scope into collections or content types, relations, validation and permissions. Front-end integration connects the API to the site or app, including preview. Migration moves existing content and media, and training prepares editors. Each line is a separate component you can ask a partner to price.

• Scoping and content model design
• Front-end integration and preview setup
• Migration of content, media and redirects
• Editor training and handover documentation

Most engagement costs are one-time: scoping, modeling, integration, migration and training. Recurring costs come from running the platform: hosting or infrastructure you pay a cloud or data center provider for, backups, monitoring, security patching, version upgrades and any ongoing support retainer. Paid self-hosted editions also recur if you need features such as single sign-on, audit logs or review workflows, and that licensing is paid to the software vendor, not DeployOpen. Ask which items recur, how often they renew and who invoices each one.

No. DeployOpen does not publish a price list, and a quote follows from a written scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a quote that lists each deliverable, the assumptions behind it and what is excluded. Ongoing support, upgrades and continuous testing are offered as retainers, so request them as a separate line item rather than assuming they are included.

Ask the partner to name the exact product, edition and plan the quote assumes, because feature access differs by tier. For Strapi, the self-hosted Community Edition is free, while Growth and Enterprise are paid plans; SSO, audit logs and review workflows sit in specific tiers, so confirm which ones your requirements need on the current pricing page. Also confirm that the quote does not include any vendor license you must buy separately, and who holds that contract. Directus and Payload have their own license terms that your legal team should review before the build.

Support boundaries define who fixes what after go-live. Ask the partner to state, in writing, which components it operates, such as the application, the content model, the hosting environment or the backups, and which remain with your team or a cloud provider. Confirm response expectations, upgrade responsibilities for major versions, and what happens when a vendor releases a new major version after handover. Support is delivered through a separate retainer, so the quote should say whether it is in scope or priced separately.

Migration effort rises with the number of content types, the volume of media, the number of locales and how much existing content needs reshaping rather than copying. Redirect mapping, editor retraining and running two systems during cutover add effort. Effort falls when the source content is clean, the content model is agreed early and the number of front ends is small. Ask the partner to list the source systems, record counts, media volume and locales used in the quote, since these are the inputs that move the estimate most.

Yes, an internal team can run the work, and many organizations split it: they keep content modeling and editor operations in house and bring in a partner for hardening, integration or migration. The trade-off is staffing and skills. Self-hosting needs people who can manage the database, Node.js runtime, backups, upgrades and access control. Ask the partner for a split proposal that shows which tasks you would own, which tasks you would hand over, and what knowledge transfer each handover requires.

Require a line-item quote tied to the written scope, with separate sections for one-time services, recurring hosting and software, and optional retainers. Ask for the assumptions behind each estimate, including the number of content types, locales, editors, integrations and migration sources. Request the named edition or plan, the support boundaries, the exclusions and the payment milestones. A quote that cannot show its assumptions cannot be compared fairly with another bid.