Why We Built Nextly

If you have built content-driven applications with Next.js, you have encountered the same decision every team faces eventually. You evaluate your options for managing structured content, and you find that every framework falls into one of two camps. Each camp has genuine strengths, and each has trade-offs that become painful over time. We built Nextly because we wanted to stop making that trade-off.

The code-first camp

Payload CMS is the best example of code-first done right. You define your content schema in TypeScript, your content structure lives in your codebase, and you get all the benefits that come with treating schema as code: version control, type safety, IDE autocomplete, pull request reviews, and automated testing.

Sanity takes a similar approach with its schema definitions. The developer experience is excellent. You write code, you deploy code, and your content structure follows the same lifecycle as the rest of your application.

The strength here is real. When your content schema is defined in code, you can review changes before they go live. You can roll back a bad schema change with a git revert. You can write tests that validate your content structure. You can use CI/CD pipelines to deploy schema changes alongside application changes.

But there is a gap. When a non-technical team member needs to add a new field, adjust a validation rule, or create a new content type, they cannot do it themselves. They need a developer. Even a simple change like adding a subtitle field to a blog post becomes a ticket, a code change, a review, and a deployment. For fast-moving teams, this creates a bottleneck that slows everyone down.

The visual camp

Strapi pioneered the visual content type builder that lets non-technical users create and modify content structures through a graphical interface. WordPress, Directus, and similar tools follow the same philosophy. You click to add fields, drag to reorder, configure options through forms, and save. No code required.

This is genuinely powerful for teams where editors and content managers need autonomy. A marketing lead can add a new content type for a campaign landing page without filing a ticket. A product manager can adjust the fields on a product entry without waiting for the next sprint.

But developers lose something important. The content structure lives in the database, not in the codebase. There is no version control for schema changes. There is no way to review a content type modification in a pull request. Type safety depends on generated types that may be out of sync with the actual schema. And deploying schema changes across environments often requires manual recreation or database migrations that are separate from your application deployment.

For teams with strong engineering practices, this feels like a step backward. Schema as infrastructure should follow the same discipline as the rest of your codebase. Database adapters that handle migrations separately from application code add friction that code-first avoids.

What we wanted

We spent years working with both camps. We used Payload on projects where developer experience was the priority. We used Strapi on projects where editor autonomy was essential. Both are excellent tools that we respect deeply. They inspired much of what Nextly has become.

But every project made us wish we could have both. The TypeScript schema definitions and version control of Payload. The visual content type builder and editor accessibility of Strapi. In one framework, without compromising either experience.

The Nextly approach

Nextly treats code-first and visual as equal, first-class approaches to schema definition.

Code-first: Define collections in TypeScript using defineCollection(). Your schema lives in your codebase, is version controlled, and gets full type safety. Developers work in their editors and deploy through their normal CI/CD pipeline.

const Articles = defineCollection({ slug: "articles", fields: [ text({ name: "title", required: true }), richText({ name: "body" }), relationship({ name: "author", relationTo: "users" }), select({ name: "status", options: ["draft", "review", "published"], defaultValue: "draft", }), ], access: { read: () => true, create: ({ req }) => req.user?.role === "editor", }, }); `

Visual: Open the Schema Builder in the admin panel and build collections by adding fields, configuring options, and saving. No code, no deployment, immediate availability.

Both approaches produce the same collection. The same database tables, the same API endpoints, the same admin panel for content editors. A collection defined in code and a collection built in the Schema Builder are indistinguishable from the perspective of anyone using the admin panel or querying the API.

How teams actually use it

In practice, most teams use both approaches at different stages of a project.

Developers define the initial schema in code during the setup phase. They establish the core collections, set up access control rules, and configure relationships. This goes through code review and gets deployed as part of the application.

As the project evolves, the Schema Builder handles rapid iteration. A content strategist can prototype a new content type visually, test it with real content, and validate the structure before a developer ports it to code. When a schema change is small and low-risk, the visual approach saves the round trip through a development cycle.

For teams that want the best of both worlds, Nextly provides an export feature. Build something visually in the Schema Builder, and export it as clean, readable defineCollection() TypeScript code that you can commit to your repository.

Not a compromise

This is not a lowest-common-denominator solution. Each approach has full access to every feature in Nextly. Code-defined collections can use every field type, every access control pattern, and every lifecycle hook. Visual collections built in the Schema Builder have the same capabilities. Neither approach is a second-class citizen.

You can start visual for rapid prototyping and move to code for production. You can start in code from day one if that matches your workflow. You can use both simultaneously in the same project. The choice is yours, and you can change your mind at any point.

Open source, free, self-hosted

Nextly is MIT licensed. No per-seat pricing, no usage limits, no vendor lock-in. Self-host on your own infrastructure and own your data completely. The source code is available on GitHub.

We believe developer tools should be free. The frameworks we were inspired by have built incredible communities, and we want to contribute to that same ecosystem. If you have been looking for a Next.js framework that does not force you to choose between code and visual, give Nextly a try.

npx create-nextly-app@latest