Strapi development - the open-source, self-hosted headless CMS whose software is yours, not just the content.
Intention InfoService builds on Strapi - modelling your content types, extending the CMS in Node, and shipping the fast front end that reads it in Next.js or Astro, by a small senior team at transparent published fixed prices. Because the Community Edition is open-source and self-hosted, you own the running software, the code and the database - not just the content. Self-hosting is a real responsibility, and we say so up front. For startups, SMBs and enterprises worldwide.
Fixed price, software you own, no in-house lock-in.
- You own the code and the data
- Published fixed pricing
- Open-source, self-hosted
Strapi in 2026Open source
- License
- MIT, open-source core
- Runtime
- Node.js, React admin
- API
- REST out of the box, GraphQL plugin
- Hosting
- Self-hosted, or managed Strapi Cloud
The Community Edition is MIT-licensed - yours to read, patch, extend and self-host.
A self-hosted content backend, and the front end that reads it
Strapi is the content backend - we model your content, extend it in Node, and stand up the admin your editors use, then pair it with a front end that renders fast. A typical Strapi engagement is one of these:
Content-type modelling
The foundation: your content modelled as collection types, single types and reusable components with typed fields and relations, written to your repository and reviewable in a pull request - not trapped in a vendor dashboard.
The API, and custom Node
Strapi generates a REST API from your model (and a typed GraphQL API via its official plugin); where the generated API is not enough, we extend it with custom Node controllers, services, routes, middleware and lifecycle hooks - all TypeScript-first.
A custom admin & plugins
The admin is a React app we configure and extend - custom fields, roles and permissions, internationalization, the media library - and the plugin ecosystem covers the rest. Building React interfaces over an API is our home ground.
Self-hosted setup, and care
We deploy Strapi on infrastructure you control, on the database you choose, so you own the running software - and, because self-hosting has to be patched and kept current, we can run and update it for you on a care plan, or hand it to your team.
The front end that reads it
Strapi is the backend; the site is built on a front end that reads its API - Next.js for app-grade and SEO-critical sites, Astro for content sites - with webhook-driven revalidation so a publish refreshes only the routes that changed.
Migrations onto Strapi
Moving off WordPress or a legacy CMS onto a self-hosted headless backend: we model the target content types first, script the extract and transform, load into a non-production instance to verify, and map URLs with redirects so the SEO survives.
Strapi is the backend - here is what reads it, and when it is the wrong CMS
Strapi does not render your website; it stores your content and serves an API. The site is a front end, and sometimes a self-hosted CMS is not the right call at all - here is where each of those goes:
The front end for an app or an SEO-critical site - Next.js, the React front end over Strapi is where that build happens - server rendering, on-demand revalidation from Strapi, and the interactivity of a real application. Strapi holds the content and the API; the site is the front end.
A team that just wants to edit whole pages in a familiar admin - WordPress, the traditional page-based CMS is often the right, cheaper call - a themed admin your team knows, with plugins. Strapi is a headless backend that serves an API, not a page-editing tool.
A team that would rather never run a server - a managed, hosted CMS like Sanity is the honest choice when you do not want to patch and host anything - or Strapi's own managed Strapi Cloud. Self-hosted Strapi is for teams who want to own and run the backend; we will say so before you commit.
A hosted headless CMS hands you your content. Strapi hands you the software.
Every headless CMS gives you your content over an API. The difference is what happens to the software that serves it. A hosted, SaaS headless CMS runs the backend for you - you own what you put in, but the application stays theirs. Strapi is the one where the software is yours too: the Community Edition is open-source and MIT-licensed, so you self-host it, you control the database, and you extend it in Node. You own the running CMS, not just the content inside it. The honest flip side - because the software is yours, keeping it patched and current is yours too - is real, and we put it on the table below rather than hide it.
What owning your CMS gives you
Strapi's whole proposition is that you own the backend, not rent it. Here is what that buys you - and, honestly, when renting a managed CMS is the smarter call.
Own the running software
Strapi's Community Edition is MIT-licensed and open-source, so a self-hosted build is software you own - the code and the React admin are yours to read, patch and extend, not a hosted service you rent access to.
Own the data and the database
Your content lives in a database you control - PostgreSQL or MySQL in production, SQLite for local work - on infrastructure you run. The data is not in someone else's cloud; it is in yours, and it is yours to back up and move.
Extend it in Node, no ceiling
When the generated API is not enough, you drop into Node - custom controllers, services, routes, middleware and lifecycle hooks, all TypeScript-first. You are not waiting on a vendor's roadmap for a feature; you build it.
A real API from your model
Define a content type and Strapi generates its REST endpoints out of the box, with filtering, population and pagination; a typed GraphQL API is available via its official plugin. The contract falls out of the model, so the front end asks for exactly what it renders.
A genuinely free open core
The open-source Community Edition is free to self-host forever - no per-seat fees, no cap on API requests, admin users or content entries. A handful of advanced features live in paid editions, and we tell you which before you commit; the core is a real product, not a trial.
Host it your way
Run it yourself for full control, or use Strapi's own managed Strapi Cloud to skip the DevOps - the same open-source CMS either way. You choose where it lives, not a vendor whose only option is their platform.
When a self-hosted CMS is the wrong call
Owning the software is the upside; running it is the trade. If your team does not want to patch a server, manage deploys and keep a self-hosted app current, that is a real reason to rent instead - a managed, hosted CMS like Sanity (or Strapi's own managed Strapi Cloud) is the cleaner call, and we will say so before you spend anything. If what you actually want is a team editing whole pages through a familiar themed admin, that is WordPress. Not sure which side you are on? We will make that call with you before we quote.
From content model to a self-hosted API your front end reads
There is no Strapi running this Next.js site to point at, so the proof is the discipline. Every card is a decision you can inspect on a build we deliver - a content type in the repository, a populated query, a piece of custom Node - and we are precise about what the free open-source core gives you versus what sits in Strapi's paid editions, because that honesty is the point. Strapi is a widely adopted open-source headless CMS used by teams of many sizes; none of them are our clients, and we will not borrow their work as ours.
Collection types, single types, components
You model content in the Content-Type Builder or in code: collection types for repeatable entries (posts, products), single types for one-off global content (a homepage, settings), and reusable components composed into either. Each field is typed, and the model lives in your repository. What you check: the content model is code you own and can diff.
Relations and dynamic zones
Content types link through typed one-to-one, one-to-many and many-to-many relations, so a delete respects what still references it. A dynamic zone lets an editor assemble a page from a chosen set of components in any order. What you check: a landing page is composable blocks the editor controls, not one frozen template.
The Document Service API
Server code and plugins read and write content through the Document Service API, the current line's data layer, which works on documents - one documentId grouping an entry's draft, published version and locales - so draft & publish and internationalization are first-class. A build still centred on the older Entity Service API is a tell it is a version behind.
A REST API from the model
Define a content type and Strapi generates its REST endpoints out of the box - no hand-rolled CRUD. You shape each response with query parameters: filter on any field, select fields, populate related content and media to the depth a view needs, sort and paginate. The API contract falls out of the content model.
GraphQL via the official plugin
Install Strapi's official GraphQL plugin and the same content model is exposed as a typed graph - the same filtering, pagination and population, resolved in one query - so you can choose REST or GraphQL per surface. We tell you which fits each screen rather than defaulting to one out of habit.
Custom controllers, services, middleware
When the generated API is not enough, you drop into Node: custom routes, controllers and services, route policies, global or route-level middleware, and lifecycle hooks on create, update and publish. The current line is TypeScript-first, so extension code is typed against your model. Node and React are what we build every day - real adjacency, not a shipped-Strapi claim.
Webhooks and revalidation
Publishing and other content events fire webhooks to an endpoint you define. On a Next.js front end that call triggers on-demand revalidation, so an editor's change refreshes only the affected routes within seconds instead of a full rebuild. What you check: the publish-to-live path is wired to the pages that changed.
A React admin, and plugins
The admin panel is a React application - built with Vite in the current line, which replaced the older Webpack build - and you can customize and extend it or write your own plugin. The ecosystem adds official and community plugins for GraphQL, internationalization, users and permissions, documentation and more. A bespoke editing experience is a normal request for us.
RBAC, i18n and media - the open core
Role-based access control, internationalization for multi-locale content, and the media library are part of the free, MIT-licensed Community Edition - along with content types, the REST and GraphQL APIs, the Document Service, draft & publish, the plugin system and a full-screen content preview. We are precise about that line so you know what the open core gives you before anyone pays for anything.
Editorial at scale, named by edition
Some features sit in Strapi's paid editions, and we will not imply they are free: Content History, Releases, side-by-side live preview and Strapi's AI features - including an AI Content-Type Builder that drafts content types from a prompt - are in the paid Growth edition; single sign-on is a paid feature, and review workflows and audit logs are in Enterprise. If your team needs these, we scope the edition into the plan openly, and enable Strapi's AI as Strapi's own feature, not a proprietary offering of ours.
Self-hosted, on your database
You run Strapi on infrastructure you control, backed by the database you choose - PostgreSQL or MySQL in production, SQLite for local work. Because the Community Edition is open source, you own and control the running software itself, not only the content: the code is MIT-licensed, yours to read, patch, extend in Node and self-host. The honest operational counterweight is stated plainly in the ownership and process sections, not buried.
Front-end pairing and migrations
Strapi is the content backend, not the website: the site is built on a front end that reads its API - Next.js for app-grade and SEO-critical builds, Astro for content-first sites. Moving onto Strapi from WordPress or a legacy CMS is a defined task: model the target types first, script the extract and transform, verify in a non-production instance, then cut over with redirects so the URLs survive.
How we take on a Strapi build: model the content types and components first, because every endpoint and screen inherits from that model; wire the editorial workflow - roles, locales, draft & publish, and only the paid features you actually need - to how your team really works; extend the API in typed Node only where the generated REST or GraphQL genuinely falls short; then build the front end that reads it in Next.js or Astro. And when the real job is a team editing pages in a familiar admin, we will tell you that is WordPress, not Strapi.
This site's content runs on Sanity, not Strapi - and that is deliberate.
Our own site is a static Next.js and React build, and it does not run Strapi - not the runtime, not the admin. Here is the honest part that separates this page from our Sanity one: our own blog, guides and glossary now run on Sanity, but Strapi runs nothing here and is not going to, so this is a permanent zero, not a 'not yet.' The adjacency is real and worth stating plainly as adjacency, never as a track record: Strapi is a Node.js and TypeScript application whose admin panel is a React app, and Node and React are what we build every day - which is exactly why we can read a Strapi codebase cold. But knowing Node and React is not the same as having shipped a Strapi CMS, and we won't blur the two. And we won't show you a Core Web Vitals or Lighthouse score for a Strapi build we haven't shipped.
The depth on this page is the demo
The capability detail above is written by people who know current Strapi practice cold - content types and components, the Document Service API, REST out of the box and GraphQL via the official plugin, custom Node controllers, the Vite-built React admin, RBAC, i18n and the media library in the free core, and an honest read on which features sit in the paid editions. Dated Strapi vocabulary - a build still centred on the old Entity Service API - is how a buyer spots an amateur; ours is current, and that competence, stated as capability and never as a result we invented, is the proof that travels. Everything here is a decision you can inspect on a build we ship, not a number you have to believe.
You own the code, the data and the database
This is the ownership a hosted headless CMS structurally can't give you. Strapi's Community Edition is MIT-licensed and open-source, so with a self-hosted build you own the running application itself - not just your content, but the code, the React admin and the database it sits on, whether that's PostgreSQL, MySQL or SQLite. You host it, you control the data, and you extend it in Node. Where a SaaS headless CMS lets you own your content while it keeps the software, here the software is yours too, and you can hand the whole thing to any other Strapi developer without asking us. The honest flip side is the next card: because the software is yours, keeping it current is yours too.
Self-hosted means someone has to run it - us, or you
Owning the software is the upside; running it is the honest trade. A self-hosted Strapi instance has to be patched, hardened, deployed and kept current - Strapi ships security fixes on a rolling basis, and applying them is real work: assess it, test in staging, deploy in a window. So we put that on the table before you buy, not after. We can carry it for you on a published monthly care plan, or your own team can - and because it is standard open-source Strapi, that upkeep is portable and nobody holds it hostage, us included. You pay your own host, or Strapi Cloud, directly, with no markup from us. And if never thinking about any of this is what you want, that is a sign you want a managed option - a hosted CMS or Strapi's own managed Strapi Cloud - and we will tell you that before you spend anything.
Standard Strapi, no framework only we understand
Your content types are defined the documented way, your customizations are ordinary Node controllers, services and middleware, and the admin is stock Strapi on the mainstream npm and Node toolchain - not a proprietary layer that only works while we're in the room. Any competent Node team can read and pick it up. You talk to the engineers who model your content and write your code: no account-manager layer, no offshore hand-off, no juniors learning Strapi on your budget.
We adopt or migrate after an audit
Already running Strapi, or on a CMS you want moved onto a self-hosted headless backend? We start with a paid audit, model your content types, and map your URLs with redirects so the SEO survives - then pick the codebase up where it is, rather than rip-and-replace as a reflex. If you are mid-upgrade, we will tell you honestly what moving to the current Strapi line involves before you commit.
A registered company since 2016, senior people direct
Intention InfoService is a real, incorporated company, small and senior on purpose, so your Strapi build stays with the people who modelled it instead of rotating hands. You work directly with the engineers, at published fixed prices billed against clear milestones, with an NDA on request. For startups, SMBs and enterprises worldwide.
Honest about partners, certifications and scores
The Strapi Partner Program is real - agencies apply and are vetted, earning a Strapi Partner badge and a listing in Strapi's public partner directory - and we are not a Strapi partner and are not in that directory. Strapi does not issue an individual developer certification; the 'Strapi certificates' advertised online are third-party course-completion certificates from training platforms, not a credential Strapi grants - so we won't claim a Strapi certification we don't hold, and we won't pretend the partner program doesn't exist to dodge the question. We hold no SOC 2 report and no ISO 27001 certification, and there is no HIPAA certification for anyone to hold - and note SOC 2 is a compliance feature of Strapi's paid Enterprise edition, not an attestation we carry. We also won't show you a Core Web Vitals or Lighthouse score for a Strapi build we haven't shipped; performance is engineered on your real content and measured on your real pages after launch.
The real work behind this honesty
Our production work is two real, custom web builds - a professional-training platform rebuild and a financial-services site, both on our work page. Neither is a Strapi project, and we won't relabel them as one. What they honestly prove is the problem-shape a Strapi buyer cares about: the training platform models a large course catalog once and serves it to a fast filterable listing, templated per-city landing pages, enquiry and demo-class funnels and an admin a non-technical marketing team runs day to day, which is the same model-once, serve-many job a headless CMS exists to do. You can see the two production builds whose code the client owns outright and a team that ships real web software with real Node and front-end engineering. The Strapi-specific proof is not a borrowed case study or a partner badge we didn't earn - it is the current-standard depth on this page and the standard, self-hosted Strapi code, database and all, that you would own outright.
How we build on Strapi - model the content types first, and you own what ships
The content model is the foundation the API, the admin and the front end all sit on, so we design it before we build anything - and because you self-host it, we are honest from the start about keeping it patched and current. Most Strapi builds go from kickoff to live in weeks, not months.
Model the content types first
firstBefore any UI, we design the collection types, single types and components in the Content-Type Builder or in code, with typed fields and relations, agreed in your repo. The content model is the contract every endpoint and screen inherits from, so getting its shape right is the whole game.
Wire the editorial workflow
before contentWe set roles and permissions, internationalization, draft & publish and the media library to how your team really works - and we scope only the paid-edition features you actually need, openly, rather than surfacing them at renewal.
Extend the API in Node
in sprintsStrapi generates the REST API from your model, and GraphQL via its plugin; where that is not enough we add typed Node - custom controllers, services, routes, middleware and lifecycle hooks - only where the generated API genuinely falls short.
Pair the front end, make it reactive
the buildWe build the site on Next.js (app-grade, SEO-critical) or Astro (content-first) reading Strapi's API, and wire webhook-driven revalidation so a publish refreshes exactly the affected routes - never a full rebuild for a single edit.
Deploy, hand over, and keep it current
on deliveryWe deploy self-hosted on infrastructure you control - or on managed Strapi Cloud if you prefer - and hand you a codebase and database you own. Because self-hosting has to be patched and kept current, we can run it on a care plan or hand it to your team, tested in staging before anything ships.
Who runs the backend? Match the model to your team
We're stack-agnostic, so this is fair, not a pitch. The real choice with a headless CMS is not brand versus brand - it is who owns and runs the software behind your content.
| Self-hosted open-source (Strapi) | Hosted SaaS headless CMS | Managed (Strapi Cloud) | |
|---|---|---|---|
| Who runs the backend | You, or us on a care plan | The vendor runs it for you | Strapi runs it, managed |
| What you own | The code, the data and the database | Your content; the vendor keeps the software | The code; Strapi hosts it |
| Database control | Yours - PostgreSQL, MySQL or SQLite | The vendor's store, not yours to touch | Managed for you |
| Extend in code | Yes - custom Node, no hard ceiling | Within the vendor's plugins and limits | Yes - the same open-source Strapi |
| Maintenance | Yours, or ours on a care plan | None - the vendor patches it | Handled by Strapi |
| Cost model | Free open-source core; you pay your own hosting | A subscription, often per seat or usage | A managed-hosting subscription |
Self-hosted Strapi and managed Strapi Cloud are the same open-source CMS, hosted differently; a hosted SaaS headless CMS such as Sanity or Contentful keeps the software and rents you the backend. Payload and Directus are other self-hosted, open-source options in the same space. The deciding question is who you want running the backend, and we recommend by fit, not by a badge we hold.
What a Strapi build costs
No quote wall. A Strapi build - the content model, the API, the admin and a Next.js or Astro front end - is priced by our published web tiers, the same numbers as everywhere else. You always see the price before you commit.
Starter
1 week
A single-page site or landing page, live fast
Launch Sprint
2-3 weeks
Startups needing a fast, credible site
Growth Site
3-5 weeks
SMBs that want a lead engine
Commerce Sprint
4-6 weeks
DTC / e-commerce brands
MVP Sprint
6-10 weeks
Pre-seed / seed founders
How a Strapi build maps to these numbers
A content or marketing site on Strapi with a Next.js or Astro front end maps to the Starter, Launch or Growth tier by scope; a larger platform, custom plugins, or a migration onto Strapi is scoped as part of our web design and development service. Two honest notes on cost: our fee is for the build - Strapi's Community Edition is free to self-host, and you pay your own hosting (or Strapi Cloud) directly, with no markup from us. And because a self-hosted CMS has to be kept patched and current, ongoing upkeep runs on a website maintenance care plan - ours, or your own team's.
See full package details on pricing and our web development service.
Strapi development, answered
Is Strapi actually free, or will I hit a paywall?
Both, and here is where the line is. Strapi's Community Edition is genuinely open-source and MIT-licensed, free to self-host with no per-seat fees and no cap on API requests, admin users or content entries. The core is a real product, not a trial: content types, a REST API out of the box and GraphQL via the official plugin, role-based access control, internationalization, the media library, the plugin system, draft and publish, and the Document Service. What sits behind paid editions are specific extras - things like advanced release management, content history, live preview and Strapi's AI features, with single sign-on, review workflows and audit logs in the higher tiers. So the honest version is: the open-source core is free and yours, and you only pay if you want a specific paid-edition feature or managed hosting. Before you commit, we tell you which side of that line your feature list falls on.
Strapi vs Sanity - which should I use?
It comes down to who runs the backend. Sanity and Contentful are hosted, SaaS headless CMSs: you own your content, but the vendor runs the software and you rent access to it. Strapi's Community Edition is open-source and self-hosted: you own the running software too - the code, the React admin and the database - and extend it in Node. Pick self-hosted Strapi when owning and controlling the backend is a genuine requirement; pick a SaaS CMS, or managed Strapi Cloud, when you would rather not run infrastructure. Neither is better in the abstract, and we recommend by fit.
Strapi vs WordPress - what's the difference?
Different jobs. WordPress is a traditional, page-based CMS where a team edits whole pages through a familiar themed admin with plugins - often the simpler, cheaper choice for a single site one team maintains. Strapi is a headless content backend that serves a REST or GraphQL API to a separate Next.js or Astro front end. If your team just wants to edit pages in a familiar admin, that is WordPress; if you want structured content served to one or more front ends and a backend you own, that is Strapi.
Is Strapi good for SEO?
Strapi itself is a headless backend - on its own it renders nothing, so it has no direct bearing on SEO. SEO comes from the front end we pair with it: a fast Next.js or Astro build reading Strapi's API, with structured content, clean metadata and localization. On a migration, we protect SEO by mapping every URL, preserving metadata, and setting redirects before cutover. We claim the method, never a ranking outcome.
Do I own my data with Strapi?
Yes, and more than that. With a self-hosted Community Edition build you own both the data and the CMS software itself: you host it on infrastructure you control, the content lives in a database you choose - PostgreSQL, MySQL or SQLite - and the code is MIT-licensed and yours to read, patch and extend in Node. You own the running software, not just the content inside it, and you can move to any other Strapi developer without asking us.
Self-hosted Strapi vs Strapi Cloud - which should I pick?
A real choice, and it is the same open-source Strapi either way. Self-host it for full control and to own the whole stack, and you pay only your own infrastructure. Or use Strapi Cloud, Strapi's own managed-hosting product, to skip the DevOps - you still own the code, but Strapi runs it. Self-hosting means someone patches and maintains the server; managed hosting hands that off. We help you decide by how much operational work your team wants to own, and you pay your host or Strapi directly, with no markup from us.
Isn't self-hosting a lot of work - who keeps it patched?
Yes, honestly - self-hosting is real work, and pretending otherwise is how CMSs rot. Someone has to patch Strapi, harden the server and manage deploys; Strapi ships security fixes on a rolling basis, and each one needs assessing, testing in staging and deploying carefully. The honest options are three: we run and patch it for you on a published care plan, your own team does it, or, if you would rather never think about it, you take a managed route instead - a SaaS headless CMS or Strapi's own managed Strapi Cloud. We help you pick by fit, not by what bills us the most.
Does this website run on Strapi?
No, and unlike Sanity it is not going to. This site is a static Next.js and React build; our own blog, guides and glossary run on Sanity, but Strapi does not run here and is not on that list, so this is a permanent no, not a 'not yet.' Strapi is a Node.js app with a React admin, and Node and React are what we build every day - which is why we can read a Strapi codebase cold - but knowing Node and React is not the same as having shipped a Strapi CMS, and we will not blur the two.
Do I own the code you build?
Yes - the code is yours, and with self-hosted Strapi that ownership is unusually complete. Your content types, your custom Node controllers and services, and the standard open-source Strapi they run on all live in your repository and on your infrastructure, in a database you control. Any competent Node team can pick it up, and you can move on without asking us. Fixed pricing and code you own outright are the whole point.
Ready to own your headless CMS?
Get a fixed-price quote for a Strapi build - open-source, self-hosted, with the content model, the API and a fast Next.js or Astro front end, and code and data you own outright. And if renting a managed CMS fits your team better, we will tell you that first.