What it means to own the code instead of a theme—custom layouts, real integrations, AI APIs without plugin limits, and a codebase that grows with the business.
Flexibility in a CMS is bounded by what the theme and plugin authors decided to support. Flexibility in a code-first Next.js project is bounded by what is technically possible in a web application—which is a much larger space. New layouts, new integrations, new AI providers, and new product features all follow the same path: write the code, review it, deploy it.
The cost of that flexibility is that someone needs to understand and maintain the code. The client workflow is designed to keep that responsibility clearly with the developer while keeping the client in control of direction.
On a template-driven CMS, flexibility is determined by what the theme author and plugin developers chose to support. If you need a layout that falls outside the theme's options, you are either modifying someone else's PHP—which breaks on the next theme update—or installing a page-builder plugin that introduces its own constraints.
A Next.js site starts from code you own. Every page, layout, and component is written to do exactly what is needed, not adapted from a generic template. There is no theme vendor to wait on and no plugin marketplace to browse. If a design needs a three-column section that fades in on scroll with a live data feed, that is something you build, not something you hope a plugin ships.
This ownership also extends to performance. A template often ships JavaScript, CSS, and markup that applies to every possible layout a theme might use, whether your site uses those features or not. A code-first project ships only what is in it.
Components in React are composable. A section, a card, a navigation pattern, a form—each is a self-contained piece that can be reused, combined, and customized independently. Changing the way a component looks across the entire site is a change in one file, not a search-and-replace through a database of post metadata.
Responsive behavior, animation, and interactive states are all expressed directly in the component. There is no theme settings panel that overrides your intentions based on options you did not know existed. What the developer writes is what the browser renders.
A/B testing and experimentation can be implemented as real feature flags or split routes in Next.js, with the test logic in the application code rather than in a third-party plugin that requires a paid tier and an external dashboard to manage.
Connecting a WordPress site to a third-party service usually means finding a plugin someone built for that service, checking when it was last updated, installing it, and trusting that it does not conflict with the other plugins already running. For many integrations, the plugin option does not exist at all.
A Next.js app connects to third-party services the same way any modern web application does: over HTTPS, using the service's official SDK or REST/GraphQL API, called from a server route so credentials stay off the client. The Stripe SDK, the Anthropic SDK, a custom business intelligence API, a CRM webhook receiver—these are all npm packages or fetch calls, not plugin installs.
When a service changes its API or releases a new SDK version, updating the integration is a normal package upgrade. There is no third-party plugin author standing between the service and the site.
The AI API landscape moves fast. New models, new providers, new capabilities, and breaking API changes happen on a timescale of weeks, not quarters. A site built on a plugin-based CMS can only use AI features that a plugin author has chosen to expose, in the shape the plugin author chose, updated when the plugin author gets around to it.
A Next.js app accesses AI APIs directly. The Anthropic Claude SDK, OpenAI, Mistral, Google Gemini, and any other provider with a REST API or npm package can be called from a server route. The site in this repo already has a working AI chat route built on the Anthropic SDK—a capability that required no plugin install and no third-party dashboard.
Streaming responses, function calling, tool use, multi-step agent workflows, retrieval-augmented generation with a vector store—these are all achievable in a Next.js app because the application layer is real code, not a configuration interface built by a plugin author for an older version of a model.
When a better model or a lower-cost provider becomes available, swapping it in is a dependency change and a few lines of code. The site follows the AI ecosystem's pace, not the pace of a plugin marketplace.
Software requirements change. A site that starts as a marketing brochure may need a member portal a year later. A contact form may evolve into a full intake workflow with email automation and CRM sync. These additions are normal scope expansions for a code-first application: new routes, new API connections, new database tables.
On a CMS, the same expansion often requires switching page builders, hiring a specialist in a particular WordPress stack, or migrating to a different CMS entirely. The site is hostage to the decisions made when the theme was chosen.
Because the Next.js project is source code in a Git repository, the codebase can grow with the business. A new feature is a branch, a pull request, a review, and a deploy—the same workflow regardless of how much the scope has grown from the original site.
A code-first approach is not a free lunch. It asks for a developer who can read and write the codebase, review dependencies, and make deliberate decisions about what is added. The flexibility that comes from owning the code is only useful if someone understands the code.
For clients, this means the relationship with the developer matters. Clear briefs, review of preview builds, and a feedback loop (described in the client workflow section) replace the ability to log into a dashboard and edit things directly. That is the tradeoff: less self-service in the moment, more capability and fewer surprises over time.
For arvintech projects specifically, the workflow is designed so clients stay informed and in control of direction without needing to touch the code. The developer handles the implementation; the client approves it. That separation is what makes large-scale flexibility achievable without creating confusion.
Want to explore more about how this site is built?