
We build two kinds of software on two different stacks. Business applications, such as client portals, integrations and financial tools, are built on .NET and Azure. Marketing sites are built with Next.js. For each kind of software we choose the stack where maintenance is easiest to organise.
After the critical vulnerabilities in PHP, the programming language behind WordPress and many other websites, in October 2026, an obvious question is whether that is why our marketing sites do not run on WordPress. It is not. Next.js had critical vulnerabilities of its own that same month.
Every stack runs into a vulnerability sooner or later. What matters is who does what when it happens.
Two kinds of software
Business applications hold the logic, data and permissions an organisation runs on. Think of a client portal where customers view and submit their own data, or an integration that exchanges invoices, payments and customer data between systems. An error in software like this affects day-to-day operations. We maintain this software for years. Together with the client, we keep developing it.
We build these applications on .NET and Azure, Microsoft's platform. Azure handles sign-in, permissions and storage in one environment and connects to the Microsoft services that many organisations already use. New applications follow the same fixed structure.
A marketing site asks for something else. Clients want to change text, images and pages themselves without calling a developer. The site has to load quickly and be easy to find. The design has to hold up for years, even after hundreds of changes by editors.
For that we use Next.js, with Sanity for content management and Vercel for hosting. We keep site and application separate. Sensitive customer data stays in the application. The site links to it, for example with a button to the client portal.
Why not everything in .NET
It is possible. One stack for everything has its advantages: one language, one way of building and one way of maintaining.
For marketing sites, other things matter more. Next.js is built for websites. Speed and search engine visibility come as standard.
Sanity is built for editors. An editor sees straight away how a page will look while editing, and works with fields we set up for each site. All of that can be built in .NET, but then we build and maintain it ourselves. With Next.js and Sanity it comes included and a large community keeps it up to date.
For an application the trade-off is reversed. There, reliability, data security and the connection to Microsoft services matter more than convenience for an editor.
Why not WordPress
WordPress is the best-known choice for websites. It has a mature admin environment, plenty of themes and a plugin for almost every function. For a small site that is quick and affordable.
Most of the maintenance sits in those plugins. Each plugin is code from another party, with its own update schedule. According to Patchstack, more than nine out of ten vulnerabilities found in the WordPress ecosystem were in a plugin.
On top of that, much of a WordPress site lives in settings in the admin screen, outside the code. Which setting was changed when is therefore hard to trace. In our marketing sites the entire structure of the site is defined in code, with a history of every change. Only the text and images live in Sanity.
What the choice delivers
- No server of our own. There is no server for us or the client to look after. That saves maintenance.
- Editors see only what they need. Design and technology stay out of reach.
- Widely used technology. Next.js is among the most widely used technologies for websites. That gives certainty for the long term: the site stays easy to maintain and develop further.
Who patches when there is a vulnerability
With a WordPress site, the hosting provider and the site's administrator have to update it themselves: PHP on the server and the plugins in the site. With a managed service such as Vercel, the platform takes over part of that work. How large that part is varies per vulnerability. Sometimes sites on the platform are not affected, sometimes the platform puts extra protection in place and updating is still required.
Updating the site itself therefore remains our job, just as it is for the applications.
The trade-off
For business applications, maintenance lies with us and Microsoft. For marketing sites it lies with us and Vercel. The security of a site does not lie in the name of its stack. It lies in who updates it when a vulnerability appears and how quickly that happens.