DEV Community: Theodore Kelechukwu Onyejiaku

What Are Agent Skills and How To Use Them

Theodore Kelechukwu Onyejiaku — Fri, 13 Mar 2026 09:59:47 +0000

TL;DR

Agent Skills are an open standard for packaging reusable workflows, domain expertise, and new capabilities into portable folders that any AI agent can discover and use — think of them as "saved prompts" on steroids
Skills use a three-tier progressive disclosure model to protect the context window: only the name and description load at startup (~30-50 tokens per skill), the full SKILL.md loads when triggered, and reference files load only when needed during execution
Originally created by Anthropic, skills are now an open standard at agentskills.io, adopted by 26+ platforms including Claude, OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor, and VS Code
A skill is just a folder with a SKILL.md file (YAML frontmatter + markdown instructions) plus optional scripts/, references/, and assets/ directories — you can build one in minutes
Skills are composable: combine custom skills with built-in document skills and MCP servers to build complex, predictable workflows that produce consistent output every time

What Are Agent Skills?

If you find yourself typing the same prompt across conversations — a weekly report format, a code review checklist, a data analysis pipeline — you've already felt the problem that skills solve. Agent Skills are folders of instructions that package repeated workflows, specialized knowledge, or new capabilities for your AI agent. Instead of copying and pasting lengthy prompts every session, you write them once as a skill and reuse them across every conversation.

But skills go far beyond "saved prompts." They're an open standard originally created by Anthropic and now governed as a cross-platform specification at agentskills.io.

On December 18, 2025, Anthropic released Agent Skills as an open standard, publishing the specification and SDK for any AI platform to adopt. This means a skill you build for Claude works identically in OpenAI Codex, Gemini CLI, GitHub Copilot, Cursor, VS Code, and over 20 other platforms that have adopted the standard.

The simplest way to think about it: MCP gives your agent access to external tools and data. Skills teach your agent what to do with those tools and data.

Filesystem (left) — Skills that provide instructions and domain knowledge to the agent
Agent (center) — Contains the LLM and Tools working together
MCP Servers (right) — External tools and data connections
Subagents (bottom) — Spawned by the main agent for parallel/specialized work

Skills flow into the agent as knowledge, MCP connects bidirectionally for external capabilities, and Subagents are dispatched from the agent. This visually reinforces the point: MCP gives your agent access to external tools and data. Skills teach your agent what to do with those tools and data.

Why Skills Matter: From Prompts to Packages

The Prompt Repetition Problem

Consider a content creator who publishes blog posts every week. Without skills, every conversation starts the same way:

Paste the blog post structure rules (TL;DR section, heading hierarchy, citations format)
Paste the SEO guidelines (keyword density, meta description format, internal linking rules)
Paste the brand voice instructions (tone, audience, formatting preferences)
Paste or describe the topic and source material
Hope the output actually follows all those rules consistently

Now multiply that across a team of five writers, each with their own slightly different version of those instructions. The output quality varies from session to session and person to person.

This approach has three fundamental issues:

Context window pollution — Every piece of instruction you paste consumes tokens that could be used for actual content. The more instructions you front-load, the faster your context fills up and the higher the likelihood of degradation in response quality
No portability — Your workflow lives in your clipboard or a shared doc somewhere, not in a versioned, shareable artifact that can be installed and used consistently
No consistency — Without a standardized format, different people will interpret and paste those instructions differently, and you can never guarantee the agent follows every rule every time

How Skills Fix This

Skills address all three problems:

Progressive disclosure — Only the skill's name and description are loaded at startup (roughly 30-50 tokens per skill). The full instructions load only when the skill is triggered. Referenced files, scripts, and assets load only when needed during execution. You can have hundreds of skills installed without any impact on performance
Portability — A skill is a folder. Share it as a zip file, push it to a Git repository, or publish it to a marketplace. Since it's an open standard, it works across Claude, Codex, Gemini CLI, and every other platform that supports the spec
Repeatability — The same instructions execute the same way every time, for every team member, across every platform. In a non-deterministic system where you can never fully predict the model's output, skills provide the structure to make workflows as predictable as possible

Anthropic frames the context window as a public good — the more data you add, the more tokens you consume, the faster it fills, and the greater the risk of context degradation. Progressive disclosure is what makes skills fundamentally different from just pasting a big prompt. Skills are intentional about what information goes into the context window and what stays on disk until it's actually needed.

The Anatomy of a Skill

Every skill follows the same structure, defined by the Agent Skills Specification:

my-skill/
├── SKILL.md              # Required — YAML frontmatter + markdown instructions
├── scripts/              # Optional — executable code (Python, Bash, JS)
├── references/           # Optional — additional documentation
└── assets/               # Optional — templates, images, logos, data files

The SKILL.md File

This is the only required file. It has two parts:

1. YAML Frontmatter — metadata that tells the agent what this skill is and when to use it:

---
name: analyzing-marketing-campaign
description: ">-"
  Analyze weekly marketing campaign performance from CSV or BigQuery data.
  Use when the user asks about campaign metrics, funnel analysis, ROAS,
  or budget reallocation.
---

The name and description are the only two required fields. The name must be 1-64 characters, lowercase with hyphens, and should match the folder name. The description (up to 1,024 characters) is mission critical — it's how the agent detects when to activate the skill. Include trigger keywords and describe not just what the skill does, but when to use it.

Optional frontmatter fields include license, compatibility (environment requirements), metadata (arbitrary key-value pairs like author and version), and allowed-tools (pre-approved tool list for security-conscious environments).

2. Markdown Body — the actual instructions, as detailed as you need:

# Weekly Campaign Analysis

## Input Requirements
- Campaign data with columns: date, campaign_name, impressions, clicks, conversions
- Date range must be specified

## Step 1: Data Quality Check
- Verify no missing values in required columns
- Flag any anomalies (CTR > 20%, negative values, etc.)

## Step 2: Funnel Analysis
Calculate against these benchmarks:
| Metric | Benchmark |
|--------|-----------|
| CTR    | 2.5%      |
| CVR    | 3.0%      |

## Budget Reallocation
Only when the user asks about budget reallocation, read:
`references/budget_reallocation_rules.md`

Notice that last line — the budget reallocation rules live in a separate file that only loads when the user asks about it. That is progressive disclosure in action. Instead of cramming everything into the context window upfront, the skill tells the agent where to find additional information and when to fetch it.

Optional Directories

Directory	Purpose	Examples
`scripts/`	Executable code loaded and run on demand	Python data analysis, Bash automation, JS utilities
`references/`	Additional documentation loaded when needed	Domain-specific rules, style guides, API docs
`assets/`	Templates, images, and data files	Output templates, logos, schema files, sample data

Skills aren't limited to text — they can include scripts in Python, Bash, or JavaScript that the agent executes as part of the workflow. A PDF processing skill might include Python scripts for form extraction. A data analysis skill might include diagnostic scripts and visualization code. The agent loads and runs these only when the workflow requires it.

Where Skills Fit in the Agent Ecosystem

With so many technologies in the AI toolkit — MCP, skills, tools, subagents — understanding when to use what is essential. Here is how they all fit together:

The analogy from the course captures it perfectly: tools are the hammer, saw, and nails. Skills are the knowledge of how to build a bookshelf. The tools provide the raw capabilities (filesystem access, bash execution, API calls). Skills provide the procedural knowledge and domain expertise to use those tools in a specific, repeatable way.

Component	Role	Best For
Prompts	Atomic unit of communication	One-off instructions
Tools	Low-level capabilities (bash, filesystem, APIs)	The building blocks that power everything
MCP	Connects agents to external systems and data	Database access, Google Drive, Slack, any external service
Skills	Packaged workflows with domain expertise	Repeatable tasks, team-wide processes, predictable output
Subagents	Isolated execution with own context window	Parallel tasks, specialized analysis, fine-grained permissions

How They Compose Together

The real power emerges when you combine these components. Consider a workflow that chains three skills with an MCP server:

In this flow, the MCP server provides the connection to BigQuery. The marketing analysis skill defines how to analyze the data (benchmarks, formulas, allocation rules). The brand guidelines skill defines how things should look (colors, typography, logos). The built-in PowerPoint skill handles the document generation. Each skill loads only its own context, only when needed.

You can also dispatch subagents alongside skills. A main agent can spawn subagents — each with their own context window and specific skill access — to parallelize work. For instance, one subagent analyzes customer interviews while another processes survey data, both using the same "customer insights" skill but running in parallel. The parent agent collects and synthesizes their results.

When to Use What

Scenario	Reach For
Need data from an external database or API	MCP
Need a repeatable, documented workflow	Skills
Need to teach the agent your company's specific process	Skills
Need parallel execution with isolated context	Subagents
Need real-time access to Google Drive / Slack / etc.	MCP
Need specialized analysis that shouldn't pollute main context	Subagents + Skills
Need a one-off quick task	Just a prompt

Use skills for procedural, predictable workflows. Use subagents for full agentic logic only when necessary for specialized or parallel tasks. Use MCP for any external data or tooling. And remember — skills, subagents, and MCP are composable. The sweet spot is usually a combination of all three.

Built-In Skills and the Skills Repository

Anthropic ships several production-ready skills at github.com/anthropics/skills:

Document Skills (built into Claude AI, always active):

Skill	What It Does
Excel	Create, edit, and analyze `.xlsx` spreadsheets with formatting and charts
PowerPoint	Generate presentations with custom layouts, colors, typography
Word	Create formatted `.docx` documents
PDF	Extract text, fill forms, merge PDFs, convert to images

Example Skills (can be toggled on in Settings > Capabilities):

Skill	What It Does
Skill Creator	Meta-skill that programmatically creates new skills following best practices
Code Review	Structured code review with configurable standards
Data Analysis	Statistical analysis workflows

The skill-creator is particularly useful — it's a skill that creates skills. It includes Python scripts for initializing the folder structure, packaging into a zip, and validating against best practices. It is enabled by default and can save significant time when building new skills.

In Claude Code, you can install skills from the marketplace:

# Add the Anthropic skills marketplace
/plugins marketplace add anthropics/skills

# Verify installed skills
/skills

Partner-built skills from companies like Atlassian, Figma, Canva, Stripe, Notion, and Zapier are also available through the skills directory.

How to Build a Skill: Architecture Walkthrough

The best way to understand how all the pieces of a skill fit together is to look at a real-world example. Let's walk through the architecture of a Strapi Configuration Skill — a skill that scaffolds fully configured Strapi CMS projects with content types, seed data, public API access, and auto-populate middleware.

The goal here is not to recreate this skill step-by-step, but to understand the architectural decisions and moving parts so you can apply these patterns to your own skills. For the full source code, check out the repository.

The Directory Structure

strapi-configuration/
├── SKILL.md                  # Core instructions (480 lines)
├── CLAUDE.md                 # Development context for contributors
├── README.md                 # User-facing documentation
├── scripts/                  # Empty — reserved for future helpers
├── references/               # Empty — reserved for future docs
└── templates/                # Domain-specific data files
    ├── blog.json             # ~22KB preset definition
    ├── ecommerce.json        # ~23KB preset definition
    ├── portfolio.json        # ~25KB preset definition
    └── restaurant.json       # ~24KB preset definition

This structure shows several important patterns:

Standard directories are present even when empty. The scripts/ and references/ directories exist as placeholders — they signal to other developers (and the agent) that the skill follows the standard layout and may grow into these directories.

Domain-specific directories are allowed. The templates/ directory isn't part of the standard spec (scripts/, references/, assets/ are), but skills can include any additional directories that make sense for the domain. Here, each JSON template is a ~23KB definition containing content types, components, middleware configs, seed data, and permission rules for a specific project type.

Progressive disclosure is baked into the architecture. Those four template files total ~94KB of data. None of it loads until the agent actually needs a specific template. When the user picks "blog," only blog.json enters the context — the other three templates stay on disk. That's ~70KB of tokens saved.

The Frontmatter: Your Skill's Elevator Pitch

---
name: strapi-configuration
description: >-
  Create a fully configured Strapi project with preconfigured content types,
  seed data, public API access, and route-based middleware for default
  population. Use when the user wants to scaffold a new Strapi project for
  a specific use case such as blog, e-commerce, portfolio, or restaurant.
  Supports preset templates and custom project descriptions.
compatibility: Requires Node.js and access to the strapi-core monorepo.
allowed-tools: Bash Read Write Edit Glob Grep
metadata:
  author: strapi
  version: "0.1.0"
---

Key decisions worth noting:

The description is packed with trigger keywords: "scaffold", "Strapi project", "blog", "e-commerce", "portfolio", "restaurant", "content types", "seed data." When a user says any of these words, the agent knows this skill is relevant
compatibility declares the runtime requirements upfront — the agent (and the user) knows this needs Node.js before it even starts
allowed-tools explicitly declares which tools the skill will use. In security-conscious environments, this allows pre-authorization rather than prompting for each tool at runtime

The Instruction Body: A Deterministic Workflow

The body of this SKILL.md is structured as 9 sequential steps, each with clear entry/exit criteria. Here is the high-level flow:

[video-steps.mp4](https://delicate-dawn-ac25646e6d.media.strapiapp.com/video_steps_10379ccc12.mp4) Your browser does not support the video tag.

Several patterns make this workflow reliable:

Explicit branching. Step 1 presents a selection menu and routes to either Step 2 (preset template) or Step 2b (custom generation). The branching is clearly marked — the agent never has to guess which path to follow.

Code templates, not descriptions. Rather than saying "create a controller," the skill provides the exact TypeScript code:

import { factories } from '@strapi/strapi';

export default factories.createCoreController('api::<name>.<name>');

This eliminates guesswork and ensures the generated code actually works with the target framework. The skill includes templates for controllers, services, routes (with and without middleware), middleware files, component schemas, and the entire seed script.

Progressive file loading. Step 2 says "Read the template JSON file at templates/<preset>.json." It doesn't embed the template data in the SKILL.md — it tells the agent where to find it and what structure to expect:

The template contains:
- `contentTypes` - Collection types and single types (schemas)
- `components` - Reusable component definitions
- `middlewares` - Route-based populate middleware configs
- `seedData` - Sample data entries for each content type
- `publicPermissions` - Which API endpoints to make publicly accessible

The custom path generates data dynamically. Step 2b is a mini-workflow within the workflow — it gathers requirements, designs a content model following patterns from existing templates, generates seed data, configures middleware, sets permissions, and optionally saves the result as a reusable template for next time. This demonstrates how skills can handle both deterministic paths (presets) and creative ones (custom generation) within the same workflow.

Supporting Files: CLAUDE.md and README.md

This skill includes two additional files that aren't part of the agent skills spec but demonstrate good practice:

CLAUDE.md captures development context — the directory structure, key conventions for the Strapi schema format, CLI testing commands, common pitfalls (like draftAndPublish needing to be nested inside options, not at the top level), and future improvements. This is valuable for both the agent when it needs to modify the skill and for human developers maintaining it.

README.md is user-facing documentation — installation instructions, quick start examples, usage for each preset, and what gets generated. It explains how to install the skill at project scope (<project>/.claude/skills/) or globally (~/.claude/skills/).

What Makes This Skill Work Well

Looking at the architecture holistically, several design decisions stand out:

The description is rich with trigger keywords — the agent can match user intent to this skill reliably
Steps are numbered and sequential — there is no ambiguity about execution order
Code templates are exact, not described — pattern matching produces reliable output
Large data lives in files, not instructions — 94KB of template data stays on disk until needed
Branching is explicit — preset vs. custom paths are clearly defined
The skill stays under 500 lines — keeping the main instructions concise and deferring detail to external files
Edge cases are handled — what if no path is provided? What if the user picks custom? What if they want to save the result as a template?

Here is the skill in action.

[video-steps.mp4](https://delicate-dawn-ac25646e6d.media.strapiapp.com/video_steps_10379ccc12.mp4) Your browser does not support the video tag.

note: this is still work in progress, but once it is ready, I will share the repo here.

Best Practices for Building Your Own Skills

Based on the official specification, Anthropic's engineering blog, and patterns observed across production skills:

Naming and Description

Name: Use lowercase letters, numbers, and hyphens. Follow the verb-ing + noun pattern: analyzing-marketing-campaign, generating-practice-questions. Don't use reserved keywords like "claude" or "anthropic." Max 64 characters
Description: This is how the agent decides when to use your skill. Describe both what it does and when to use it. Include trigger keywords. Max 1,024 characters

Structure and Content

Keep SKILL.md under 500 lines. Move detailed content into references/, scripts/, or assets/
Use step-by-step instructions. Number your steps. Specify edge cases. Be clear about what to skip and why
Provide code templates, not descriptions. Agents produce more reliable output when they can pattern-match against exact examples
Use progressive disclosure aggressively. If a piece of information is only needed 20% of the time, put it in a reference file
Use forward slashes in all file paths, even on Windows

Degree of Freedom

Think about how much freedom to give the agent:

Low freedom for processes that must be followed exactly (compliance checks, data pipelines, test procedures)
High freedom for creative outputs where variety is desirable (design, writing, brainstorming)

Testing and Evaluation

Run your skill through the skill-creator skill to score it against best practices
Write test cases like unit tests: define input queries, expected behaviors, and output formats
Test across all models you plan to use — different models may interpret instructions differently
Gather human feedback and iterate

Where Skills Can Live

Scope	Location	Use Case
Project	`<project>/.claude/skills/`	Team-specific workflows tied to a codebase
User	`~/.claude/skills/`	Personal skills available across all projects
Claude AI	Settings > Capabilities > Skills	Upload as zip, available in the web UI
Marketplace	`anthropics/skills` on GitHub	Community and official skills

The Open Standard: Cross-Platform Portability

Agent Skills follow the same playbook Anthropic used with the Model Context Protocol: build a specification that solves a real interoperability problem, release it as an open standard, and let ecosystem adoption create network effects.

The platforms that have adopted the standard now include Claude, Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot, VS Code, Cursor, Roo Code, Amp, Goose, Mistral AI, Databricks, and many others — over 26 at last count. Partner-built skills from Atlassian, Figma, Canva, Stripe, Notion, and Zapier are available at launch.

The specification and reference library live at github.com/agentskills/agentskills. The reference library includes a validation tool you can use to check your skills against the spec:

skills-ref validate ./my-skill

Getting Started: Your First Skill in 5 Minutes

1. Create the folder:

mkdir -p .claude/skills/my-first-skill

2. Create SKILL.md:

---
name: my-first-skill
description: >-
  Describe what your skill does and when to trigger it.
  Include keywords that users are likely to say.
---

# My First Skill

## Steps

### Step 1: [First thing to do]
[Detailed instructions...]

### Step 2: [Second thing to do]
[Detailed instructions...]

## Output Format
[What the final result should look like]

3. Test it by starting a new session and asking a question that matches your skill's description.

4. Iterate. Run it through the skill-creator for best-practice feedback, or validate it with the reference library. Refine based on actual usage.

Whether you're automating a weekly report, encoding your team's code review process, building a project scaffolding tool, or packaging brand guidelines for consistent design output — skills transform one-off prompts into durable, shareable, composable knowledge that works everywhere.

Citations

Agent Skills Specification: https://agentskills.io/specification
Introducing Agent Skills (Anthropic): https://www.anthropic.com/news/skills
Equipping Agents for the Real World with Agent Skills: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
Skill Authoring Best Practices (Claude Docs): https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
Agent Skills Overview (Claude API Docs): https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
Agent Skills GitHub Repository: https://github.com/anthropics/skills
Agent Skills Open Standard Repository: https://github.com/agentskills/agentskills
OpenAI Codex Skills Documentation: https://developers.openai.com/codex/skills/
VS Code Agent Skills: https://code.visualstudio.com/docs/copilot/customization/agent-skills

How to Build a Strapi Plugin That Extends the Admin and Backend

Theodore Kelechukwu Onyejiaku — Fri, 13 Mar 2026 09:49:03 +0000

Whether you’re building a product solo, working with clients, or maintaining a CMS for a growing team, the starting point is usually the same.

You define content types, expose them through APIs, and consume that content in your application. Editors work in a structured interface, developers get predictable data, and the CMS stays focused on content.

That already covers a lot — but rarely everything.

Real products quickly introduce needs that go beyond content modeling: custom backend logic, admin workflows, or UI extensions that reflect how content is actually created and reviewed. When that happens, it’s important to know whether the CMS can adapt to additional requirements and scale with the product. This is about avoiding situations where small needs later force difficult architectural decisions.

This is where Strapi starts to matter.

Strapi is designed to be extended through plugins. Plugins are the mechanism Strapi provides to adapt the CMS to your project: adding backend logic, extending APIs, and customizing the admin interface when needed — without pushing those needs outside the CMS you already rely on.

In this article, we’ll make this concrete by building a small but real Strapi plugin: a todo list that integrates directly into the admin panel and attaches itself to any content type.

Let’s get started!

Installing Strapi

To get started, you'll need a Strapi project to work with.
You can follow the official quick-start guide, or simply run the following command:

npx create-strapi-app@latest my-strapi-project

Once the installation is finished you can navigate into the newly created folder and start Strapi in development mode:

cd my-strapi-project && npm run develop

When Strapi starts, it will open in your browser at http://localhost:1337/admin/auth/register-admin. The first screen prompts you to create an admin user for your application. Once that’s done, you’ll land in the Strapi admin and can start building.

At this point, you have a working Strapi project and a clean starting point for plugin development.

Bootstrapping a Strapi plugin with the Plugin SDK

After you’ve installed Strapi and created your admin user you are now ready to start developing your plugin!

Strapi provides an official plugin SDK that takes care of structure and conventions for you. From the root of your project, run:

npx @strapi/sdk-plugin init todo

This command launches an interactive CLI that asks a few questions about your plugin. Based on your answers, it generates a blank plugin inside src/plugins/todo.

Once the plugin has been bootstrapped, you can enable it by updating ./config/plugins.ts

export default () => ({
  // ...
  'todo': {
    enabled: true,
    resolve: 'src/plugins/todo'
  },
  // ...
})

With that in place, Strapi will load your plugin at startup.

Building your plugin

At this point, Strapi is running and your plugin is enabled — but there’s one important detail to be aware of before you start writing code.

When you run strapi develop, Strapi does not compile plugin code for you. Plugin code is built separately, which means that while developing your plugin you’ll need to run an additional build process.

From the plugin directory, start the watch command:

cd src/plugins/todo && npm run watch

This watches your plugin files and rebuilds them as you make changes.

This separation is intentional. In Strapi, plugins are treated as isolated units, with their own dependencies and build lifecycle, rather than as hidden parts of the main application. Keeping plugin builds explicit makes the boundary between the application and its extensions clear, and avoids coupling plugin development to the core dev process.

Creating a content type

In Strapi, everything you store is a content type. Whether it’s an Article, a Product, or a User profile, the data lives in a model with a schema — and Strapi uses that schema to generate the database structure, admin behavior, and API layer.

A plugin doesn’t change that. Even if the UI and logic live inside the plugin, the data still needs a place to live.

So if our todo plugin is going to store tasks, we need a content type for them — and we’ll define it inside the plugin, so the whole feature (UI + backend + data model) stays self-contained.

The easiest way to do this is with the Strapi generator CLI:

npm run strapi generate content-type

Running this command will open up another interactive CLI. In there you can specify the name of the content type as well as add some attributes.

When prompted:

name the content type task
add attributes: name (text) and done (boolean)
choose to add it to the existing todo plugin
allow the CLI to generate API-related files

Don’t forget to select the option to add the model to your existing todo plugin and to bootstrap API related files.

Once the generator finishes, you’ll see new files for the task content type: a schema, service, controller, and routes — all scoped to the plugin.

By default, every content type in Strapi is exposed through the Content API. That’s usually what you want: content types are meant to be queried by frontends and external consumers.

In this case, it’s not.

Tasks are an internal, admin-only concern. They exist purely to support editors while working in the admin panel, and should not be reachable from the public Content API.

For that reason, we’ll move the generated routes from the Content API to the Admin API, making the task content type accessible only inside the admin context.

To do that:

Move the generated route file src/plugins/todo/server/src/routes/content-api/task.ts to the src/plugins/todo/server/src/routes/admin folder. You will then end up with the following file src/plugins/todo/server/src/routes/admin/task.ts

/**
 * Task router
 */

import { factories } from '@strapi/strapi';

export default factories.createCoreRouter('plugin::todo.task');

Update src/plugins/todo/server/src/routes/admin/index.ts file to register those routes as admin routes

import task from './task';
export default () => ({
  type: 'admin',
  routes: [...task.routes],
});

Update src/plugins/todo/server/src/routes/content-api/index.ts to replace the content API routes with an empty definition

export default () => ({
  type: 'content-api',
  routes: [],
});

This keeps the task API private to the admin context, which is exactly what we want.

Known issue with generated routes

When generating content types with the CLI, you may run into a small TypeScript edge case when registering admin routes.

You might see an error like:

[ERROR] server/src/routes/admin/index.ts:4:15 - TS2488:
Type'Route[] | (() => Route[])' must have a'[Symbol.iterator]()' method that returns an iterator.

This is a typing issue only — the routes work correctly at runtime. You can safely fix it by adding a @ts-expect-error when spreading the routes:

import task from'./task';

exportdefault () => ({
type:'admin',
// @ts-expect-error
routes: [...task.routes],
});

Polymorphic relation

Each task should be associated with whatever content entry it belongs to — articles, pages, users, or any other type. To support that, the relation needs to be polymorphic.

In this context, polymorphic simply means the relation isn’t tied to one specific content type. A task can point to different kinds of entries, depending on where it’s created in the admin panel.

Update the src/plugins/todo/server/src/content-types/task/schema.json schema to add a morphToMany relation called related,

{
    "kind": "collectionType",
    "collectionName": "tasks",
    "info": {
        "singularName": "task",
        "pluralName":"tasks",
        "displayName":"Task"
    },
    "options": {
        "draftAndPublish": false
    },
    "pluginOptions": {
        "content-manager": {
            "visible": false
        },
        "content-type-builder":{
            "visible": false
        }
    },
    "attributes": {
        "name": {
            "type": "text"
        },
        "done": {
            "type": "boolean"
        },
        "related": {
            "type": "relation",
            "relation": "morphToMany"
        }
    }
}

At this point, the task content type has three fields:

name
done
related

That’s all we need.

Fetching related tasks with a custom admin API route

Now we need a way to fetch all tasks linked to the entry currently being edited. The catch is that Strapi doesn’t support filtering on polymorphic relations out of the box (see the FAQ).

So we’ll add a custom service method that:

looks up task IDs in the polymorphic relation table, then
fetches the matching task documents.

Open server/src/services/task.ts and extend the core service with findRelatedTasks:

/**
 * Task service
*/

import { factories } from '@strapi/strapi';

export default factories.createCoreService('plugin::todo.task',({ strapi }) => ({
    async findRelatedTasks(relatedId:string,relatedType:string) => {
        const taskIds = await strapi.db.connection('tasks_related_mph')
            .select('task_id')
            .where({
                related_id: relatedId,
                related_type: relatedType,
            });
        return strapi.documents('plugin::todo.task').findMany({
            filters: {
                id: { $in: taskIds.map(({ task_id }) => task_id) },
            },
        });
    },
}));

Next, expose this method through a custom controller action. Open server/src/controllers/task.ts and add findRelatedTasks:

/**
 * Task controller
 */

import { factories } from '@strapi/strapi';

export default factories.createCoreController('plugin::todo.task',({ strapi }) => ({
asyncfindRelatedTasks(ctx) {
    const { relatedId, relatedType } = ctx.params;
    const tasks = await strapi
      .service('plugin::todo.task')
      .findRelatedTasks(relatedId, relatedType);

    ctx.body = tasks;
  },
}));

Finally, register an admin route that calls this controller. Update server/src/routes/admin/index.ts:

import task from'./task';

export default () => ({
    type:'admin',
    routes: [
        // @ts-expect-error
        ...task.routes,
        {
            method:'GET',
            path:'/tasks/related/:relatedType/:relatedId',
            handler:'task.findRelatedTasks',
        },
    ],
});

With this in place, the admin panel can request related tasks for the current entry using a single endpoint — which we’ll use later when building the sidebar UI.

Cleaning up the admin UI

Now that the backend pieces are in place, it’s time to prepare the admin side.

The generated content type appears in the Content Manager and Content-Type Builder by default.

Because tasks are meant to be managed through the plugin UI (not as standalone entries), we’ll hide the Task content type from the Content Manager and the Content-Type Builder. You can do this by updating the schema of the Task content type at src/plugins/todo/server/src/content-types/task/schema.json:

{
    "pluginOptions": {
        "content-manager": {
            "visible": false
        },
        "content-type-builder": {
            "visible": false
        }
    }
}

The plugin also comes with its own menu entry and page. Since this plugin only adds functionality inside the Content Manager, you can remove:

the plugin icon by removing src/plugins/todo/admin/src/components/PluginIcon.tsx file
the plugin pages by deleting src/plugins/todo/admin/src/pages/ folder
the corresponding menu registration from the src/plugins/todo/admin/src/index.ts file

Creating the sidebar panel

The core of this plugin lives in the Content Manager edit view. We’ll add a custom sidebar component that will appear within the edit screen of a content document and will list all the tasks related to it.

To do so, you’ll have to create a new component in your plugin. We’ll create that at src/plugins/todo/admin/src/components/TodoPanel.tsx:

import React from "react";
import { unstable_useContentManagerContext as useContentManagerContext, type PanelComponent } from '@strapi/content-manager/strapi-admin';

const TodoPanel: PanelComponent = () => {
  return {
      title: "Todo list",
        content: (
            <div> All my todos will be here. </div>
        ),
    };
};

export default TodoPanel;

Once we’ve created the panel component we can now register it using the addEditViewSidePanel API provided by the Content Manager plugin. We do this in the bootstrap function of src/plugins/todo/admin/src/index.ts:

import TodoPanel from './components/TodoPanel';

export default {
    bootstrap(app: any) {
        app.getPlugin('content-manager').apis.addEditViewSidePanel([TodoPanel]);
    },
};

Once registered, the panel shows up automatically when editing entries.

Fetching and displaying tasks

At this point, the plugin has everything it needs on the backend:

a content type, admin-only routes, and a custom endpoint to fetch tasks related to a specific entry.

What’s missing is the admin-side logic that ties it all together.

Inside the Content Manager edit view, we want to:

fetch the tasks related to the currently edited entry,
display them inline in the sidebar,
and update their state without reloading the page.

To handle data fetching, caching, and updates cleanly, we’ll use @tanstack/react-query. It fits well here because it lets us express “this list depends on the current document” and takes care of refetching when data changes.

First, install it as a dependency of the plugin:

npm install @tanstack/react-query

Wiring React Query into the panel

React Query works through a shared QueryClient. We'll create one and wrap the panel content in a QueryClientProvider by editing ./plugin-todo/admin/components/TodoPanel.tsx, then move the task-specific logic into a dedicated TaskList component.

// ./plugin-todo/admin/components/TodoPanel.tsx

import React from 'react';
import { unstable_useContentManagerContext as useContentManagerContext, type PanelComponent } from '@strapi/content-manager/strapi-admin';
import {
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query'
import TaskList from './TodoList';

const queryClient = new QueryClient();

const TodoPanel: PanelComponent = () => {
  return {
    title: 'Todo',
    content: (
      <QueryClientProvider client={queryClient}>
        <TaskList />
      </QueryClientProvider>
    ),
  };
};

export default TodoPanel;

Fetching and updating tasks

The TaskList component is responsible for:

determining which entry is currently being edited,
fetching its related tasks via the custom admin endpoint,
rendering them as a checklist,
and updating task state when a checkbox is toggled.

// ./plugin-todo/admin/components/TodoList.tsx

import * as React from 'react';
import { unstable_useContentManagerContext, useFetchClient } from '@strapi/strapi/admin';
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';
import { Checkbox } from '@strapi/design-system';

const TaskList = () => {
  const { get, put } = useFetchClient();
  const { id, slug } = unstable_useContentManagerContext();
  const queryClient = useQueryClient();

  const { data, isLoading } = useQuery({
    queryKey: ['tasks', id],
    queryFn: async () => {
      return get(`/todo/tasks/related/${slug}/${id}`);
    },
  });

  const updateTaskMutation = useMutation({
    mutationFn: async ({ documentId, done }: { documentId: string; done: boolean }) => {
      return put(`/todo/tasks/${documentId}`, { data: { done } });
    },
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['tasks', id] });
    },
  });

  const handleCheckboxChange = (taskId: string, currentDone: boolean) => {
    updateTaskMutation.mutate({ documentId: taskId, done: !currentDone });
  };

  if (isLoading) {
    return null;
  }

  return (
    <ul>
      {data?.data.map((task: { documentId: string; name: string; done: boolean }) => (
        <li style={{ marginTop: '12px' }} key={task.documentId}>
          <Checkbox 
            checked={task.done || false}
            onCheckedChange={() => handleCheckboxChange(task.documentId, task.done)}
          >
            {task.name}
          </Checkbox>
        </li>
      ))}
    </ul>
  );
}

export default TaskList;

At this stage, the request to /todo/tasks/related is working — but the list is empty. That’s expected: we haven’t created any tasks yet.

Creating tasks from the admin panel

To add tasks directly from the Content Manager, we’ll use a modal built with the Strapi Design System.

The modal contains a small form that:

captures the task name,
associates it with the currently edited document,
creates the task through the plugin’s POST route,
and refreshes the task list when the operation succeeds.

Create a new component at admin/src/components/TodoModal.tsx:

// ./plugin-todo/admin/components/TodoModal.tsx

import { useState } from 'react';
import { Button } from '@strapi/design-system';
import { Field } from '@strapi/design-system';
import { Modal } from '@strapi/design-system';
import { unstable_useContentManagerContext, useFetchClient } from '@strapi/strapi/admin';
import { useMutation, useQueryClient } from '@tanstack/react-query';

type Props = {
  isOpen: boolean;
  onOpenChange: (open: boolean) => void;
}

const TodoModal = ({ isOpen, onOpenChange }: Props) => {
  const [taskName, setTaskName] = useState('');
  const { id, model } = unstable_useContentManagerContext();
  const { post } = useFetchClient();
  const queryClient = useQueryClient();

  const createTaskMutation = useMutation({
    mutationFn: async (data: any) => {
      return post('/todo/tasks', { data });
    },
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['tasks', id] });
      setTaskName('');
      onOpenChange(false);
    },
  });

  const submitForm = () => {
    createTaskMutation.mutate({ 
      name: taskName, 
      related: [{
        __type: model,
        id,
      }],
    });
  };

  return (
    <Modal.Root open={isOpen} onOpenChange={onOpenChange}>
      <Modal.Content>
        <Modal.Header>
          <Modal.Title>Create task</Modal.Title>
        </Modal.Header>
        <Modal.Body>
          <Field.Root name="task" required>
            <Field.Label>Task</Field.Label>
            <Field.Input 
              value={taskName}
              onChange={(e: React.ChangeEvent<HTMLInputElement>) => setTaskName(e.target.value)}
            />
          </Field.Root>
        </Modal.Body>
        <Modal.Footer>
          <Modal.Close>
            <Button variant="tertiary">Cancel</Button>
          </Modal.Close>
          <Button 
            onClick={submitForm} 
            loading={createTaskMutation.isPending}
            disabled={!taskName.trim() || createTaskMutation.isPending}
          >
            Confirm
          </Button>
        </Modal.Footer>
      </Modal.Content>
    </Modal.Root>
  );
}

export default TodoModal;

The important detail here is the related field: we attach the task to the current document using its model type and ID, which makes the polymorphic relation work seamlessly across content types.

Connecting everything in the panel

Finally, we add a button to the sidebar panel that opens the modal and renders the task list below it:

// ./plugin-todo/admin/components/TodoList.tsx

import * as React from 'react';
import { unstable_useContentManagerContext as useContentManagerContext, type PanelComponent } from '@strapi/content-manager/strapi-admin';
import { TextButton } from '@strapi/design-system';
import { Plus } from '@strapi/icons';
import TaskList from './TodoList';
import {
  QueryClient,
  QueryClientProvider,
} from '@tanstack/react-query'
import TodoModal from './TodoModal';

const queryClient = new QueryClient();

const TodoPanel: PanelComponent = () => {
  const [modalOpen, setModalOpen] = React.useState(false);
  const { id } = useContentManagerContext();
  return {
    title: 'Todo List',
    content: (
      <QueryClientProvider client={queryClient}>
        <div>
          <TextButton
            onClick={() => setModalOpen(true)}
            startIcon={<Plus />}
            disabled={!id}
          >
            Add todo
          </TextButton>
          {id && (
            <>
              <TodoModal isOpen={modalOpen} onOpenChange={setModalOpen} />
              <TaskList />
            </>
          )}
        </div>
      </QueryClientProvider>
    )
  }
}

export default TodoPanel;

With that in place, the plugin comes together:

tasks appear next to content,
tasks can be created and updated inline,
and all the logic stays scoped to the plugin.

Refreshing the admin panel now shows a fully functional todo list embedded directly in the Content Manager.

Deploying to production with Strapi Cloud

So far, everything we’ve done has been running locally. The final step is making sure the plugin is built and available in production — and then actually seeing it live.

Because plugin code is built separately from the main Strapi app, it needs to be compiled as part of the deployment process. A simple way to ensure this happens automatically is to add a postinstall script to the root package.json of your Strapi project:

{
    "scripts":{
        "postinstall":"cd src/plugins/todo && npm install && npm run build"
    }
}

This guarantees that whenever your project installs dependencies — locally, in CI, or in production — the plugin is installed and built as well.

If you’re using Strapi Cloud, you don’t need any additional setup.

Once your project is connected to Strapi Cloud, every push triggers a deployment where dependencies are installed and build steps are executed. With the postinstall script in place, your plugin is compiled automatically during that process.

After the deployment finishes, open your Strapi Cloud project, navigate to the Content Manager, open any entry, and you should see your todo sidebar panel — just like in local development.

At this point, the plugin is running in production, inside the same admin your editors use every day.

GitHub Repo

The complete code can be found here: https://github.com/strapi-community/plugin-todo

Final words

This plugin is intentionally small, but it mirrors how real Strapi extensions are built and shipped.

You defined a data model, scoped it to a plugin, exposed only the APIs you needed, and extended the admin interface where editors actually work. Nothing lives outside the system, and nothing special is required to deploy it.

That’s the core idea behind Strapi plugins: they let you adapt the CMS to your product without turning customization into a separate project.

If you want to explore further, the full plugin code is available on GitHub, and the Strapi community is always a good place to go deeper — whether you’re refining an internal workflow or building something meant to be reused by others.

Building Production-Ready Strapi + Next.js 16 Applications: Lessons from NOTUM Technologies

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:56:51 +0000

TL;DR

Who: NOTUM Technologies is a digital agency based in Brno, Czech Republic, and has been a Strapi partner for 5+ years.

What: They created an open-source Next.js + Strapi starter template that saves 3-4 weeks of development time per project.

Key Highlights:

Monorepo architecture with full TypeScript type safety between Strapi and Next.js
Supports projects from small startups to enterprise clients with billions of visitors
Includes automatic page hierarchy with recursive full-path generation
Built-in redirect management when page structures change
Docker-ready deployment for any platform (Azure, AWS, Heroku, etc.)
Uses PNPM for better dependency management and smaller build sizes
Server-side populate logic to avoid frontend complexity and URL length limitations

Notable Plugins Created: Location picker for maps, Record locking for multi-user editing

This article is based on the follwing discussion. Just in case you don't have the time to watch you can do a quick read instead.

Introduction: From Pain Point to Production Solution

Every agency knows the struggle: a new client comes in, and you're starting from scratch—again. Copy the old project, strip out the irrelevant components, implement new ones, and hope you haven't introduced any bugs along the way. For NOTUM Technologies, this cycle became unsustainable once they hit a critical mass of clients.

The solution? A comprehensive starter template that distills years of production experience into a single, battle-tested package. But this isn't just another tutorial project—it's the foundation that has powered enterprise applications serving billions of visitors.

Why Strapi? A Five-Year Partnership

NOTUM's journey with Strapi began around 2018-2019 when they were evaluating CMS options. After extensive internal discussions, Strapi emerged as the winner for several compelling reasons:

Flexibility at Scale: Strapi works beautifully out of the box for simple websites, but it also allows deep customization through plugins and custom code. This dual nature makes it suitable for the wide variety of projects an agency encounters.

Plugin Ecosystem: NOTUM has contributed significantly to the Strapi ecosystem, creating plugins like the location picker (for map-based selection and proximity filtering) and record locking (preventing users from accidentally overwriting each other's changes).

Community Building: Beyond code contributions, NOTUM actively nurtures the local Strapi community through in-person meetups, including a V5 launch party. These gatherings provide valuable opportunities to share learnings and collect feedback directly from Strapi's team.

The Architecture: Why a Monorepo?

One of the most consequential decisions in the template is its monorepo structure, powered by Turborepo. This wasn't a trendy choice—it was driven by a real technical need.

The Type Safety Problem

Strapi doesn't automatically expose TypeScript types to frontend applications. In traditional setups, developers either manually maintain duplicate type definitions or accept the risk of runtime errors when schemas change. Neither option scales well.

By using a monorepo, NOTUM solved this elegantly: auto-generated types from Strapi are exposed to the entire workspace. When you change a content schema, those changes automatically propagate to the frontend application. No more runtime surprises, no more manual syncing.

note: the Strapi team actively is working on improving DX experience to allow users to expose Strapi types to their frontend project. We will keep you posted with updates.

Package Structure

The monorepo contains two main workspaces:

Apps Workspace:

strapi - The backend CMS application
ui - The Next.js frontend application

Packages Workspace:

Shared ESLint and TypeScript configurations
A shared data package for configuration variables (like supported locales)
The Strapi types package (recently separated to reduce build dependencies)
Design system with Tailwind configuration

This structure means you have a single source of truth for everything from linting rules to locale configurations.

Why Next.js 16? The Jack of All Trades

While the template specifically chose Next.js 16 for the frontend, the decision came from practical experience rather than hype.

Versatility: Agencies encounter everything from statically generated marketing sites to dynamic admin dashboards. Next.js handles all these use cases with the same framework.

Team Adoption: React's dominance in the job market means easier hiring and onboarding. The entire team could standardize on one framework.

Enterprise Deployment: Despite internet discourse about Next.js being tied to Vercel, NOTUM has successfully deployed to Azure, AWS S3, Heroku, and other enterprise hosting platforms without significant issues.

The recent migration to Next.js 16 and React 19 did require switching from Yarn v1 to PNPM (due to multiple React version requirements with Strapi still on React 18), but this change actually improved build sizes and developer experience.

The Editting Experience: Where V5 Shines

The template's primary focus is creating an exceptional page editing experience, both for developers and content editors.

Strapi V5's preview and content history features were game-changers here, solving the long-standing headless CMS problem of not seeing what you're editing.

Automatic Page Hierarchy

One standout feature is the automatic full-path generation system. Instead of manually managing URL paths, the template uses a parent-child relationship system:

Create a root page (the homepage)
Create child pages with just a slug and parent reference
The system automatically computes full paths recursively
Change any slug in the hierarchy, and all child paths update automatically

This isn't a plugin—it's built using Strapi's lifecycle hooks and the DB query builder. The implementation required some SQL magic since lifecycle hooks don't always provide references to current relation versions, but the result is seamless path management.

Automatic Redirects

When page paths change, the system automatically generates redirect entries. No more broken links when restructuring your site's information architecture.

Solving the Population Problem

Anyone who's worked with Strapi at scale knows the populate challenge. With dynamic zones containing dozens (or hundreds) of components, the populate object becomes unwieldy.

The URL Length Limit

Here's a problem most tutorials don't mention: when you have many components, your populate query parameters can exceed URL length limits. The frontend simply cannot request everything it needs.

Server-Side Population

NOTUM's solution moves population logic to Strapi itself using document middleware:

The middleware detects specific request patterns (like fetching a single page)
It checks for a custom middleware_populate query parameter
If conditions are met, it replaces the client's populate object with a pre-defined server-side version

This approach keeps the frontend lean, avoids URL length issues, and provides a security benefit—you explicitly control what data can be populated.

They originally used the popular "populate deep" plugin but abandoned it due to performance issues at scale.

You can also accomplish this via route middleware to allow route based population, you can learn more about it here

Developer Experience Features

Scripts for Common Tasks

The template includes utility scripts for developer quality of life:

Remove all node_modules across the monorepo
Clear build caches for all applications
Quickly reset to a clean state when dealing with stale cache issues

GitHub Integration

Husky for commit message formatting (enforcing company-wide standards)
GitHub Actions for build verification
Dependabot configuration for automated dependency updates

VS Code Configuration

Recommended extensions and workspace settings come pre-configured, though this area continues to evolve.

Real-World Deployment

The template ships with Docker support for maximum deployment flexibility. This wasn't added for theoretical completeness—it came from actual enterprise client requirements.

Tested Platforms:

Azure (used extensively on multiple projects)
AWS S3 (for statically generated applications)
Heroku (for teams preferring simpler deployment)

The containerized approach means you're not locked into any specific hosting provider, a crucial requirement for enterprise clients with existing infrastructure preferences.

This a super power of Strapi, you can decide where and how you want to deploy it. My favorite place is Strapi Cloud. But you can decide which approach works best for you.

Lessons Learned: Strapi V5 Lifecycle Gotchas

NOTUM offered valuable feedback for developers diving deep into Strapi customization:

Lifecycle Changes in V5: The introduction of content history changed how lifecycles work. Publishing a new version now triggers the create lifecycle, which can cause unexpected behavior if you're not prepared for it.

Relation Data Availability: When making adjustments that don't change relations, those relations won't be present in the lifecycle payload. This is technically correct but not always obvious.

Admin Panel vs API Payloads: Calling the same endpoint from the admin panel versus a custom API client produces different lifecycle payloads. This inconsistency can trip up even experienced developers.

The takeaway isn't that these behaviors are wrong—they often have valid technical reasons—but they're not always well documented. NOTUM recommends approaching lifecycles with caution and always checking actual behavior against assumptions.

note: Did you know, you can alway provide feedback and feature request here or continue the conversation in GitHub discussions.

AI-Assisted Development: The Evolving Workflow

NOTUM is actively exploring AI integration in their development workflow, particularly for documentation:

Building an internal knowledge base in Markdown
Experimenting with AI agents that understand the template's specifics
Working toward publishable "skills" for AI tools that understand their codebase

Their philosophy aligns with broader industry observations: there's no one-size-fits-all AI workflow. Each developer should find what makes them productive rather than copying someone else's setup.

Getting Started

The template is designed for quick setup:

Clone the repository
Ensure you're using the correct Node version (the repo includes version configuration)
Run pnpm install
Start Docker (required for the database)
Run pnpm run dev:strapi to start the backend
Create an API token in Strapi's admin panel
Add the token to your Next.js .env.local file
Run the frontend

Check out this video on how to set the project up.

Conclusion: Why Templates Matter

The difference between a tutorial template and a production template is measured in months of real-world usage. NOTUM's starter represents the accumulated wisdom from dozens of client projects, from startup landing pages to enterprise applications.

Every time they complete a project—or even mid-project when something important emerges—they backport those learnings into the template. This continuous improvement cycle means you're not just getting a starting point; you're getting a documented history of what works (and what doesn't) in production.

Whether you use the template directly or study it as a reference for your own architecture, there's value in learning from a team that has shipped—and maintained—this stack at scale.

You can also checkout out our official Strapi Stater project called Launchpad

Resources

NOTUM Technologies: For companies needing development partners with deep Strapi expertise
GitHub Repository: Open-source starter template (link in video description)
Strapi Community: Join local meetups to connect with other developers

Did you know?
Strapi hosts Open Office Hours on Discord Monday through Friday at 12:30 PM CST (running until about 1:30 PM CST). It's a great way to connect, get help, and share your feedback directly with the team.

This article was created based on a conversation with Dominic from NOTUM Technologies about their Next.js + Strapi starter template.

Originally published at strapi.io

Building Native Apps With Expo and React Native

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:52:43 +0000

This post is based on our livestream conversation with Kadi Kraman, Developer Experience Engineer at Expo.

TL;DR

Expo is the Next.js of React Native — it handles all the complex native tooling so you can focus on building your app
Start with Expo Go for learning and prototyping; switch to development builds for production (no limitations)
CNG (Continuous Native Generation) means you never commit native folders — they're auto-generated and disposable
React Native renders actual native components, unlike Flutter which draws its own UI
Three styling options: Built-in StyleSheet, NativeWind (Tailwind), or Unistyles (best for theming)
EAS services handle building, submitting, and updating your apps — no Mac required for iOS builds
You can write server code directly in your React Native app with +api.ts files
Meta officially recommends Expo for React Native development

Why Choose Expo for Mobile Development?

Think of Expo as the Next.js of React Native. Just as you wouldn't manually configure Webpack and bundlers when building a React web app, Expo eliminates the complexity of native mobile development tooling.

The Problem Expo Solves

React Native by itself is a toolkit of APIs and a JavaScript runtime, but it doesn't provide a complete framework for building apps. For example, navigation between screens isn't included out of the box.

Without Expo, you'd need to:

Manually configure native build tools (Xcode, Android Studio)
Research and choose from dozens of libraries for basic functionality
Manage native iOS and Android folders manually
Handle complex upgrade paths when React Native versions change

What Expo Provides

Expo is a collection of libraries, utilities, bundlers, and a complete ecosystem that makes building React Native apps pleasant and straightforward. Key benefits include:

Expo SDK: A curated set of native libraries guaranteed to work together (video, audio, haptics, push notifications, etc.)
Expo Router: File-based routing similar to Next.js
Expo Go: Test your app instantly on your phone without building native binaries
CNG (Continuous Native Generation): Native folders are generated automatically and can be thrown away and regenerated

React Native vs. Flutter: Understanding the Difference

A common question is how React Native compares to Flutter. The key distinction is in rendering: Flutter renders on Skia (a graphics engine), essentially drawing its own UI that hooks into native APIs. React Native, on the other hand, renders actual native components. When you build a button in React Native, it's a real native button, not a simulation. This is why React Native apps are often described as "native apps" — because they truly are.

Getting Started: Expo Go vs. Development Builds

Expo offers two approaches for development, each suited to different stages of your project.

Expo Go: Perfect for Learning and Prototyping

Expo Go is an app you download from the App Store or Play Store. It contains pre-built native code for the most common libraries, allowing you to start developing immediately without any native build tools. Simply write JavaScript/TypeScript, and your code runs instantly on your device.

Best for: Learning React Native, rapid prototyping, hackathons, and getting that first "app on your phone" moment. This instant feedback loop is why many AI-powered app builders (like Replit) use Expo under the hood.

Limitations: Not all libraries are included. Some Expo SDK libraries (like expo-video) and third-party packages won't work in Expo Go.

Development Builds: Production-Ready Flexibility

When you're ready for production or need libraries not included in Expo Go, you switch to development builds. Instead of using the Expo Go app, you create your own native shell with exactly the libraries you need.

Best for: Production apps, custom native code, any library from the React Native ecosystem.

Key insight: There are no limitations with development builds. Once you move past Expo Go, you have full access to native code. You can even write custom native modules in Swift or Kotlin using the Expo Modules API.

Continuous Native Generation (CNG): The Secret Sauce

One of Expo's most powerful features is CNG (also called "prebuild"). Traditional React Native development requires you to commit and maintain iOS and Android folders, managing native code directly. With CNG:

Your native folders are git-ignored
They're generated automatically from your package.json, app.json, and node_modules
Upgrades become trivial: delete the native folders, regenerate with new versions

If you need to modify native configuration (like editing Info.plist or the app delegate), you create config plugins instead of editing files directly. These plugins run during generation, making your changes repeatable and testable.

Styling Your App: Three Approaches

Coming from web development, you might wonder about styling options. React Native offers several approaches:

Approach	Description	Best For
StyleSheet (Built-in)	React Native's built-in styling API. Can be verbose for theming.	Projects that want zero dependencies
NativeWind	Tailwind CSS for React Native. Familiar utility classes.	Web developers wanting quick start
Unistyles	Like StyleSheet but with better theming support (light/dark mode).	Apps needing robust theming

Pro tip: If you want your app to look distinctly "native" rather than like a website, study the Apple Human Interface Guidelines and Google Material Design specs. Expo UI (currently in beta) is also exposing more native components like segmented controls and glass buttons.

Deployment: From Code to App Store

Deploying mobile apps is fundamentally different from web deployment. You need to handle code signing (certificates and provisioning profiles) and pass through a manual review process. Expo offers several services to streamline this:

EAS Build: Cloud-based CI/CD that builds your native apps. Particularly valuable because you need a Mac to build iOS apps — EAS Build provides that infrastructure.
EAS Submit: Uploads your built apps to the App Store and Play Store. Free to use and essential since Apple requires specific tools (Transporter) to upload apps.
EAS Update: Push JavaScript updates without going through app store review. Fix bugs instantly.
Expo Launch: A new beta product that takes a GitHub repo and handles everything — building, signing, and submission. Currently supports public repos and iOS (Play Store coming soon).

Writing Server Code in Your React Native App

A powerful recent addition is the ability to write API routes directly in your React Native codebase. Create files ending in +api.ts in your source folder:

// src/posts+api.ts
export function GET() {
  return Response.json({ message: "Hello from server!" });
}

Environment variables without the EXPO_PUBLIC_ prefix are only accessible in these server routes, keeping your secrets safe. Deploy with EAS Hosting and you have a full-stack mobile app with backend API routes.

AI-Assisted Development with Expo

The Expo ecosystem is particularly well-suited for AI-assisted development. With Expo Go's instant feedback loop, tools like Replit and various AI coding assistants can help users go from idea to working app in minutes.

However, there's an important distinction between "vibe coding" (letting AI write everything) and AI-assisted development. Even when using AI tools, you still own the code and are responsible for testing, iterating, and ensuring quality. AI can give you a starting point, but professional development still requires understanding what the code does.

Resources like MCPs (Model Context Protocols), cursor rules, and Claude rules allow experts to codify best practices that AI tools can use as a source of truth — resulting in much higher quality generated code than generic training data.

Coming Soon: Performance Observability

Expo is developing an observability product for monitoring app performance — think Lighthouse scores but for native apps. You'll be able to track metrics like JavaScript bundle load time, see how different app versions affect performance, and identify slow devices or sessions.

Quick Start Checklist

Install Node.js and create a new project with npx create-expo-app@latest
Download Expo Go on your phone for instant testing
Run npx expo start and scan the QR code
Read the Expo docs (docs.expo.dev) — they have an AI assistant built-in
Check React Native Directory (reactnative.directory) for community libraries

Additional Learning Resources

To continue your learning journey, here are some excellent resources:

Video Resources

Full Stack React Native Course by Tube Guruji: A comprehensive 4+ hour course building a local business directory app from scratch using React Native, Expo, and a full backend. Perfect for hands-on learning.

Written Tutorial

Building a React Native App with Expo and Strapi: A Complete Guide: A detailed step-by-step tutorial from the Strapi blog covering project setup, NativeWind styling, data fetching with React Query, and building a complete blog app with infinite scroll. Read it here.

Conclusion

Expo has transformed React Native development from a complex, native-tooling-heavy process into something that feels almost as simple as web development. For React developers, there's never been a better time to start building mobile apps.

The key takeaways: Start with Expo Go for learning, graduate to development builds for production, embrace CNG to avoid native folder maintenance, and leverage EAS services for painless deployment. With these tools, you can go from idea to app store in record time.

Meta officially recommends Expo for React Native development, and it's clear why: the developer experience is exceptional, the ecosystem is mature, and the path from prototype to production is smoother than ever.

Happy building!

Originally published at strapi.io

Bye 2025, Hello 2026! A year in review

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:49:08 +0000

We’ve just wrapped up 2025 - and what a year it has been!
As we do every single year, let’s take a moment to celebrate all the achievements of the past 12 months, and share what’s coming next!

Before we go through the details, to all of you who have used Strapi: thank you! By being part of the community, you have contributed to elevating the Strapi open-source project to:

70K+ stars on GitHub (add yours!)
36K commits
9.4K pull requests merged
Thousands of customers, including Adidas, Airbus, Amazon, Cisco, Tesco, Toyota, PostHog, and CodeRabbit

These milestones are especially meaningful, as Strapi turned 10 this year!

12 months ago, we shared that we would focus on the Side Editor, the New Cloud Plan, the JavaScript/TypeScript SDK, the AI tools, and the first in-person StrapiConf. And that is exactly what we delivered!

Product improvements

More than ever before, the Strapi community shipped.

Strapi AI

AI is changing everyone’s job. You have to disrupt yourself, and so do we. Content Management Systems sit at the intersection of Developers and Marketers, who both have to reinvent their jobs with code generation (vibe coding and AI coding) and content creation (gen AI). The way CMSs are used continues to evolve at an incredible pace. What an exciting time to be building!

This is why we invested heavily in AI. In 2025, we unveiled a suite of strategic product enhancements designed to accelerate both developer workflows and content editor experiences.

AI Content-Type Builder

It all started with the AI Content-Type Builder that we announced at StrapiConf (see below). With the brand new AI Content-Type Builder, you can generate content types and components from natural language prompts or uploaded frontend apps/Figma designs. This eliminates redundant tasks, saving days of development time.

AI Media Library

Creating alt text and captions is another repetitive -and often overlooked- task. The AI Media Library handles this automatically whenever you upload an asset.

Your browser does not support the video tag.

AI Translations

If you manage a website in multiple languages, translating content can be a lengthy, costly, and error-prone process. The AI Translations feature has you covered. When enabled, it automatically translates your content into all the locales you selected. This marks an important step in Strapi’s evolution toward an agentic CMS. Merci beaucoup!

Your browser does not support the video tag.

These are the first steps into the Strapi AI journey. Stay tuned for more!

Editing Experience

Live Preview

The Headless architecture is a great separation of concerns between the frontend and the CMS. However, this separation often came at the cost of the editing experience. Non-technical people need - and deserve - to edit websites and apps in an intuitive and smooth manner. Combined with Strapi 5's Draft & Publish capabilities, Live Preview addresses this challenge.

Your browser does not support the video tag.

Responsive

Editing content for small screens has been a community request for several years. We must admit this comes later than expected, but Strapi is becoming responsive. We've released the first improvements and will keep rolling out additional updates.

Conditional Fields

At Strapi, we’ve always prioritized giving developers and content teams the flexibility to organize content as they see fit. So we introduced Conditional Fields.

With Conditional Fields, you can dynamically show or hide fields based on specific criteria like dropdown selections or checkbox values. This helps editors focus on the right fields at the right time.

Developer Experience

Strapi was created by developers, for developers. In 2025, we shipped a significant number of Developer Experience improvements:

Strapi Client Library: The brand new SDK allows you to easily request your Strapi content from your favorite frontend framework.
OpenAPI support: We’ve heard many users requesting the ability to benefit from typing when using the Strapi Client Library in a frontend project (Next.js, Tanstack, Astro, Nuxt.js, etc.). OpenAPI support will allow us to add this to the Strapi Client Library.
Homepage widgets: From now on, it is possible to display and create widgets on the Strapi homepage.
MCP prototype: The first MCP prototype was shipped. This will be a massive enabler in making Strapi fully agentic.

Integrations

A Headless CMS is often used in conjunction with other services, making it the foundation of a composable architecture. In 2025, in close collaboration with our partner VirtusLab, we launched official integrations for Shopify, BigCommerce, and Cloudinary.

Strapi Cloud

24 months after its launch, Strapi Cloud has become the leading platform for hosting Strapi projects, as it comes with everything you need: Node.js hosting, a Postgres database, asset storage, a CDN, GitHub/GitLab integrations, and more.

Until 2025, the most affordable plan was the Pro plan, at $99/month. Many of you have shared that this price was too high for small projects. This is why we introduced the Essential Plan, for $15/month (when billed annually). We even went a step further by launching a Free Plan, making Strapi Cloud accessible to everyone.

Based on your feedback, we released a bunch of other improvements, such as:

Ownership transfer: Give full access to a Strapi Cloud to anyone (ideally for agencies with clients, and vice versa).
Data migration: Easily migrate content from one environment to another.
Downloadable backups: Save your content and store it anywhere.

Community milestones

Strapi is so much more than an open-source project; it is a vibrant community of contributors, users, and partners who build faster, together.

StrapiConf

After organizing 3 online StrapiConf, we organized the first in-person StrapiConf on May 13, 2025. After years of chats on the Strapi Community Discord, it was fantastic to meet so many of you face-to-face!

Community members presented incredible plugins. Large organizations, including Adidas and Airbus, benefit from the unique customization capabilities that Strapi offers. We had a blast!

Thank you again to our amazing sponsors for empowering the Strapi ecosystem.

Community Calls and Events

We had some amazing calls with the community, one of which was a full-on conversation with Kent C. Dodds about the future of the web, AI agents, and why Model Context Protocol (MCP) might be as big a shift as the early days of the internet.

Here are some other talks and events you may have missed:

To join live streams & online meetings on the latest updates & discussions about Strapi, visit our events page: https://strapi.io/events

Tutorials

Among many amazing tutorials, we created a full tutorial on “Strapi 5 and Next.js 15 Full Stack Project Course”, which shows you how to build a fully functional summer camp website from start to finish, through hands-on practice.

Other great tutorials from the community that you may want to see include:

To see more tutorials, visit the Strapi Blog or our YouTube channel.

Marketplace

We introduced several improvements to the Strapi Marketplace:

The Plugins & Providers are now merged into one overview
The overview is sorted by the number of NPM downloads by default
The home page now directly shows the overview
Outdated plugins for Strapi v4 have been removed

Thank you to the top plugin creators:

Mateusz Ziarko - VirtusLab
Scherwan Al-Ahmad - MagicDX
Kevin Vugts - Headlockr
Tim Schipper - PluginPal
Nikita Shenderov - CKEditor plugin
Laurent Cazanove - Meilisearch

Partner Program

The Partner Program continues to become increasingly beneficial for both enterprises seeking trusted implementers and agencies expanding their client base.

Special shout-out to Notum, QBurst, Alloy, TenTwenty, and Thrillworks for becoming Enterprise Partners, totaling 5 Enterprise-level partners added in 1 year.

This year, we launched monthly live Partner Enablement sessions to keep our partners informed on Strapi best practices, product updates, and sales alignment.

Partners have consistently shared valuable feedback with our product and engineering teams. They've helped identify bugs, feature gaps, and opportunities to price the product more competitively. Thank you for that!

Looking ahead to 2026

As you have seen in this article, we have shipped numerous new features, just as we have for the past few years. This is great!

Over the past few months, you all have shared your opinions through the Community Survey and the pain point GitHub issue. A few improvement requests have been around for a long time on the Feedback page. This is largely because we needed to build a solid company to make the open-source project sustainable and navigate through 2 different business models.

We’ve heard you loud and clear. Although adding features is exciting, it is time to improve some of the foundations. That's why 2026 will be dedicated to User Experience. And it all starts with Quality - fixing bugs, improving data migration, and strengthening the foundations - while also encompassing both the Developer Experience (MCP, typing in the frontend) and the Editing Experience (Media Library enhancements, etc.). Regarding Strapi Cloud, we are migrating to a new infrastructure that will significantly enhance performance, but also allow us to provide you with direct database access and improved runtime logs.

We also plan to continue collaborating as a Strapi community, including creating plugins, contributing to the core, and hosting events.

A Heartfelt Thank You

Thank you so much for being part of the Strapi community. We are 10 years into this journey, and it feels like we are just getting started.

Str’happy New Year!

Originally published at strapi.io

Building a React Native App with Expo and Strapi: A Complete Guide

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:45:51 +0000

This post is based on our livestream conversation with Kadi Kraman, Developer Experience Engineer at Expo.

TL;DR

Expo is the Next.js of React Native — it handles all the complex native tooling so you can focus on building your app
Start with Expo Go for learning and prototyping; switch to development builds for production (no limitations)
CNG (Continuous Native Generation) means you never commit native folders — they're auto-generated and disposable
React Native renders actual native components, unlike Flutter which draws its own UI
Three styling options: Built-in StyleSheet, NativeWind (Tailwind), or Unistyles (best for theming)
EAS services handle building, submitting, and updating your apps — no Mac required for iOS builds
You can write server code directly in your React Native app with +api.ts files
Meta officially recommends Expo for React Native development

Why Choose Expo for Mobile Development?

The Problem Expo Solves

Without Expo, you'd need to:

Manually configure native build tools (Xcode, Android Studio)
Research and choose from dozens of libraries for basic functionality
Manage native iOS and Android folders manually
Handle complex upgrade paths when React Native versions change

What Expo Provides

Expo is a collection of libraries, utilities, bundlers, and a complete ecosystem that makes building React Native apps pleasant and straightforward. Key benefits include:

Expo SDK: A curated set of native libraries guaranteed to work together (video, audio, haptics, push notifications, etc.)
Expo Router: File-based routing similar to Next.js
Expo Go: Test your app instantly on your phone without building native binaries
CNG (Continuous Native Generation): Native folders are generated automatically and can be thrown away and regenerated

React Native vs. Flutter: Understanding the Difference

Getting Started: Expo Go vs. Development Builds

Expo offers two approaches for development, each suited to different stages of your project.

Expo Go: Perfect for Learning and Prototyping

Limitations: Not all libraries are included. Some Expo SDK libraries (like expo-video) and third-party packages won't work in Expo Go.

Development Builds: Production-Ready Flexibility

Best for: Production apps, custom native code, any library from the React Native ecosystem.

Continuous Native Generation (CNG): The Secret Sauce

Your native folders are git-ignored
They're generated automatically from your package.json, app.json, and node_modules
Upgrades become trivial: delete the native folders, regenerate with new versions

Styling Your App: Three Approaches

Coming from web development, you might wonder about styling options. React Native offers several approaches:

Approach	Description	Best For
StyleSheet (Built-in)	React Native's built-in styling API. Can be verbose for theming.	Projects that want zero dependencies
NativeWind	Tailwind CSS for React Native. Familiar utility classes.	Web developers wanting quick start
Unistyles	Like StyleSheet but with better theming support (light/dark mode).	Apps needing robust theming

Deployment: From Code to App Store

EAS Build: Cloud-based CI/CD that builds your native apps. Particularly valuable because you need a Mac to build iOS apps — EAS Build provides that infrastructure.
EAS Submit: Uploads your built apps to the App Store and Play Store. Free to use and essential since Apple requires specific tools (Transporter) to upload apps.
EAS Update: Push JavaScript updates without going through app store review. Fix bugs instantly.
Expo Launch: A new beta product that takes a GitHub repo and handles everything — building, signing, and submission. Currently supports public repos and iOS (Play Store coming soon).

Writing Server Code in Your React Native App

A powerful recent addition is the ability to write API routes directly in your React Native codebase. Create files ending in +api.ts in your source folder:

// src/posts+api.ts
export function GET() {
  return Response.json({ message: "Hello from server!" });
}

AI-Assisted Development with Expo

Coming Soon: Performance Observability

Quick Start Checklist

Install Node.js and create a new project with npx create-expo-app@latest
Download Expo Go on your phone for instant testing
Run npx expo start and scan the QR code
Read the Expo docs (docs.expo.dev) — they have an AI assistant built-in
Check React Native Directory (reactnative.directory) for community libraries

Additional Learning Resources

To continue your learning journey, here are some excellent resources:

Video Resources

Full Stack React Native Course by Tube Guruji: A comprehensive 4+ hour course building a local business directory app from scratch using React Native, Expo, and a full backend. Perfect for hands-on learning.

Written Tutorial

Building a React Native App with Expo and Strapi: A Complete Guide: A detailed step-by-step tutorial from the Strapi blog covering project setup, NativeWind styling, data fetching with React Query, and building a complete blog app with infinite scroll. Read it here.

Conclusion

Happy building!

Originally published at strapi.io

Introducing Yearly Plans and New Limits for Strapi Cloud

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 12:34:03 +0000

Back in March, we introduced a new pricing model, making Strapi Cloud more accessible. The intention was simple: reduce friction for builders. We simplified Strapi Cloud pricing by offering “hosting-only plans” (without CMS features), increasing included storage, and removing CMS seat and entry limits. The result was a pricing model that grows with your business, where you only pay for what you need when you need it. This approach makes it easier for you to scale, allowing you to focus less on infrastructure management and more on building products that matter.

Today, we’re taking the next step in that direction. We're introducing annual billing with 20% savings, alongside refined usage limits that ensure each plan serves its intended purpose.

TL;DR

20% discount for yearly billing compared to monthly billing
Refined usage limits: Updated API request limits for Free and Essential plans
Monthly quota resets: API requests and bandwidth renew monthly, even on yearly plans
Explore the Strapi Cloud Pricing page and Cloud billing & usage docs for complete details

What’s new and what it means for you

Introducing Yearly Pricing

We heard from many customers that they prefer annual billing for simplified budgeting and reduced administrative overhead. One annual invoice means less time spent processing payments for both developers and accounting teams.

You can now choose yearly billing on all paid Strapi Cloud plans and get a 20% discount compared to monthly billing, with one annual invoice instead of twelve.

Yearly plans offer the best value for teams that are ready to commit and plan ahead. Monthly billing remains available for teams that require maximum flexibility and the ability to cancel at any time, albeit at a higher monthly rate. This reflects the trade-off between flexibility and long-term savings, allowing you to choose what best suits your situation.

Existing monthly customers will continue on their current plans without any changes to their pricing. You're grandfathered in at your existing rates.

Monthly resets still apply on yearly plans too, regardless of how you’re billed:

API requests reset monthly
Bandwidth resets monthly
Asset storage remains an ongoing limit

If you're currently on a monthly plan, don't worry, you'll keep your current pricing. Your rates won't change, and you'll continue with the same limits you have today.

Updated API request limits

We’ve refined API request limits on two plans to better reflect how they’re typically used:

Free plan: 2,500 API requests/month (previously 10,000)
Essential plan: 50,000 API requests/month (previously 100,000) – applies to new subscriptions only

The Free plan remains ideal for personal projects, learning, and early prototypes. These refined limits enable you to build in a stable environment, knowing exactly when your project is ready to transition from proof of concept to production.

Existing Essential customers are protected. If you’re already on the Essential plan, nothing changes. You’ll keep your existing 100,000 API requests/month limit. No action required. No disruption. We believe trust is built by honoring existing commitments and protecting the way you’re already building.

Why we changed the limits

To be clear and honest, lower limits aren’t a direct benefit to individual users. These updates help keep Strapi Cloud reliable, sustainable, and aligned with how each plan is intended to be used:

Free plan: lower limits ensure stability and usability for everyone experimenting or learning.
Platform sustainability: helps maintain performance, prevent abuse, and fund continued investment in new capabilities.

If your project outgrows a plan, that’s a signal it’s ready for the next stage.

What’s next for Strapi Cloud

Alongside these pricing updates, we're continuously building new capabilities across all paid Strapi Cloud plans designed to give you more visibility, control, and speed as your projects grow.

This includes enhanced logging, monitoring, and other improvements focused on improving the developer experience. These initiatives are shaping the 2026 roadmap, and we'll share more details as they become available.

FAQ

Will yearly plans be available for the Growth (CMS) plan?

Yearly billing currently applies only to Strapi Cloud hosting plans (Essential, Pro, Scale). CMS feature licenses (Growth) remain separate for now and are available on a monthly basis.

Can I stay on the Free plan and pay overages?

No, overages don't apply to the Free plan. If you need additional resources, upgrading to a paid plan starting at just $18/month (or $15/month with yearly billing) gives you significantly more capacity.

Do monthly quotas reset monthly, even on yearly plans?

Yes. API requests and bandwidth renewals occur on a monthly basis on yearly plans. Unlike Asset storage, which is an ongoing limit. For example, an Essential customer with 100,000 API requests/month makes 125,000 requests in a given month. They exceeded their quota by 25,000 API requests and would be charged an additional $1.50.

Can I switch from monthly to yearly billing and vice versa?

Yes, you can adjust your billing frequency in your dashboard at any point in time. However, the change will take effect at the end of your current billing cycle. For yearly plans, this means the switch will occur after your 12-month commitment has been completed.

Is Strapi Cloud better than managing my own servers?

In most cases, yes, it greatly reduces operational overhead and lets you build faster. If you require full infrastructure control or want to keep both your frontend and backend on the same infrastructure, self-hosting remains an option.

What happens to existing Essential customers with the new limits?

Current Essential customers keep their existing 100,000 API requests/month limit and won't be affected by these changes. The new 50,000 API requests/month limit only applies to new Essential subscriptions created after December 22nd, 2025.

Originally published at strapi.io

Chat as the New Interface: Building for the Agentic Web with Kent C. Dodds

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 11:56:41 +0000

I recently had the chance to sit down with one of my favorite educators in web development, Kent — someone whose courses and talks played a big role in my own late-career transition into tech. We started out talking about React Server Components… and somehow ended up in a full-on conversation about the future of the web, AI agents, and why Model Context Protocol (MCP) might be as big a shift as the early days of the internet.

You can watch the whole talk here, or keep reading for everything we covered.

Users Are Quietly Leaving the Browser

Kent said something that really stuck with me:

“Users are fleeing the browser and moving to AI agents.”

If you think about your own habits, that might already be true.

I realized I barely use Google anymore. Most of the time I don’t search for a page — I ask an AI a question.

Instead of:

Finding the right keywords
Clicking through SEO’d blog posts
Hunting for the one paragraph that actually answers my question

…I just open ChatGPT or Claude and type what I want.

That’s not just a nicer UX. It’s a fundamental shift in the primary interface between users and software:

Before: users went to websites and apps
Now: users go to agents, and agents go to websites and apps for them

Browsers and search engines are trying to adapt (AI answers on search result pages), and AI tools are trying to adapt (chat + files + tools + browsing), but the direction is pretty clear:

The main way people interact with software is becoming “Asking”, not “Searching”

ChatGPT Apps and the New Interaction Model

At React Conf, Kent showed a short promo video for an upcoming ChatGPT feature: ChatGPT apps.

The idea:

Instead of going to a website and logging in
You tell ChatGPT what you want to do
ChatGPT decides which “app” (backed by tools/APIs) is best to handle it
That app appears inside the chat, as:
- A small widget
- A full-screen experience
- A hybrid where you both click UI and keep chatting

Input becomes multimodal: text, voice, clicks, typing. The agent chooses whatever mix of UI + conversation makes the most sense for the task.

The important mental shift:

In the future, you won’t just be designing for “the user in the browser.”
You’ll be designing for the user’s agent, which is acting on their behalf.

That means your app needs a way to say to the agent:

“Here’s what I can do. Here are the actions I support. Here’s how to call me.”

That’s where MCP comes in.

What Is MCP, Really?

MCP stands for Model Context Protocol. Under all the buzzwords, it’s basically:

A standard way for AI agents (like ChatGPT, Claude, etc.) to talk to external services in a structured, predictable way.

You expose your app as an MCP server, which defines:

Tools – the operations your app can perform
Inputs/outputs – what arguments those tools need and what they return
Authentication – how the agent is allowed to call those tools

Then an agent can:

Read your tool definitions
Decide when to call them based on what the user asks
Chain them together with other tools, web search, memory, etc.

Kent has been focusing a lot on consumer-oriented MCP servers (not just dev tools in an IDE). One of his example projects is a journaling app, exposed via MCP:

You could talk to ChatGPT and say, “Help me journal about my day and save it.”
The agent asks you questions, writes the entry, and stores it via the MCP server.
You interact with ChatGPT, not “yet another journaling app UI,” but your data still lives in your service, with your logic.

That’s the pattern:

Your app becomes a capability provider to agents, not just a website with a login form.

“If You’re Not Integrated, You’ll Be Left Behind”

Kent compared this shift to the early web:

In the 90s, a lot of businesses didn’t think they needed a website.
By 2010, not having one made you basically invisible.

He sees MCP and agent integration the same way:

Today, most companies are still asking: “Why would my service need an MCP server?”
Tomorrow, the question becomes: “Why on earth *don’t you have one?”*

Imagine:

ChatGPT or Claude has hundreds of millions of users.
Those users say, “Book me a ride,” “Find me a sitter,” “Order me this thing,” “Update my account,” “Change my subscription,” etc.
The agent looks at all the available services exposed via MCP.

If your competitor has MCP integration and you don’t, the agent will prefer the one it can seamlessly call. Browsing your website and scraping forms will always be a worse UX than direct integration.

Yes, agents can technically browse the web. But:

It’s slower
Less reliable
Harder to secure
Worse for the user

Agents are incentivized to use directly integrated tools whenever possible. That’s why Kent argues:

Ignoring MCP and agent integration will eventually feel like not having a website in 2010.

What Happens to UI and Frontend Work?

Does this mean UI is dead? Not at all.

Kent thinks custom UI will be important for at least the next five years (and probably longer — but forecasting beyond that gets dicey fast).

A few key points:

Branding still matters
- If you ask your agent, “Get me a ride to the airport,” Uber cares a lot that you know it’s Uber picking you up, not some random service.
Trust still matters
- Users want to know which company they’re actually interacting with.
UI libraries may become “building blocks”
- In the future, a service might expose:
- Not just tools (actions)
- But also UI components
- The agent could then compose those components into custom layouts based on what the user is trying to do.

We may eventually see agents generate full UI on the fly, but we’re not there yet. For now:

Frontend work is still about building components, flows, and branded experiences — just increasingly in collaboration with agents instead of only with browsers.

“Is AI Going to Take My Job?”

We had to talk about the big fear: AI replacing developers.

Kent’s take was both simple and kind of liberating:

If AI completely replaces all developers in, say, a year
There is nothing you can do to meaningfully prepare
No skill, no amount of money, no clever trick changes that outcome

So planning your life around that scenario is pointless. You can’t act on it.

Now remove that from the table and ask a more useful question:

“Assuming AI remains a powerful tool, not an instant replacement, how do I stay relevant and valuable?”

His answer:

Get really good at using AI in your workflow
Get really good at integrating AI into your products

And this matches my own experience too. I’ve used AI to:

Generate large chunks of code quickly
Create entire prototypes with 3D graphics
Iterate on ideas at a speed that wasn’t possible before

But here’s the catch:

AI can often get you 60–80% of the way
That last 20% is brutal if you don’t understand what’s going on
Debugging, performance tuning, architecture decisions, tradeoffs — that’s still on you

The skills that matter more than ever:

Problem solving
Debugging and troubleshooting
Understanding systems and tradeoffs
Being able to explain your problem clearly (to humans and AI)

Kent even tries to talk to LLMs the same way he’d talk to another engineer — not just “do this,” but with context, constraints, and reasoning. That habit itself is a valuable engineering skill.

How Kent Uses AI Day-to-Day

A few practical bits from Kent’s workflow:

He uses Cursor as his primary editor
He still likes editor mode over a pure chat agent — seeing and editing files is part of his “prompt”
He treats the existing codebase as context for the model:
- If the AI keeps giving wrong answers
- He improves the code structure and patterns
- So future suggestions become better

He also uses ChatGPT outside the editor to:

Think through ideas
Step away from the code and reason at a higher level

In other words, AI isn’t a replacement for thought — it’s a partner in thinking and typing.

MCP vs “Yet Another AI Wrapper App”

One of the most interesting parts of the conversation was about the current wave of “AI apps.”

For the past few years, companies have been building:

Chatbots that sit in front of their knowledge bases
RAG (retrieval augmented generation) systems that:
- Take a user question
- Search internal docs
- Stuff the results into the prompt
- Ask a model to answer

Those are useful, but they have big limitations:

They only know what’s inside your knowledge base
They don’t have the broader capabilities of ChatGPT/Claude:
- Web search
- Other tools
- Memory
- General world knowledge

If instead you expose your knowledge base (and other capabilities) via MCP:

ChatGPT can combine your data with:
- Other services
- Search
- The user’s history and preferences
You don’t have to maintain a completely separate chat UX if you don’t want to
You ride the wave as agents get smarter and more integrated

There are still valid reasons to build your own “wrapper”:

You need something immediately
You can’t (or don’t want to) rely on ChatGPT / Claude’s current MCP support
You have strict privacy constraints

But even then, Kent recommends:

Build your own chatbot on top of an MCP server you control.

That way:

Internally: your bot talks to your MCP server
Externally (later): ChatGPT, Claude, or any other agent can talk to that same MCP server

You get both:

Control over privacy and UX
Future compatibility with general-purpose agents

Common MCP Misconceptions

A few myths Kent keeps running into:

“MCP doesn’t support OAuth.”

It does. And the spec has been improving quickly:

Earlier versions made the MCP server act as its own OAuth server (painful)
Newer versions treat it as a resource server (much simpler)
Recent updates made it even more secure and easier to work with

Is it perfect? No. But it’s absolutely not “no auth.”

“Why not just use a CLI? The agent can call that.”

For developer tools, sure — a CLI might be fine.

But:

CLIs are non-standard — every one is different
Agents would have to repeatedly run --help and parse text
That’s slow, brittle, and not consumer-friendly
And your actual users are not going to be using CLIs on their phones by voice

MCP gives you:

A standard tool definition format
A way for agents to optimize how they load and call tools
Something that works across:
- Dev tools
- Consumer apps
- Mobile devices
- Voice interfaces

So… What Should You Actually Do?

If you’re a developer or technical founder, here’s a simple roadmap pulled from our conversation:

Accept that agents are becoming the new frontend.
Users will increasingly talk to AI first.
Keep investing in UI skills — they still matter.
Branding, trust, and good interaction design aren’t going away.
Get good at using AI in your workflow.
Treat it like a powerful teammate that’s great at drafting, exploring, and refactoring.
Start learning about MCP.

Read the spec
Look at existing open-source MCP servers
Try building a tiny one yourself for a hobby project or side tool

Think in terms of “capabilities,” not just “apps.” Ask:

“What can my service do for a user?”
“How can I expose those actions to an agent cleanly?”

Stay optimistic. Ignoring AI doesn’t protect you — it just puts you behind. Integrating it makes you more capable, not obsolete.

Kent closed our conversation with this:

“Be optimistic. The version of you that learns to use and integrate AI will be better than the version of you who doesn’t.”

I tend to agree.

You don’t need to predict the entire future of AI.
You don’t need to know exactly where we’ll be in ten years.

But you can start today:

Use agents more intentionally
Build small integrations
Ship a simple MCP server
And keep your skills pointed toward where the puck is going — not where it’s been.

Originally published at strapi.io

Quality First: Our Commitment to a (Even) More Robust Strapi

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 11:53:17 +0000

v5.31.1: 24 bug fixes. v5.30.1: 12 bug fixes. v5.29.0: 20 stability improvements. The pattern is clear, quality is now our top priority until the end of the year and throughout 2026.

Why This Matters?

We shipped significant features in 2025, including TypeScript 5.0 support, Responsive Admin Panel, Conditional Fields, Live Preview, Homepage Customization, Database Transactions, Draft & Publish improvements, Strapi AI, Shopify/Cloudinary/BigCommerce integrations, and more. But velocity came at a cost to stability.

You've been clear through GitHub issues and community feedback. The top-voted requests aren't flashy new features; they're reliability fundamentals. Better error handling, performance optimization, data transfer, and media library stability. Support tickets echo the same patterns.

How did we get there?

We're a small team maintaining three products that serve different needs: Strapi Community Edition (open source), Strapi Enterprise Edition, and Strapi Cloud. Each one requires attention, resources, and care. As an open-source company, we face a constant balancing act: generating revenue to sustain the project while staying true to our commitment to the community that makes Strapi what it is.

It's not easy. When we prioritize one, the other can slip. And we know you've felt that in some ways, lingering bugs, features that would benefit from additional iterations, or pull requests that go unreviewed for some time.

What we are doing about it

Recent releases show the shift. v5.31, v5.30, and v5.29 merged over 70 PRs focused on quality.

Here is a summary of these updates across various parts of the codebase:

Content Modeling: Fixed schema generation with negative numbers, resolved enum defaults, and Content-Type Builder accessibility.
Content Manager:
- Content Internationalization: Fixed field flickering on i18n rerenders, bulk unpublish with new locales, draft relation counts, locale picker ordering, publish/unpublish with locales.
- Responsiveness: improved responsiveness of the left menu and subnav.
- General Fixes: preserved hidden fields during form submission, admin panel safety (prevented accidental self-deletion), dynamic zone configurations, and bulk operations.
- Media Library & Upload: Resolved modal click issues, file-type detection, folder selection, and enhanced asset selection with accessibility improvements.
Developer Experience: Improved TypeScript errors, customized CORS settings in the GraphQL plugin, and Node 24 support added.

Quality isn't just our focus at the core; it extends to everything we do, from the documentation to the Marketplace and the LaunchPad demo application:

Here are the latest updates from the M*arketplace*:

We have migrated numerous Strapi plugins from Strapi 4 to Strapi 5 i.e plugin-rest-cache,
We've removed outdated v4 plugins, eliminated duplicate listings, and increased visibility for higher-quality plugins, while also adding visibility warnings for unmaintained packages.
Stale plugins (no updates in 2+ years) are being deprecated. Moving forward, we plan to raise quality standards and work toward automated compatibility testing with each Strapi release.

We’ve also been busy reworking our documentation. To name a few recent improvements:

We added a new section on How to create admin permissions from plugins.
We developed the Information on aggregation in GraphQL API and GraphQL API related v5 migration.
We reworked the Document Service API page to better explain documentId and available methods.
We improved the Lifecycle functions reference with more explanations and examples.

We need your help

Here's the truth, though: We need your help. We're prioritizing quality and committing resources, but we can't do this alone. Community contributions such as detailed issues, PRs, and documentation updates make a massive difference.

For instance, last month's releases included 9 merged PRs from a diverse group of community contributors in countries like Colombia, India, Egypt, and Austria. Here are some of the amazing people who contributed:

Ayush @Ayushd785
Chaitya @chaitya-titan
Daniel Garcia @dagadevelop
Dmitry Maklygin @dmaklygin
José Luis @SalahAdDin
ndaemy @ndaemy
Razim Saidov @razims
Sam Phillemon @Sam-Phillemon9493

The unglamorous work matters most. In open source, it's the steady contributors who review PRs, triage issues, update docs, and fix bugs that build reliable software. We see you. We value you. Making contributions count requires effort from both sides. We're making a significant push to review PRs more frequently and merge them faster. The entire team is now pitching in to support this effort. On the contributor side, following the guidelines carefully makes a huge difference—writing clear descriptions, linking related issues, including tests, and providing all the necessary context helps us merge contributions quickly and efficiently.

Why should you contribute to Strapi?

Building on our promising Documentation Contribution Program, we plan to provide stronger recognition and clearer incentives to code contributors, including Strapi goodies from the Strapi Shop and more!

We're also planning to start allocating unused Open Collective funds directly toward contributions to the core codebase and popular plugins currently hosted under the Strapi Community GitHub Org: such as the plugin-rest-cache, strapi-plugin-sitemap, strapi-plugin-import-export-entries, strapi-plugin-seo, and strapi-plugin-menus!

We're still finalizing the details of this program, so please stay tuned for more information. In the meantime, we invite you to check out our GitHub repository and look for issues or PRs that could use some love!

Looking ahead to 2026

In summary, our plan is to prioritize the foundations that directly impact reliability and stability. We'll tackle as many of these topics as possible, with progress dependent on both our internal resources and community contributions.

Main focus areas currently include:

Media Library performance and reliability
Bulk operations reliability
Relations handling
Filters and search functionality
Performance improvements include faster build times, optimized rendering, and more efficient compilation.

Every year, we ask the community to identify the issues that matter most to them. Join the discussion on GitHub and tell us what we should prioritize.

Your feedback and contributions directly shape our roadmap!

Originally published at strapi.io

Next.js 16 Route Handlers Explained: 3 Advanced Use Cases

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 11:49:13 +0000

Introduction

Route handlers in Next.js 13.2+ provide a cleaner, platform-native alternative to legacy API Routes. They use the standard Request and Response Web APIs and make it easy to build server-side logic and REST endpoints with familiar HTTP methods like GET, POST, PUT, and DELETE.

Beyond simple CRUD, route handlers are ideal for tasks that don’t belong in React components, such as file generation, data transformation, proxying, and other backend-for-frontend responsibilities.

This article walks through 3 production-ready use cases that show how to apply route handlers effectively in real Next.js applications.

Why Use Next.js Route Handlers?

Route handlers are ideal whenever your application needs server-side logic that sits outside the React rendering lifecycle. In practice, they’re a great fit for:

Shared API logic with Higher-Order Functions (HOFs): Apply logging, validation, authorization, or context forwarding across multiple REST endpoints without repeating code.
Backend responsibilities without a backend server: Route handlers can perform tasks such as:
- Generating downloadable files (CSV, PDFs, exports)
- Transforming or aggregating data
- Proxying or forwarding requests
- Streaming responses from LLMs
- Handling third-party webhooks

These patterns become increasingly powerful as your application grows and your API endpoints take on backend-for-frontend duties.

Project Overview

For this walkthrough, we start with a Next.js 16 dashboard application based on the current official App Router tutorial.

The project has been extended with:

A Strapi backend providing invoice and customer data
A JSON REST API built entirely through App Router route handlers

Throughout the article, you'll build 3 advanced server-side capabilities:

CSV export route: Generate downloadable invoice data directly from a route handler.
Locale-aware currency conversion route: Transform data using live exchange rates, plus a proxy that redirects based on the client’s IP.
Redirect management system: A middleware powered by Vercel Edge Config and a dedicated route handler for efficient redirect lookups.

By the end, you'll see how route handlers can cleanly encapsulate backend logic without needing a separate API service.

Prerequisites

This guide assumes you’re comfortable working with:

React’s page.ts|js files in the Next.js 16 App Router
REST endpoints using standard HTTP verbs (GET, POST, PUT, DELETE).

Vercel Edge Config

Two of the examples rely on Vercel Edge Config, so it's helpful to be familiar with:

Create an Edge Config store
Connect it to your Vercel project
Pull configuration values locally using vercel env pull
The @vercel/edge-config SDK for accessing config values in route handlers

System / Environment Requirements

To follow along after forking the starter repository, you’ll need:

The latest version of Node.js
npm or pnpm
A cloned or scaffolded version of the example app:

npx create-next-app --example https://github.com/anewman15/nextjs-route-handlers/tree/prepare

The Starter Code — A Typical JSON API Built with Next.js 16 Route Handlers

The starter code for the example Next.js 16 app router API application is available in the prepare branch here. It has a similar-looking dashboard application with customers and invoices resources as the original Next.js tutorial. Some features have been discarded for brevity, focusing on the topics of this post.

For demonstration purposes, the base invoices REST endpoints are already implemented in this branch. You’ll expand on these throughout the article as you build more advanced functionality.

To get the project running locally:

Bootstrap the starter project

npx create-next-app --example https://github.com/anewman15/nextjs-route-handlers/tree/prepare

CD into the app directory and install dependencies

npm i

Start the development server:

npm run dev

Visit http://localhost:3000/dashboard. You’ll see the classic Next.js dashboard with routes for:

/dashboard
/dashboard/invoices
/dashboard/customers

This dashboard fetches resources from a Strapi backend hosted at:
https://proud-acoustics-2ed8c6b135.strapiapp.com/api.

Because the data comes from a cloud-hosted CMS, you’ll need an active internet connection as you follow along.

The examples in this article assume you are working from the prepare branch.
The fully completed project lives in the main branch if you want to inspect the final implementation.

Next.js Route Handlers for JSON REST APIs

The starter code makes heavy use of route handlers (route.ts) to implement its REST API. This aligns with the recommended pattern in the App Router: each nested segment can define its own API surface using exported HTTP method functions, such as:

GET
POST
PUT
DELETE

Example: Collection Endpoint: We will use a GET() and a POST() handler for invoices endpoints at the /api/v2/invoices/(locales)/en-us routing level:

// Path: app/api/v2/invoices/(locales)/en-us/route.ts

import { NextRequest, NextResponse } from "next/server";
import { invoices } from "@/app/lib/strapi/strapiClient";

export async function GET() {

  try {
    const allInvoices = await invoices.find();

    return NextResponse.json(allInvoices);
  } catch (e: any ){
    return NextResponse.json(e, { status: 500 });
  }
};

export async function POST(request: NextRequest) {
  const formData = await request.json();

  try {
    const createdInvoice = await invoices.create(formData);

    return NextResponse.json(createdInvoice);
  } catch (e: any){

    return NextResponse.json(e, { status: 500 });
  };
};

As it goes with React views in the page.ts file, we can use dynamic route segments to define endpoints for an individual item (invoices item in this case) with its :ids.

Example: Single-Item Endpoint: So, we have a route handler at /api/v2/invoices/(locales)/en-us/[id]. For this segment, we have a GET(), a PUT() and a DELETE() handler in the route.ts file:

// Path: app/api/v2/invoices/(locales)/en-us/[id]/route.ts

import { NextRequest, NextResponse } from "next/server";
import { invoices } from "@/app/lib/strapi/strapiClient";

export async function GET(
  request: NextRequest,
  { params }: { params: Promise<{ id: string }>}
) {
  const id = (await params).id;

  try {
    const invoice = await invoices.findOne(id);

    return NextResponse.json(invoice);
  } catch (e: any) {
    return NextResponse.json(e, { status: 500 });
  };
};

export async function PUT(
  request: NextRequest,
  { params }: { params: Promise<{ id: string }> }
) {

  const id = (await params).id;
  const formData = await request.json();

  try {
    const invoice = await invoices.update(id, formData);

    return NextResponse.json(invoice);
  } catch (e: any) {
    return NextResponse.json(e, { status: 500 });
  };
};

export async function DELETE(
  request: NextRequest,
  { params }: { params: Promise<{ id: string }> }
) {

  const id = (await params).id;

  try {
    const invoice = await invoices.delete(id);

    return NextResponse.json(invoice);
  } catch (e: any) {
    return NextResponse.json(e, { status: 500 });
  };
};

The Next.js 16 route.ts file facilitates hosting multiple REST API endpoints by allowing more than one handler/action export. So, for each action for an invoices item at /api/v2/invoices/(locales)/en-us/[id], we have:

a GET() handler that serves an invoices item with :id,
a PUT() handler that helps update an invoices item with :id,
a DELETE() handler that helps delete an invoices item with :id.

`NextRequest` and `NextResponse` APIs in Next.js 16

Route handlers use NextRequest and NextResponse, which extend the native Web APIs (Request and Response) with features optimized for the Next.js runtime:

Access to cookies and headers
URL utilities
Built-in JSON helpers
Enhanced redirect and response handling

These abstractions make building REST endpoints in the App Router ergonomic and familiar.

Authentication & Middleware in the Next.js App Router

Authentication can be introduced at multiple layers in a Next.js App Router application:

Sitewide auth — via OAuth, NextAuth.js, credentials, SSO, or JWT sessions
Middleware-based authorization — using middleware.ts with matcher patterns for RBAC or LBAC
Higher-order function (HOF) middleware — apply shared logic (auth, validation, logging) to groups of route handlers
Service-specific SDKs — attach access tokens to requests for external services (e.g., Stripe, Strapi, Vercel APIs)
Custom per-handler logic — manually adding headers inside individual route handlers, adding auth tokens to request headers from individual route handlers.

Example: Strapi Token Authentication

In our case above, we are handling the Strapi token authentication very granularly at every request with the strapiClient initialized in app/lib/strapi/strapiClient.ts:

// Path: app/lib/strapi/strapiClient.ts

import { strapi } from "@strapi/client";

const strapiClient = strapi({
  baseURL: process.env.NEXT_PUBLIC_API_URL!,
  auth: process.env.API_TOKEN_SALT,
});

export const revenues = strapiClient.collection("revenues");
export const invoices = strapiClient.collection("invoices");
export const customers = strapiClient.collection("customers");

This strapiClient sends the auth token as a header at every Strapi request, so in this case, there is no need for authorizing backend Strapi requests with a specialized/shared middleware.

Next.js 16 Route Handlers - 3 Advanced Use Cases

So far, we’ve used route handlers for relatively standard REST endpoints. But route handlers really shine when you start delegating heavier backend responsibilities to them.

Because they run on the server and are built on top of the Web Request/Response APIs, route handlers are a great fit for tasks like:

Generating and streaming files (CSV, PDF, etc.)
Aggregating or transforming data from multiple sources
Implementing location- or locale-aware APIs
Handling webhooks and callback URLs
Acting as a backend-for-frontend layer without a separate API service

The trade-off is always cost vs performance: you want to keep serverless invocations efficient while still doing useful work at the edge of your app.

In the next sections, we’ll walk through three concrete, production-style use cases:

A CSV download route for invoices
A location-based proxy + currency conversion endpoint
A redirect-management middleware backed by Vercel Edge Config and a dedicated route handler

Use Case 1: Implementing a File Download (CSV Export)

A classic pattern for route handlers is file generation: fetch data, transform it, and stream it back as a downloadable file.

In this example, we want to:

Fetch all invoices from our Strapi backend
Convert them to CSV
Return the result as an invoices.csv file from a route handler

We’ll create a route at /api/v2/invoices/(locales)/en-us/csv:

// Path : ./app/api/v1/invoices/(locales)/en-us/csv.route.ts

import { json2csv } from "json-2-csv";
import { invoices } from "@/app/lib/strapi/strapiClient";

export async function GET() {

  const allInvoices = await invoices.find({
    populate: {
      customer: {
        fields: ["name", "email"],
      },
    },
  });

  const invoicesCSV = await json2csv(allInvoices?.data, {
    expandNestedObjects: true,
  });

  const fileBuffer = await Buffer.from(invoicesCSV as string, "utf8");

  const headers = new Headers();
  headers.append('Content-Disposition', 'attachment; filename="invoices.csv"');
  headers.append('Content-Type', "application/csv");

  return new Response(fileBuffer, {
    headers,
  });
};

Here’s what happens step-by-step:

invoices.find() fetches invoice data (including related customer info) from Strapi.
json2csv converts the JSON array into CSV.
We create a Buffer from the CSV string.
We set headers so the browser treats the response as a file download.
We return a raw Response containing the CSV buffer.

Now, any GET request to /api/v2/invoices/(locales)/en-us/csv returns a downloadable invoices.csv file.

In the UI, we simply wire a “Download as CSV” button on the /dashboard/invoices page to this endpoint:

This keeps file generation purely server-side, with a minimal surface in your React components.

Use Case 2: Location-Based Proxy + Data Transformation

For the second use case, we’ll combine:

A data transformation route handler that converts invoice amounts from USD → EUR from Exchange Rates API
A location-aware proxy route handler that redirects traffic based on the client’s country

This kind of pattern is useful when you want to serve region-specific views of the same underlying data.

Step 1: Currency Conversion Endpoint (/api/v2/invoices/(locales)/fr)

First, we create a route handler that:

Fetches invoices in USD using invoices.find()
Fetches live forex rates from the exchange rates provider
Returns invoices with amounts converted to EUR using the NextResponse

// Path: ./app/api/v2/invoices/(locales)/fr/route.ts

import { NextResponse } from "next/server";
import { invoices } from "@/app/lib/strapi/strapiClient";

export async function GET() {
  let invoicesInUSD;
  let USDRates;

  try {
    invoicesInUSD = await invoices.find({
      fields: ["date", "amount", "invoice_status"],
      populate: {
        customer: {
          fields: ["name", "email", "image_url"],
        },
      },
    });

    USDRates = (await (
      await fetch("https://open.er-api.com/v6/latest/USD"))
      .json()
    )?.rates?.EUR;

    const USDtoEURRate = USDRates || (0.86 as number);
    const invoicesJSON = await JSON.parse(JSON.stringify(invoicesInUSD?.data));

    const invoicesInEUR = await invoicesJSON.map((invoice: any) => ({
      date: invoice?.date,
      amount: USDtoEURRate * invoice?.amount,
      invoice_status: invoice?.invoice_status,
      customer: invoice?.customer,
    }));

    return NextResponse.json({ data: [...invoicesInEUR] });
  } catch (e: any) {
    return NextResponse.json(e, { status: 500 });
  };
};

Key points:

All the “heavy” work — external API call + transformation — happens server-side.
The client just consumes a clean JSON API with EUR amounts.
You can swap out the forex provider or rate logic without touching any React code.

We are able to access this directly from the /api/v2/invoices/(locales)/fr endpoint. However, we want to implement a location-based proxy that redirects routing based on the request IP address. In particular, if the user is requesting /api/v1/invoices from an IP located in FR, we want to redirect them to /api/v2/invoices/(locales)/fr. Otherwise, we send the invoices as in v1.

Let's now add a location proxy route handler.

Step 2: Location-Based Proxy (/api/v1/invoices)

Next, we create a location-aware proxy route:

If the request originates from France (FR), we redirect to the /fr endpoint.
Otherwise, we return the default invoices as-is.

// Path: app/api/v1/invoices/route.ts

import { NextRequest, NextResponse } from "next/server";
import { invoices } from "@/app/lib/strapi/strapiClient";

export async function GET(request: NextRequest) {
  const ip = (await request.headers.get("x-forwarded-for"))?.split(",")[0];
  // const ip = "51.158.36.186"; // FR based ip

  let allInvoices;
  let country = "FR";

  try {
    allInvoices = await invoices.find();
    country = (await (await fetch(`http://ip-api.com/json/${ip}`)).json())?.countryCode;

    if (country !== "FR") {
      return NextResponse.json(allInvoices);
    };

    return NextResponse.redirect(new URL("/api/v2/invoices/fr", request.url), {
      status: 302,
    });
  } catch (e: any) {
    return NextResponse.json(e, { status: 500 });
  };
};

Behavior:

Non-French IPs hit /api/v1/invoices and receive the default USD dataset.
French IPs are transparently redirected to /api/v2/invoices/fr, where amounts are converted to EUR.

This is a perfect example of route handlers acting as a focused, backend-for-frontend layer: regional logic lives in the API, not in your React components.

Use Case 3: Redirect Management with Middleware + Vercel Edge Config

For the final example, we’ll build a redirect management system that:

Stores redirect rules in Vercel Edge Config
Uses a dedicated route handler to fetch individual redirect entries
Uses a middleware (in Next.js 16, proxy.ts) to decide whether to redirect a request

This pattern scales to thousands of redirects while keeping middleware fast and lightweight.

Step 1: Store Redirects in Edge Config

For the first step, we should add a redirects map to an Edge Config Store. Use this Vercel Edge Config guide to add a redirects map to Vercel Edge Config.

{
  "-api-v1-revenues": {
    "destination": "/api/v2/revenues/en-us",
    "permanent": false
  },
  "-api-v1-revenues-fr": {
    "destination": "/api/v2/revenues/en-us",
    "permanent": true
  },
  "-api-v1-revenues-de": {
    "destination": "/api/v2/revenues/en-us",
    "permanent": false
  }
}

Notes:

Keys represent normalized request paths (e.g., /api/v1/revenues → -api-v1-revenues).
Values contain a destination and a permanent flag.
Edge Config keys can only contain alphanumeric characters, -, and _.

Follow Vercel’s docs to:

Create the Edge Config store
Connect it to your project
Use vercel env pull to bring environment variables into your local env.local file

Step 2: Route Handler for a Single Redirect Item

Next, we expose a route handler that returns a single redirect entry from Edge Config.

This keeps the middleware simple; it doesn’t have to know how to talk to Edge Config directly.

// Path: app/api/redirects/[path]

import { NextRequest, NextResponse } from "next/server";
import { get } from "@vercel/edge-config";

export async function GET(
  request: NextRequest,
  { params }: { params: Promise<{ path: string }> }
) {
  try {
    const path = (await params)?.path;
    const redirectEntry = await get(path);

    return NextResponse.json(redirectEntry);
  } catch (e: any) {
    return NextResponse.json(e, { status: e.status });
  };
};

What this does:

Reads the path parameter from the URL
Uses get() from @vercel/edge-config to read the corresponding redirect entry
Returns the entry as JSON

Step 3: Middleware to Apply Redirects
Finally, we wire up a middleware that:

Normalizes the incoming pathname into a redirect key
Uses edgeConfigHas() to quickly check if a redirect exists for that key
If it exists, fetches the full redirect entry from the route handler
Redirects with 307 or 308 depending on the permanent flag

Add a proxy.ts (as opposed to middleware.ts, which is in version 15) file and use the following code:

// Path: proxy.ts

/* eslint-disable @typescript-eslint/no-explicit-any */
import { NextRequest, NextResponse } from "next/server";
import { has as edgeConfigHas } from "@vercel/edge-config";

export interface RedirectsEntry {
  destination: string;
  permanent: boolean;
};

export type RedirectsRecord = Record<string, RedirectsEntry>;

export async function proxy(request: NextRequest) {
  const pathname = request?.nextUrl?.pathname;
  const redirectKey = pathname?.split("/")?.join("-");

  try {
    const edgeRedirectsHasRedirectKey = await edgeConfigHas(redirectKey);

    if (edgeRedirectsHasRedirectKey) {
      const redirectApi = new URL(
        `/api/redirects/${redirectKey}`,
        request.nextUrl.origin
      );
      const redirectData = await fetch(redirectApi);

      const redirectEntry: RedirectsEntry | undefined =
        await redirectData?.json();
      const statusCode = redirectEntry?.permanent ? 308 : 307;

      return NextResponse.redirect(
        new URL(redirectEntry?.destination as string, request.nextUrl.origin),
        statusCode
      );
    }

    return NextResponse.next();
  } catch (e: any) {
    return NextResponse.json(e, { status: e.status });
  };
};

export const config = {
  matcher: ["/(api/v1/revenues*.*)"],
};

The whole point of a Next.js root middleware is to keep its operations lightweight so that it can make faster routing decisions.

So, first, without much overload, we just reached out to Vercel Edge Config with has() to quickly decide whether the redirect map has a key that represents the requested URL pathname.
We have to do some string gymnastics in the meantime to conform to Edge Config rules for naming Edge Config keys with alphanumeric characters, -, and _.
If the key doesn't exist, our decision is to swiftly continue to the next step of the request cycle with NextResponse.next(). So, this improves routing decisions on the spot.

On the other hand, if the redirects map has an item for the pathname being requested, we have additional things to do:

Create a URL from the pathname that represents a redirect URL key.
Send a fetch() request to the redirects key endpoint we created above at /api/redirects/[path] for this redirect URL key. Get that redirect entry via the route handler dedicated to this URL key.
redirect the request to the redirectEntry.destination.

So, here, we could have sent a get() request in the first place to Edge Config, but that would be a lengthy thing for the middleware to tackle -- particularly costly for a request that does not have a redirect URL. This becomes obvious when you have more and more entries in your redirects map.

Since has() is quicker and we have a route handler to tackle lengthy data fetching, we are choosing to keep our middleware performant. Essentially, for an efficient specialty middleware, we have handed off the otherwise slower yielding task of data fetching over to a route handler, which does it well in itself under the hood.

Other Advanced Route Handler Use Cases

Beyond the 3 examples above, Next.js 16 route handlers are a great fit for:

Implementing draft mode with Next.js 16 draftMode APIs, where third-party CMS data is accessed via a route handler.
Features A/B testing, where feature-related live user data is fetched through a route handler.
Handling webhooks from third-party services like payment gateways, instrumentation tools, CMS content providers, and the like.
Redirecting requests to a callback URL sent by third-party service workflows.
Implementing mailers from fetched/aggregated data.
Streaming responses from LLM models.
Handling server-sent events via the SSE protocol.

Next.js 16 Route Handlers - Pitfalls & Best Practices

While route handlers bring a powerful backend-for-frontend model to the App Router, they also introduce important architectural considerations. To use them effectively, especially for non-trivial backend logic, you need to be aware of their runtime constraints and apply performance-friendly patterns.

Next.js Route Handler Limitations

Because Next.js deploys route handlers as serverless functions (Node or Edge runtimes), they come with inherent limitations:

WebSockets cannot be used reliably due to connection timeouts.
Shared state between requests is not guaranteed; execution is isolated and ephemeral.
File-system writes may not work in serverless environments.
Lengthy or blocking operations may be terminated due to execution time limits.

These constraints should guide how much work you push into a route handler and when to offload tasks elsewhere.

Advanced Next.js 16 Route Handlers Best Practices

Just like other aspects of Next.js 16, route handler best practices obviously involve making proper trade-offs between cost and performance.

Since Next.js route handlers are serverless and subject to timeouts, we need to make sure route handlers are implemented in such a way that optimizes persistent performance against the cost of the processes handled at the route.

To get consistent performance and predictable behavior, keep the following best practices in mind:

Minimize long-running data transformations. Push heavy workloads to background jobs or external services whenever possible.
Reduce the number of aggregated data sources. If you’re combining more than a few external APIs, consider a dedicated aggregator service.
Use granular, specialized route handlers. Smaller handlers are easier to cache and revalidate using Next.js dynamic and revalidate configs.
Apply scoped access control. Use middleware matchers, location-based or role-based strategies, or shared higher-order middleware to keep endpoints secure and performant.
Leverage shared middleware for context forwarding. Keep route handlers focused and push repeated logic, like auth, logging, or header injection, into shared HOF middleware where possible.

Summary

In this post, we explored how Next.js 16 route handlers can power both standard and advanced server-side features within an App Router application. We began by reviewing how route handlers implement RESTful JSON APIs and then added a CSV file download endpoint built entirely in a route handler.

From there, we demonstrated how route handlers can take on more complex backend tasks, including a currency-conversion API backed by a location-aware proxy layer. We also implemented a redirect-management middleware using Vercel Edge Config and saw how a dedicated route handler improves performance by handling redirect lookups outside the middleware.

Finally, we touched on additional advanced use cases, along with the limitations and best practices to keep in mind when using route handlers for production workloads.

Originally published at strapi.io

Strapi 5 Migration: Why It Is Essential for Modern CMS

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 10:48:53 +0000

Introduction

We are living in a dynamic digital-only era where a content management system (CMS) is much more than just a publishing tool. In 2025 and beyond, it will serve as the core engine powering omnichannel experiences, customer engagement, and organizational agility.

To align with these demands, Strapi released its Strapi 5 update that has redefined how enterprises can model, deliver, and scale their digital content strategies.

Enterprises that are still relying on Strapi v3 or v4 are beginning to feel the impact of performance bottlenecks, limited API flexibility, and declining support options. This is why migrating to Strapi 5 is no longer just a migration option for businesses; it’s the right way forward.

This blog will explore the significant need to upgrade to Strapi 5 as an enterprise, what it can benefit you with, and what organizations can do to ensure a smooth transition.

Why Staying on Strapi v3 or v4 Holds You Back?

Staying with the older versions of Strapi can seem like a safer option from an enterprise mindset, but that comes with associated technical debt.

As Strapi continues to update, support for old versions will gradually lapse, and businesses will face difficulties fixing bugs & adding security updates, as well as new features that are available to them on the latest versions automatically.

One other area that can be impacted is performance. Even on versions 3 and 4, some businesses with higher visitor volumes experience latency issues.

Moreover, new tools, APIs, and technologies, such as Strapi AI, are being developed with Strapi 5 compatibility as the baseline, making it harder for legacy versions to keep pace. These challenges not only slow down business operations but also result in severe financial losses for the business.

Let’s understand this further with an example of API performance difference in both versions:

In Strapi v4, fetching multiple content types often required nested queries:

const articles = await strapi.db.query("api::article.article").findMany({
  populate: ["author", "category"],
});

However, in Strapi 5, this is optimized with the new Query Engine API for faster population and cleaner syntax:

const articles = await strapi.db.query("api::article.article").findMany({
  populate: { author: true, category: true },
});

This not only simplifies code readability but also improves query speed by up to 30% in production environments.

Key Advantages of Strapi 5 for Enterprises

Migrating to Strapi 5 offers multiple advantages for enterprise-grade transformation. In this section, we will briefly explore these benefits.

1. Future-Ready Architecture
Strapi 5 possesses a more modular and extensible architecture, powered by Strapi AI at the core. This means enterprises can update their tech stack seamlessly without restrictions, deliver smarter content experiences, and have better integration flexibility for newly launched tools and future upgrades.

2. Improved Content Modeling
One of the standout capabilities of Strapi 5 is the new content type builder. This version enables faster and simpler modeling through Strapi AI, which reduces the complexity of centralizing multiple content types across different platforms. With minimal complexities, your teams spend less time on configuration and more on creating & publishing content.

3. Improved Performance and API Responding
APIs are the lifeline of any headless CMS. This is why Strapi 5 is designed to provide an enhanced API experience, meaning you can expect faster API calls and reduced latency. They offer tangible benefits for enterprises with global audiences - you'll notice improved response times and enhanced content delivery experiences.

4. Improved Developer Experience
Another benefit of Strapi 5 is that it provides developers with a better experience, as it comes with enhanced tools/features, including 100% TypeScript, a new API response format, a launchpad demo app, enhanced content versioning, history, and draft management, and more. This helps improve their productivity and reduce deployment timelines.

5. Improved Security Measures
The new version also features enhanced security capabilities. These features include enhanced encryption protocols, improved options for user authentication, and regular vulnerability assessments to help safeguard your critical data. These features help ensure compliance with industry standards and safety from rising cyber threats for both the CMS and your integrated system.

6. New Plugins Ecosystem
Lastly, Strapi 5 covers a more enhanced plugin ecosystem, including Plugin SDK and a dedicated Plugin CLI. This allows the developers of a professional Strapi development company to either build custom plugins or integrate community-built plugins more seamlessly, thereby extending Strapi’s functionality as per your use case without disrupting the entire workflow.

Steps of Migration from Older Versions to Strapi 5

Migrating to Strapi 5 requires planning but offers substantial long-term returns. The step-by-step migration involves:

Step 1: Preparing the environment

The first step of the Strapi 5 migration is to back up all your Strapi assets, including your database, uploads, and configuration files.

# Backup MongoDB or PostgreSQL data
pg_dump -U <db_user> -h <db_host> -Fc <db_name> > backup.dump

Also, ensure that your infrastructure is compatible, and you’re using Node.js 18 nd npm v9+ to proceed with migration, as Strapi no longer supports older versions.

Step 2: Migrating content models and APIs

Once your data is backed up and the installation is completed, the next step is to migrate the content models and APIs. The best part of this version is that it introduces a more declarative content-type schema.

If you’re coming from Strapi v4, you’ll notice configuration paths and naming conventions have changed.

When migrating from Strapi v4 to Strapi 5, the model schema is automatically transitioned with npx @strapi/upgrade major. This eases the content model migration process.

However, remember that custom codes, controllers, services, and policies still require manual updates. For more information, you can refer to the Strapi 5 migration documentation.

Now, let’s understand Strapi v4 → Strapi 5 migration for content type structure with an example:

Strapi v4 Structure:

/src/api/article/models/article.settings.json

Strapi 5 Structure:

/src/api/article/content-types/schema.json

Step 3: Updating Custom Plugins and Middlewares

Custom plugins designed in Strapi v3/v4 may depend on deprecated APIs and require changes based on the new architecture. Hence, updating them becomes essential for plugin lifecycle consistency.

With the new plugin SDK introduced in Strapi 5, creating custom plugins becomes seamless as it allows modular development and reduces complexity.
Here’s how you can update plugin architecture to new APIs:

// Strapi v4 plugin export
module.exports = ({ strapi }) => ({ ... });

// Strapi 5 plugin export
export default ({ strapi }) => ({ register() {}, bootstrap() {} });

Step 4: Testing and validation

Testing is essential to ensure application performance, security, and API responses meet enterprise standards. Once the plugin update and content model migration are completed, begin the testing phase.

Run automated test suites to validate API responses, permissions, and content delivery.

To explain with an example, you can test API response validation (using Jest):

test("GET /api/article returns valid response", async () => {
  const response = await request(strapi.server.httpServer).get("/api/articles");
  expect(response.status).toBe(200);
  expect(response.body.data).toBeDefined();
});

Also, make sure to use Strapi’s built-in --watch-admin flag to rebuild the admin panel dynamically during testing:

npm run develop --watch-admin

Step 5: Deploy on Strapi Cloud or Self-managed Cloud Setup

Once all steps have been completed and the testing is done, you can push the changes to your CI/CD pipeline & deploy it on Strapi Cloud or any other third-party compatible setup.

Using Strapi Cloud is suggested to improve functionality and compatibility with the provided features and tools of Strapi 5.

For example, for Strapi 5 deployment with GitHub, run this command-

Additionally, enterprises can cut migration complexity, reduce downtime, and optimize Strapi 5 adoption by working with an experienced Strapi development company. The technical expertise helps with faster deployment and time-to-market, without disrupting the existing operations.

Significant Strapi Feature Updates You Should Know

The Strapi 5 update is significantly focused on enterprise-grade innovation, and to enable that, it has released two major feature updates: Strapi AI and enhancements to Strapi Cloud.

For organizations planning a Strapi 5 migration, these advancements ensure a modern, efficient, and future-proof CMS foundation.

Let’s quickly understand these updates, their significance in Strapi 5, and how they can support your unique business requirements.

Strapi AI

The newly launched Strapi AI brings generative AI capabilities directly into the CMS interface, enabling businesses to build intelligent content workflows. This feature helps teams accelerate content creation with a smart prompting mechanism, automate editorial suggestions, and improve SEO readiness with context-aware recommendations. It can summarize, rephrase, or localize content without leaving the CMS dashboard and can seamlessly integrate with your existing content approval flows.

Additionally, you can generate entire content schemas via AI chatbots either by running a prompt or by uploading a Figma file / an existing frontend app. The infusion of Strapi AI reduces manual efforts and helps you maintain consistency across channels.

Strapi Cloud Enhancements

Strapi Cloud has evolved to simplify deployment and scaling for global enterprises.
With upgraded CI/CD integrations, automated scaling across multiple environments, and built-in monitoring tools, it now delivers a truly enterprise-ready platform for seamless application development, testing, and deployment.
The latest enhancements include one-click Strapi version upgrades, strengthened security and authentication, advanced caching, and a high-availability infrastructure designed to ensure fast, reliable global content delivery.

How Does Successive Digital Simplify Strapi 5 Migration?

With over a decade of experience in CMS development & modernization, Successive Digital doesn’t just migrate your content management engine; they can transform your entire business ecosystem for a 360-degree transformation experience.

To be precise, in the context of Strapi 5 migration, they seamlessly migrate content models, APIs, and custom plugins with zero data loss, re-architect your stack to maximize Strapi 5 scalability and flexibility, optimize API performance and system security, and lastly, conduct rigorous testing to guarantee zero downtime for your ongoing operations.

Therefore, whether you’re on Strapi v3 or v4, their proven frameworks ensure a smooth and cost-effective upgrade to Strapi 5.
Here are a few project glimpses that demonstrate their capabilities:

Real-World Impact of Strapi 5 Migration

Yatra
Successive assisted Yatra in modernizing its systems by moving its legacy CMS to Strapi. This led to a 40% reduction in costs and a 20% increase in user engagement.

MyStays
Successive Digital migrated MyStays’ legacy system to Strapi, which streamlined booking by 25% and reduced time spent on content management by 40%.

Final Thoughts

In a digital economy where customer experience is paramount, using outdated versions of a CMS is a significant risk. This is the reason why Strapi 5 migration is recommended for enterprises expecting optimal operational continuity, rather than experiencing performance bottlenecks.

This new version serves as an enabler of agility, scalability, and AI-driven innovation for these established brands, allowing them to deliver an enhanced digital experience.

Furthermore, working with experts in developing Strapi-based applications, like Successive Digital, will help ensure your migration from Strapi v3 or Strapi v4 to Strapi 5 is seamless and is strategically aligned with your business goals.

In a nutshell, Strapi 5 is the present and the future of content management and digital experience ecosystem. Hence, to stay ahead and competitive, enterprises must plan a migration.

Originally published at strapi.io

How to Run A/B Tests with Strapi to Boost Conversions

Theodore Kelechukwu Onyejiaku — Fri, 06 Feb 2026 10:44:41 +0000

Experimentation is one of the most effective ways to make better product decisions. Among the most widely used methods is A/B testing, a technique that helps teams validate ideas with real user data before rolling out changes broadly. If your website is powered by Strapi, combining it with a headless A/B testing platform enables you to launch experiments and optimize conversion rates without friction.

In this post, we’ll cover the essentials of AB testing, best practices, common pitfalls, and how you can set up experimentation with Strapi and Croct.

What is A/B testing?

At its core, A/B testing is the process of comparing two or more versions of a page, component, or strategy to determine which one performs better in achieving a predefined goal.

For example, you might test different headlines on your landing page to determine which drives more sign-ups. By randomly exposing a percentage of traffic to each version, you collect data that enables you to measure the impact of changes before making a full commitment.

When should you run A/B tests?

A/B testing is most valuable when you’re unsure about how changes in your interface or content could impact user behavior, revenue, or engagement. For instance:

Deploying a website redesign
Testing alternative CTAs
Validating new navigation layouts
Experimenting with pricing pages and product cards

Beyond these examples, here are some situations where running an A/B test can make a real difference:

Early-stage features: When you’re introducing a new product feature and want to validate if users actually engage with it as expected.
Content optimization: When you’re unsure which copy, design, or visual assets resonate best with your audience (here you can think about running segmented AB tests.
Conversion funnels: When drop-offs happen in sign-up or checkout flows, and you want to identify which adjustments reduce friction.
Retention strategies: When you’re experimenting with onboarding experiences, emails, or in-app prompts to improve long-term user engagement.
Seasonal campaigns: When you want to compare variations of promotions or offers during high-traffic periods.

In short, you should consider running A/B tests whenever the outcome of a decision carries uncertainty and the potential impact on your business justifies the effort.

A/B testing isn’t about testing everything. It’s about testing what matters most.

Why most companies struggle with AB testing

While the concept of A/B testing sounds straightforward, many companies struggle to make it work.

Many products aren’t built with experimentation in mind, so every test feels like a bespoke engineering project, especially if the architecture is rigid. This usually means that CRO teams often depend heavily on scarce developer resources, which slows down the iteration process. If you work with product interfaces or e-commerce stores, consider that applications are usually dynamic, stateful, and connected to backend systems, making experiments more challenging than simple marketing page tests.

On the workflow and ownership side, we must account for the fact that product, growth, and engineering teams may not align on who drives experimentation. With unclear ownership, experimentation projects lead to stalled initiatives.

As if this is not enough, let's consider the technical aspect of AB testing: when improperly implemented, experiments can compromise reliability and performance, which introduces risk and analytics hurdles. If you don't have the right tooling at your side, you'll fall short.

In short, experimentation is challenging because of technical complexity, organizational misalignment, and a lack of purpose-built tools. Overcoming these barriers is key to unlocking continuous, meaningful conversion optimization.

A/B testing best practices

Running effective experiments requires more than just changing button colors. The A/B test itself is just one of many parts of a long workflow, and you should pay attention to each step with the same care as the test itself.

1. How to talk your boss into A/B testing

Sometimes, the biggest challenge isn’t technical, it’s organizational. Convincing leadership to invest in experimentation requires framing it as a lever for growth, highlighting the ROI of A/B testing, and positioning it as a competitive advantage. This guide provides practical guidance on framing the conversation, emphasizing risk reduction and continuous learning.

2. How to prioritize your AB testing hypotheses

Before even listing them, you should define what success means to you and which metrics you can use to validate it.

Listing testing hypotheses requires both data knowledge and creativity, and there's nothing better than brainstorming. You should invite all your team members to this assignment and have them consider what can improve the conversion rates. The more diverse this team is, the better.

Once you have a list of ideas to test, use a method like the ICE scoring to evaluate each option by assessing its impact, your confidence in its potential outcome, and the ease of implementation.

3. How to plan your AB testing

This should be the easiest step.

Start by defining your primary and complementary metrics. Gather current traffic and conversion rate information to estimate the experiment duration beforehand (this calculator can help you). Then, define which method you will use to analyze the results.

If you have a tight calendar, running multiple tests simultaneously may sound tempting. Don't do that. Overlapping experiments could interfere with one another, so our advice is to keep it simple and test one hypothesis at a time.

Finally, ensure that you include a step for documenting and sharing the learnings. Even failed experiments produce valuable insights. Maintain a knowledge base to prevent teams from repeating the same tests or mistakes.

How to analyze your experiments

Once the data comes in, it’s crucial to analyze the results correctly. Two common approaches are frequentist and Bayesian statistics, and we could write a whole article about each of them.

While frequentist methods have been the standard for decades, Bayesian methods are increasingly popular due to their flexibility, intuitive insights, and faster conclusions.

If you want to dive deeper into each of these topics, we suggest these two guides:

Which tools can you use?

The right tool can make or break your experimentation workflow. Choosing the right one depends on your team’s technical expertise and needs. It's not an easy task.

Before discussing names, consider the four types of tools and the level of development dependence each one brings.

1. No-code and low-code tools

Tools like VWO and Convert allow marketers and product managers to create experiments without any developer involvement.

These tools typically provide a visual editor for modifying elements on a webpage and tracking conversions, but offer limited to no flexibility for complex experiments, and usually impact page performance due to client-side execution.

2. Headless experimentation platforms

Platforms like Croct and Optimizely provide AB testing and personalization directly within the content management system.

These tools integrate seamlessly with dynamic websites, enabling teams to manage experiments without incurring engineering overhead, flickering, or performance issues. However, it requires a developer for the first integration and doesn't provide full flexibility for marketers in terms of design and layout.

3. JavaScript-based tools

JavaScript-based tools, such as AB Tasty, Amplitude Experiments, and Dynamic Yield, require a basic knowledge of JavaScript but offer more control over experiments. They typically involve embedding a script into the website to dynamically modify elements, which increases the dependence on developers for technical support at each test.

4. Feature flag

Feature flag tools like LaunchDarkly and Split.io allow teams to deploy new features to a subset of users without affecting everyone. Developers widely use them to roll out and test changes gradually, making them useful for backend-controlled experimentation.

5. Fully developer-driven

These solutions offer the highest level of flexibility and control, enabling engineers to implement and manage A/B testing directly within the codebase. They’re often combined with analytics platforms for result tracking.

How to run AB tests on Strapi-powered websites

There are many A/B testing tools on the market, but if you’re working with Strapi, Croct provides an out-of-the-box solution for experimentation and personalization. It stands out by offering:

Component-level experimentation, ideal for modern frontend frameworks
Real-time updates without redeploying code
Advanced user segmentation and personalization capabilities
Easy API-first integration with Strapi

This Strapi's guide walks you through adding experimentation on top of Strapi content, without complex development cycles.

Additionally, Croct provides Strapi CMS integration templates to help you get started quickly with minimal setup.

Conclusion

A/B testing is a crucial tool for developing products and websites with higher conversion rates. By combining Strapi with Croct, you can empower your team to experiment faster, personalize content at scale, and base decisions on data rather than guesswork.

If you’re ready to start running A/B tests and personalizing your Strapi-powered website, Croct is the easiest way to get there. Start planning your experiments today and see how it can take your website to the next level.

Originally published at strapi.io