Next.js
Websites and dashboards: pages generated at build time when possible, a server only when needed.
Technology
Why we build with React, Next and Node
Not out of fashion, and not out of contempt for anything else. Because of how each option behaves when the project grows, when it has to be maintained for two years and when somebody tries to attack it.
An honest comparison
| React / Next.js + Node | Custom PHP | CMS (WordPress and similar) | LMS (Moodle and similar) | |
|---|---|---|---|---|
| Performance | HTML generated at build time and served statically; interaction does not reload the page. | Good if looked after; every page is generated on every visit unless caching is added. | Depends on the theme and the plugins. Ending up with caches on top of caches is common. | Heavy by design: it does many things for many roles. |
| Attack surface | Static site: no database and no admin panel to attack. On the server side, only our own code. | Whatever you write. Entirely dependent on team discipline. | Core + theme + every plugin, each with its own patching pace. Most incidents come from there. | Large, and with student personal data inside. Updating is not optional. |
| Mid-term cost | A fast start with AI agents and little maintenance afterwards. | Cheap to start, expensive if nobody documents. | Very cheap to start; the cost shows up in plugin licences and updates that break things. | Low if it fits you as is; high as soon as it needs customising. |
| User experience | Stateful applications, real time and transitions without reloads. | Fine for classic websites; real time has to be bolted on. | Excellent for publishing content; limited for your own workflows. | Designed for courses, not for your business process. |
| Technical SEO | Full HTML from the first byte, metadata and structured data per page. | Good; everything has to be written by hand. | Very good out of the box, with mature plugins. | Irrelevant: the content usually sits behind a login. |
| Who maintains it | A team that knows JavaScript. That is the real requirement. | Easy to find, wide quality range. | Anyone can publish without touching code. That is its great advantage. | Administrators trained on the platform. |
Let's be honest
When you should NOT hire us
If your website is a blog, a standard shop or a corporate site that non-technical people will update, a CMS is the right answer and the cheap one too. Same with an LMS: if you need courses, enrolments, marks and certificates the usual way, Moodle has been solving that for twenty years and rewriting it makes no sense.
- You need to publish content daily without depending on anyone: CMS.
- You want a standard shop with payment and shipping already integrated: an e-commerce platform.
- You run courses with the classic enrol, assess and certify flow: LMS.
- You have your own processes, integrations with your systems, real time or serious volume: that is where we come in.
What we use
And what we use each thing for
React
Stateful interfaces, real time and components reused across projects.
Angular
Large internal applications for teams that already work this way: strong structure and clear conventions.
Node.js
APIs, background processes and real time over sockets, in the same language as the browser.
Kotlin
Native Android, when you need voice, real notifications or system access.
Mongo and SQL
Document stores for things that change shape, relational for things that must add up.
Frequently asked
What we always get asked
Is WordPress insecure?
The WordPress core is well maintained. The typical problem is not the core, it is the plugins: each one is third-party code on its own update schedule, and it only takes one falling behind. If you use it, treat it as what it is: a live application that needs updates and backups, not a website you leave sitting there.
Is custom software slower to build?
Not with us. We work with AI agents that write, test and deploy the code, so getting started takes days, just like setting up a CMS with a theme. This very website was built that way. The difference comes later: when you need something the theme never considered, a CMS means fighting the system, while in your own code you just write it.
Why a static site for this very website?
Because it needs no server: it is files. Nothing to restart, no database to secure, it can be served from anywhere, it survives any traffic spike and the attack surface is practically zero. If server logic is ever needed, the same code can move to a server without a rewrite.
What if we want to switch supplier tomorrow?
The code is yours and lives in a repository with its history, automatic deployment and documentation. The technology is standard and plenty of people know it: it is not a proprietary format only we understand.
Do you use AI to write the code?
Yes, and we do not hide it: this very website was built by our assistant. What does not change is review: everything goes through a branch, a merge request and a deployment with rollback. AI speeds the work up; it does not replace whoever answers for it.
Shall we talk about your case?
We will tell you frankly whether what we do suits you or not.