Building a full-blown website for a company is a major task. Due to this, most companies outsource both the design and the development of the website to some specialized vendor that then delivers the final full solution. This process is slow and the delivery is often overdue. All the website projects I have seen have been published several months late.

As a startup, we had a tight schedule to get our website up and running. At the same time, the money we can spend on this kind of project is limited. Therefore, we ended up buying the initial brand design and website layouts from an external vendor and doing the actual development in-house. 

This approach gave us a lot of flexibility since we could do the initial technical development before we even had our logo designed. In practice, we set up the cloud infrastructure behind the website and chose a technology stack for the website implementation in advance.

Technology-wise, there are many options to choose from. Usually, websites are created with the help of some content management system (CMS). WordPress is the most popular CMS out there. We did not choose WordPress or any other traditional CMS because we do not have the in-depth expertise to handle the technical implementation with the traditional CMSes.

Instead, we took a more modern approach where we split the actual content management into a so-called headless CMS solution. Headless CMS delivers only content, such as this blog post's text content and images, via an application programming interface (API). It works like any backend in any modern web application. You cannot modify the looks of the website with a headless CMS unless you specifically implement such behavior to the frontend side. We chose DatoCMS as the headless CMS, since the user interface and content modeling tools were simple and easy to use.

Frontend, or the actual visual implementation of the website, is done in HTML, CSS, and JavaScript as usual. The only requirement is that you can consume the data coming from headless CMS and display it. However, to make the development easier, it's better to leverage some frontend framework to speed up the development. 

We chose Next.js as the frontend framework. It's based on React, and React is something that is very familiar to us. Personally, I have used it in almost every user interface implementation I have done in the past six years. Another React-based option would have been Gatsby, but in my experience, Next.js is a better and much simpler solution for this kind of project.

Next.js has a lot of features, but one of the most important ones is static site generation. The Softlandia site is statically generated every time someone publishes it from the headless CMS side. This means that there is no overhead of server-side rendering and the site is extremely fast. Everything is pre-generated during the website build process. 

The site is also very easy to deploy since it's just a bunch of files you need to copy to some server that is able to serve static content. It's also very secure because there's no need to maintain backend infrastructure. In short, this is how the publishing process works:

1. Editor publishes a new version of the site (for example creates a new blog post) from DatoCMS.

2. DatoCMS notifies Github Actions to start the site build process (the Next.js code is located in Github).

3. Github Actions builds the site with Next.js "export" command. The Next.js code pulls data from DatoCMS GraphQL API.

4. Github Actions pushes the end result to Azure Static Web Apps.

5. Github Actions notifies DatoCMS if the publish was ok or not ok (the build can fail if the frontend code has bugs).

The downsides are that you need a person who is familiar with React to make changes to the website looks. With traditional CMSes, some small changes can be often done from the admin panel by almost anyone. You can also install various extensions that add more functionality to the site without touching the actual code.

Additionally, there's no preview capability. It's possible to implement it, but not with a full static generation approach. Also, the publishing process takes some minutes. The more pages you have, the more time it takes to get all data and pre-render each page as a static HTML file.

However, the downsides are not an issue for us. This is the initial version of the website. The site will evolve as the company evolves. There are many things that did not end up in this initial version. For example, there's multi-language support built in but we did not have the time to translate all the contents into Finnish so the site will be available only in English in the beginning. In the end, the final result is quite good, but there is still some work left to do in the future.