As a web developer, one question arises: Why should I use a ready-made system for my own website when I can build it completely myself? That was originally my plan. Today, however, florianreinertz.dev runs on Odoo, hosted directly by Odoo and not on my own server.
In this article, I explain how this decision came about and what bothered me about self-hosting. I also show what disadvantages I consciously accept with Odoo. At the end, you will find a brief classification of which model is sensible for which type of website.
The original plan: everything built myself
The plan was for a classic, self-developed website. It was to consist of HTML, CSS, and JavaScript and run on rented web hosting with Plesk. Plesk is a management interface for web servers. A requirements document and a design concept already existed.
The appeal is obvious. I would have full control over every detail, no dependency on a provider, and no features that I don't need. This works well for a purely presentation page. Problems only arise when the page is supposed to do more than just display content.
Where it gets stuck in everyday life
The contact form needs a backend
A static page can display content, but cannot process forms. For a request to actually arrive as an email, code on the server is needed, a so-called backend. On classic web hosting, PHP is the standard for this.
PHP is not my language, and I didn't want to make the page dependent on it. My preferred solution would have been Node.js. So I inquired with the hosting provider. The result: Node.js is not offered there, neither for the form nor for the platform itself.
What remained were detours, namely a single PHP file just for the form or an external form service. Both work, but both are another construction site.
Two languages need to be organized
My site is bilingual, in German and English. Building it myself means quite a bit of work:
- duplicate pages or a custom translation system
- a language switcher
- the correct linking of the language versions for search engines
This is feasible, but the effort grows with each new page.
Every extra is its own project
A blog, visitor statistics, and a properly functioning cookie banner are now part of a website. On a self-built site, each of these functions must be developed or integrated separately. Individually, this is manageable. Together, a portfolio page quickly becomes a software project that I have to maintain permanently.
The maintenance falls on me
Whoever hosts themselves is also responsible for updates, security vulnerabilities, backups, and certificates. This is not rocket science, but it regularly costs time. I would rather invest this time in content and client projects.
Why I chose Odoo
Odoo is actually a business software with many modules, from accounting to inventory. One of them is a website module. In my case, three points were particularly decisive.
Everything in one system
Forms, blog, multilingualism, and cookie banners are included directly. The contact form works without a separate backend. This solved the problems from the previous section in one go, without me having to write a single line of server code.
Hosting included, at a fixed price
The site runs directly on Odoo. I no longer have to take care of servers, updates, and security myself. A fixed monthly fee is due for this, which is affordable for the scope.
Email and domain intentionally continue to run separately with a separate provider. This way, I remain independent in this regard.
Not just a pure construction kit
For me as a developer, one point was particularly important: Odoo allows custom code. Where the visual editor reaches its limits, I use my own HTML, CSS (more specifically SCSS), and JavaScript. This creates not a standard look, but an individual design. In the background, I still have the convenience of a ready-made system.
What I accept in the process
Odoo is not a perfect solution. There are points that bother me, and they are part of an honest assessment.
The scope
Odoo is very extensive, with many settings, many modules, and often several ways to the same goal. For a website, you only need a small part of it. Nevertheless, you have to find your way around the overall system.
The onboarding takes time
Anyone using Odoo for the first time needs patience. You first have to figure out where each setting is and how pages, menus, and translations are related. Even the clean integration of custom code does not become clear in an hour.
Some things are possible, but cumbersome
One example is the double opt-in for newsletters. New subscribers confirm their registration via a link in an email. In the EU, this procedure has established itself as the standard for clean newsletter registrations.
This can be implemented in Odoo, but not with a simple checkbox, only through some detours. Such instances occur more often: the function is available, but the way there is not always intuitive.
Dependency on the provider
Anyone hosting with Odoo is tied to Odoo, meaning its pricing model and further development. Moving to another system is possible, but it requires effort. I consciously accept this risk.
Self-hosting, website builder, or Odoo: What fits whom?
The right solution depends on what a website is supposed to achieve. Here is a rough orientation:
- Pure business card on the web: A page with an offer, contact details, and maybe opening hours does not need a large system. A simple website builder or a slim, self-built page is completely sufficient. Odoo would be rather too much here.
- Page with forms, blog, and multiple languages: This is the typical need of freelancers and small businesses. Especially in a multilingual region like East Belgium, Odoo showcases its strengths here. This is especially true if the business already uses or wants to use Odoo for other tasks.
- Special requirements or full control: Custom applications, special interfaces, or unusual technology speak for a custom development with its own hosting. However, this also includes the ongoing maintenance effort. For me, the trade-off is clear: I currently prefer to accept the detours that Odoo requires in some places. The maintenance of a self-hosted site would be significantly more effort in the long run.
Conclusion
What tipped the scales was not that Odoo can technically do everything better. What was crucial for me was that I have to worry less about technology that has nothing to do with my actual goal.
Instead of maintaining form backends, servers, and translation logic, I focus on content, design, and client projects. The onboarding took time. However, I only had to invest that time once, while the maintenance of my own server would never be needed again.
Are you considering which solution is right for your website? I will advise you honestly, even if the answer in the end is not Odoo.