Next.js
Websites and management dashboards. Pages are prepared in advance whenever possible, and a server only steps in when needed.
Technology
Why we build with React, Next and Node
React and Next.js are the tools we use for what you see on screen; Node.js handles the work behind it, on the server. We chose them for how they hold up when a project grows, when it has to be maintained for two years and when somebody tries to break in.
How the usual options compare
| React / Next.js + Node | Custom PHP | Content manager or CMS (WordPress and similar) | Course platform or LMS (Moodle and similar) | |
|---|---|---|---|---|
| Speed | Pages are prepared before they go live and arrive ready-made. While you use the application, the page never fully reloads. | Good if looked after, although every page is rebuilt on every visit unless you add a cache, a stored copy that is served faster. | Depends on the theme and the plugins. Ending up with one cache on top of another is common. | Heavy by nature, because it does a lot for many kinds of user. |
| Where it can be attacked | A static website has no database and no admin panel to attack. Where there is a server, only our own code runs on it. | Entirely down to the code that gets written and how disciplined the team is. | The core, the theme and every plugin, each with its own pace of security patches. Most incidents start there. | In many places, and it holds students’ personal data. Updating is not optional. |
| Mid-term cost | A quick start because we work with AI agents, and little maintenance afterwards. | Cheap to start; expensive if nobody documents what was done. | Very cheap to start. The cost turns up later, in plugin licences and updates that break things. | Low if it suits you as it is. It goes up as soon as it needs adapting. |
| What users notice | Applications that update themselves in real time and move between screens without reloading. | Fine for classic websites; real time has to be added separately. | Very good for publishing content and thin for your own work processes. | Designed for courses, not for the day-to-day running of your business. |
| Showing up in search (technical SEO) | Every page reaches the search engine complete from the start, with its title, its description and the data Google uses to understand it. | Good, but everything has to be written by hand. | Very good out of the box, with well-tested plugins. | Irrelevant: the content usually sits behind a login. |
| Who maintains it | A team that knows JavaScript, the language everything is written in. That is the only real requirement. | Easy to find someone, though quality varies a lot. | Anyone can publish without touching code, and that is its great advantage. | Administrators trained on the platform. |
Before you call us
When hiring us is not worth it
If your website is a blog, an ordinary shop or your company site, and people without technical skills will keep it up to date, what you need is a content manager (CMS) such as WordPress, which is also cheaper. Training works the same way. For enrolments, marks and certificates done the usual way, Moodle has been doing the job for twenty years and there is no point rebuilding it.
- You need to publish content every day without relying on anyone: a CMS.
- You want a standard shop with payments and couriers already connected: an e-commerce platform.
- You run courses with the classic enrol, assess and certify path: a course platform (LMS) such as Moodle.
- You have your own processes, need your programs to talk to each other, want live data or handle serious volume: that is where we fit.
What we use
What each tool is for
React
Screens that respond instantly to what you do or to what changes, built from pieces we reuse between projects.
Angular
Large internal applications for teams that already work with it. It imposes a firm structure and clear rules.
Node.js
The server side: connections with other programs (APIs), background jobs and real-time alerts. It uses the same language as the browser.
Kotlin
Native Android apps, for when you need voice, proper notifications or access to the phone’s features.
Mongo and SQL
Two ways of storing data. Mongo for information that changes shape; SQL for information that has to add up.
Frequently asked
What people usually ask us
Is WordPress insecure?
The WordPress core is well maintained. Trouble usually comes from the add-ons (plugins): each is written by a third party, updates on its own schedule, and it only takes one falling behind. If you use it, plan on updating it and taking backups regularly. It is a living application and cannot just be published and left alone.
Does a custom website take longer to build?
Not with us. We work with AI agents that write, test and publish the code, so getting started takes days, the same as setting up a CMS with a theme. This website was built that way. The difference shows later: when you need something the theme does not include, a CMS means fighting the system, and with your own code you simply write it.
Why is this website static?
Because it needs no server: it is just files. Nothing to restart, no database to protect, it can be published from anywhere and it copes with any spike in visits. There is hardly anything to attack. If it ever needs server logic, the same code can move to a server without a rewrite.
What if we want to switch supplier tomorrow?
The code is yours. It lives in a repository with its full change history, automatic publishing and documentation. We use standard technology that plenty of people know, so another team can carry on with it without depending on us.
Do you use AI to write the code?
Yes, and we say so openly: this website was built by our assistant. Review stays the same. Every change goes on its own branch, through a review request (merge request), and is published in a way that can be rolled back. AI makes the work faster, but a person answers for it.