Rebuilding the Kernelics Website with Next.js, Strapi, and Jamstack: Why We Left WordPress Behind

This article reflects on our journey re-implementing the Kernelics website using tools from the JavaScript ecosystem, an effort that brought technical alignment, flexibility, and long-term maintainability to a site that had started to hold us back.

Why we initially chose wordpress for our website?

When we launched in early 2020, our focus was on building partnerships and landing our first clients. Marketing wasn’t a priority, and a website felt more like a “nice-to-have.” We even joked: “It’s kind of weird for a software development company not to have a website… right?”

So, we decided to outsource the initial build to our partners, a team experienced with WordPress development.

After about two months of traditional development, our first corporate site went live. At that stage, we were happy. The UX was decent, and the WordPress admin panel made it easy to create and update content without touching code. For a company in its first year, it worked.

The limitations of wordpress: what slowed us down

Over time, cracks started to show:

• UI/UX issues appeared with certain content types, especially edge cases that often slip past in one-off builds.
• Extending the site was difficult. WordPress’s template system meant mixing HTML, PHP, and we had even experimented with embedding Vue.js components via shortcodes and iframes for interactive elements. Managing this hybrid stack quickly became painful.
• Our stack had matured. We were fully focused on the JavaScript ecosystem. WordPress and PHP no longer matched our tech direction, and since no one in-house worked with that stack, we depended on costly external help.
• Our own JavaScript engineers couldn’t contribute effectively to the site.
• The UI started feeling outdated. We were thinking more seriously about reusable components and unified practices across projects.
• Marketing and sales teams had emerged, and the website had become a key channel, but we had a growing backlog of changes we couldn’t implement efficiently.

Eventually, we made the decision to rebuild the website entirely, using a modern tech stack aligned with our internal tools and long-term goals.

Choosing the right frontend stack for a modern website

We selected React for our website rebuild because it's the core frontend framework used across our projects.

But building a high-performing, SEO-friendly website for marketing and sales teams requires more than just a traditional single-page application (SPA) setup like Create React App. These tools don’t support server-side rendering out of the box, which limits SEO and performance at scale.

To meet real-world business needs, a website needs to achieve:

• Speed: fast load times and strong Lighthouse scores
• Flexibility: ability for marketing teams to request and test layout or copy changes
• SEO optimization: server-rendered content, clean URLs, structured metadata
• Content management: enabling non-technical team members to update pages without developer assistance

SPA-based setups often fall short at scale: performance bottlenecks, SEO workarounds, and constant developer involvement slow progress.

Why we used next.js for server-side rendering and static generation

The fastest web pages are static HTML and CSS, ready to render on load. Traditional React apps, however, render UI in the browser using the virtual DOM, meaning the user’s device does the work before seeing anything.

The solution is server-side rendering (SSR). Instead of sending JavaScript to the browser and letting it build the UI, we pre-render the page server-side and send fully styled HTML. The result is faster time-to-interactive, improved SEO, and no loss in interactivity.

SSR and static site generation are often grouped under the broader Jamstack umbrella, though the community increasingly distinguishes between static-first Jamstack sites and hybrid-rendered frameworks like Next.js.

Our jamstack frontend tech stack

We built the new site with the following frontend stack:

• Next.js + TypeScript for hybrid static generation and SSR, modular routing, and type safety
• SCSS as our CSS preprocessor
• Styleguidist for documenting UI components
• Vercel for zero-config deployments, instant previews, and excellent developer experience

This stack gave us the best of both worlds: a dynamic, React-based development flow paired with Jamstack’s performance and scalability benefits.

Wordpress backend limitations that led to rebuilding

Before committing to a full backend rewrite, we tried to squeeze as much life as possible out of our existing WordPress setup.

We explored both REST (available out of the box) and GraphQL (which required more setup). REST was functional, but overly verbose, every response included unnecessary metadata. GraphQL, while more efficient and flexible in theory, proved difficult to configure in practice.

The biggest issue? Our backend was built around Advanced Custom Fields, which didn’t play nicely with GraphQL plugins. Support was limited and unstable.

After a few rounds of failed experiments, it became clear:

• REST worked but wasn’t efficient.
• GraphQL wasn’t viable with our setup.
• Making changes to the data schema was time-consuming, even with plugins.
• The admin UX was confusing, new content managers struggled to use it without technical help.
• We had a single WordPress instance in production, with no deployment workflow or staging setup.

All of this pointed to a fundamental mismatch between the stack and our needs.

Why we chose strapi as our headless CMS?

We decided to rebuild the backend from scratch, this time in Node.js, fully aligned with our frontend and internal tooling.

We researched modern Jamstack-friendly CMS options and narrowed it down to two top choices: Strapi and Directus. Both are strong contenders, but Strapi stood out for our use case.

Here’s why Strapi was the right fit:

• Actively maintained with frequent updates
• Large, supportive community contributing plugins and extensions
• Flexible storage support, compatible with major cloud providers
• Visual content modeling with instant API generation (REST & GraphQL)
• Accessible for non-technical users, intuitive enough for marketers and content managers to use without dev support

Strapi gave us exactly what we needed: a developer-friendly, headless CMS with strong customization capabilities and a user-friendly admin panel, without compromising on performance or flexibility.

Infrastructure setup: hosting and development workflow

Once we settled on Strapi for the CMS, the next step was setting up the infrastructure to support it, along with the build and delivery pipeline for the frontend.

After comparing available options, we chose the following setup:

• Heroku for the development environment, both app and database instances. At the time, Heroku’s hobby-tier plan was a low-cost option that met our needs, though it no longer offers free tiers as of 2022. (Worth noting: Heroku hibernates inactive apps after 30 minutes. We used a simple ping tool to prevent downtime during working hours.)
• Render for the production admin panel, more stable and cost-effective for live environments.
• Cloudinary as a file storage API and CDN, fully compatible with Strapi’s media system.

Environment management and deployment automation

To streamline QA and review, we created three separate frontend environments, DEV, DEMO, and PRODUCTION, each with its own domain and corresponding CMS connection:

• DEV ↔ connected to Heroku-hosted Strapi instance
• DEMO and PRODUCTION ↔ both linked to the production Strapi instance on Render

We followed a Git-based flow for both the frontend and backend:

• Frontend used develop, demo, and main branches
• Backend used develop and main

Each environment had its own branch, making it easy to isolate changes and test them in real context.

On the frontend, we hosted with Vercel, which supports atomic deploys. Every commit creates a unique deployment URL, making it simple to test pull requests with fully working previews.

For the CMS, we set up automatic deployments on pushes to develop and main, keeping the admin panel always in sync with the codebase.

With this setup in place, we established a fully functional continuous delivery pipeline, with minimal overhead.

New features and content updates could be pushed, reviewed, and deployed in minutes, letting us focus on building instead of maintaining environments.

The results of our website rebuild

Rebuilding our site with Next.js and Strapi brought immediate improvements:

• Faster performance across the board
• Significantly improved SEO thanks to SSR and clean architecture
• Easier site management and updates for both developers and marketers
• Better alignment with our internal JavaScript-based stack
• A smoother content creation and review process
• Modern workflows for deployments, previews, and QA

The site now feels like a natural extension of how we build software, not a separate system to maintain.

Since then, our website has undergone another major redesign, incorporating new requirements and technologies.

While the stack has changed, our experience working with Jamstack principles and tools like Next.js and Strapi continues to inform how we approach performance, scalability, and content workflows today.

We hope this article gives you a clear, real-world view of what it’s like to build a Jamstack site that actually works and lasts.

If you’re working with Jamstack, or thinking about it, we’re always open to helping maintain or modernize your setup. We know the technology well and understand how to apply it where it makes sense.

Feel free to reach out, we’re happy to share insights or lend a hand.