We rebuilt our own company website as a headless CMS website with a project cost calculator. The project included greenfield development of the architecture and design, implementation of the website, a headless CMS for content management, as well as hosting and deployment in Azure. The result was a modern foundation for web content and editorial content management, separated from the visible website.
Starting point
This project was an in-house initiative by ballmüller solutions. The task was to implement a company website with a project cost calculator and create a new technical and design foundation for it.
The project brief resulted in a greenfield situation: the architecture and design were developed from scratch. The website was also to be built with a headless CMS so that content could be managed separately from the actual presentation.
Solution
We designed and implemented the website as a completely new system from the ground up. This included the architecture and design, the technical implementation of the website, the integration of the headless CMS Strapi, and the project cost calculator as part of the application.
For operations, we set up hosting with Docker and Azure. Software delivery was organised through CI/CD using Azure DevOps. CI/CD means that changes are built, tested and deployed automatically. The project ran from August 2022 to June 2023 with a team of 1.
Result
The delivered solution was a company website with a headless CMS and project cost calculator. The project was completed.
The duration was 11 months. The project period ran from August 2022 to June 2023.
Technology
The following technologies were used:
- ASP.NET Core for the web application
- Blazor WebAssembly for the part of the application running in the browser
- Strapi as the headless CMS for content management
- MySQL as the database
- Docker for container-based operations
- Azure Static Web Apps for delivering web content
- Azure Container Apps for running container applications
- Azure DevOps for CI/CD, i.e. automated build and deployment processes
- TailwindCSS for styling the user interface
Why a headless CMS website is a good fit for projects like this
A headless CMS website is particularly suitable when content needs to be maintained independently of the visible website. A headless CMS centrally manages text, images and other content and provides it via defined interfaces; the presentation in the browser is developed separately. This is often useful when companies want to structure their content flexibly and continue developing the website independently on the technical side.
For projects of this kind, separating content, application and operations is often a pragmatic approach. This means editorial teams and development do not work on the same part of the system. Content can be maintained in the CMS while the actual website is created as a standalone application. This is especially helpful when design, interaction or additional features go beyond a conventional standard website.
This approach also offers advantages in terms of extensibility. If additional components are added later, such as forms, calculators, portals or integrations with other systems, the structure usually remains clearer than if everything is bundled together in one monolithic system. In this context, monolithic means that many tasks are combined in a single application and often also in a single technical product.
From an operational point of view, it is also important that a headless CMS website can consist of different parts with different requirements. The public-facing web part typically needs to be fast, stable and easy to deliver. The CMS, by contrast, requires protected access, roles and a clearly defined editorial process. That is why operations are often considered separately in such projects as well, for example for the website, CMS and supplementary services. More on this usually falls under web development and hosting and operations.
Decision-makers should therefore look above all at how clearly content, functions and processes need to be separated from one another. Not every website needs a headless CMS. But if bespoke requirements, a dedicated application layer or additional features are the main focus, this approach is often a good fit. A clean information architecture is important. By this we mean that content, page types, relationships and maintenance processes are clearly described before implementation begins.
How projects like this are typically implemented
For a bespoke website or portal solution, a project like this usually begins with a proper clarification of the goal. Decision-makers, specialist departments and the delivery team should first define which content is to be provided, which functions are required and which processes are intended for editorial work, approval and operations. Especially for a headless CMS website, this early alignment is important because content maintenance and the frontend are planned separately.
This is usually followed by the functional and technical concept. Here, page types, content models, roles, interfaces, search functions and non-functional requirements are described. Non-functional means requirements that do not directly represent a business function, such as maintainability, security, availability or traceability of changes. In parallel, a design concept is usually developed for structure, navigation and interface behaviour.
Implementation then involves developing the individual components and connecting them together. Typical elements are a frontend for the visible website, a CMS for content, data storage and the planned operational setup. If additional features such as forms, calculators or integrations are included, they should be thought through not only in design terms but also in terms of their data processing and maintenance. Depending on the target setup, bespoke services are often relevant for the technical implementation, such as web application development, data storage and operations.
Deployment is another important part. In professional projects, changes are not usually copied manually to servers but delivered through automated processes. These processes help create repeatable releases and reduce sources of error. A clearly traceable separation between the development stage and the live environment is also part of this.
Before go-live, it should be checked whether content, permissions, navigation, forms, loading behaviour and editorial processes work together properly. After that, the operational phase begins: content is maintained, technical dependencies are monitored and extensions are planned. Anyone preparing a similar project can use an initial assessment via the project check or a no-obligation initial consultation. For us at ballmüller solutions, what matters is that the concept, implementation and later operations are considered together from the outset.
Typical pitfalls in website, CMS, data and operations
In projects like this, problems often arise not in the visible interface but at the boundaries between content, technology and organisation. One common pitfall is an unclear scope for the CMS. If it is not properly defined in advance which content should be maintained in a structured way and what may remain editorially flexible, content maintenance later becomes unnecessarily complicated. A CMS should support editorial work, not make it harder through models that are either too rigid or too open.
Interfaces are equally critical. An interface is a defined connection through which systems exchange data. Even if a website initially seems manageable, small additional features can already create internal dependencies, for example with forms, datasets or external services. These dependencies should be described early from both a business and technical perspective so that responsibilities, error scenarios and operational processes are clear.
In operations, it is often underestimated that a headless CMS website consists of several parts that need to be protected and monitored differently. The public-facing web part has different requirements from the editorial system. Access, roles and approvals must be regulated in a clear and traceable way. It should also be defined how changes are rolled out, how incidents are handled and who is allowed to adjust content or technical settings.
Data also deserves attention. Even simple websites can involve personal data, for example through contact forms or editorial user accounts. Personal data means information relating to an identified or identifiable person. The legal requirements that follow from this should not be assumed on the technical side but checked with the relevant internal departments and, where necessary, with legal advisers or data protection officers.
Finally, it is worth looking at long-term maintainability. Bespoke systems should be built in such a way that content remains extensible, technical components can be replaced and deployment processes do not depend on individual knowledge. This includes clear responsibilities, documented procedures and an operational concept that remains viable after go-live. If a project also requires data storage or integrations, this often also affects database development. This is precisely where it becomes clear whether the solution not only works today but can also be developed cleanly over time.
Frequently asked questions
What do the costs of a headless CMS website depend on?
The costs depend mainly on the functional scope, the desired level of design, bespoke features and the planned operational setup. The content model, interfaces, editorial roles and the question of whether additional components such as calculators or forms are needed alongside the website are also relevant. For an initial estimate, the cost calculator is suitable. If a description or requirements specification already exists, a project profile is usually the better starting point.
How is a project like this typically approached?
The usual approach runs from clarifying requirements through concept and design to implementation, quality assurance and commissioning. For a headless CMS website, content, editorial processes and technical architecture should be considered together at an early stage. This makes it easier to decide which parts should be developed individually and how operations and maintenance should be organised. What matters is that business goals, content structure and technical implementation are not planned separately in isolation.
Which risks should clients raise at an early stage?
Typical risks lie in unclear content models, blurred responsibilities and underestimated dependencies between website, CMS and operations. If roles, approvals or interfaces are only clarified late on, this often leads to rework. Security requirements, access rights and the handling of data should also be addressed early. Legal issues, for example around data protection or requirements for public bodies, should be reviewed with the responsible specialist teams and, where necessary, legally assessed.
How long does it take to implement a bespoke website with a headless CMS?
That depends on the functional scope, approval processes, design expectations and any preparatory work already in place. Integrations, editorial processes and operational requirements also influence the project duration. With bespoke solutions, it is usually not pure programming that is decisive, but the careful coordination of content, architecture and deployment. For an initial realistic assessment, a short project description or a structured initial consultation can help.
What needs particular attention for later operations?
For operations, the website, CMS, deployment and responsibilities should be viewed as one connected system. Regulated access, traceable publishing processes, monitoring of technical components and a clear approach to changes are all important. If several services are involved, it must be clear how errors are detected and resolved. It should also be clarified in advance who maintains content, who is responsible for technical changes and how further development will be planned.
