After the first call the work moves forward through regular deliveries, which you try out in a test environment before the release to production. The path changes depending on whether you start from a monolithic Drupal portal with limitations to overcome, from a Drupal portal, monolithic or decoupled, that needs maintenance and ongoing development, or from a new project.
A monolithic Drupal portal that is live, with weak points that an incremental migration could overcome. We start with a call and an assessment, the full analysis of the portal before we step in. Then we proceed in stages and you decide whether to continue.
A live Drupal portal, monolithic or already decoupled, that needs maintenance and ongoing development. We start with your account of the portal and some key information; the assessment, if needed, can be part of the maintenance contract.
A new digital service, with or without Drupal, several applications that need to work together, or an idea that still needs refining. We start with a call and a first idea of the scope, then move on to the proposal and the execution roadmap, which starts from the first version.
45 minutes, free of charge, with the people who design the solution. You tell us about the portal and give us the first details on versions, environments and ways of working. You get a first idea of how ready the portal is and what needs checking, plus an order of magnitude for the investment.
Two weeks of paid analysis, without touching the code. You get a list of blockers, a pilot proposal with an estimate and a green, amber or red traffic light. The document stays yours even if you don't continue with us.
A first objective in production, chosen with you based on the budget. You get a real result, so you can decide with data.
From there we go one objective at a time, at the pace of your work. Every milestone ends with a delivery. As we reuse what has already been built, the cost of the later sections goes down.
We apply incremental migration, or the Strangler Fig Pattern, to monolithic Drupal portals. A new frontend works alongside Drupal and takes over the portal one family of pages at a time.
It isn't the right choice for every portal, and the assessment is also how we find out whether it is. The full method is in the white paper, which is in Italian only and designed for reading and printing. The Insight article is its web version. For version upgrades, taking on existing portals and maintenance, there is the Drupal development page.
We always start with at least your account of the portal and some information on versions, environments and ways of working.
When the ongoing development has no defined milestone objectives, the assessment can be part of the maintenance contract.
Requests reach us in the progress reviews, the meetings on the state of the work, by email or through a request management tool. How often the progress reviews take place is agreed case by case, according to the maintenance contract and the project.
On ongoing development of a live portal we work in cycles of about three weeks. The first two are for development and testing and the third includes the release to production, often without interrupting the service. The roadmap stays in place. Milestones only come in when objectives are broader and well defined.
With every release you receive release notes, with links to the artefacts generated. Depending on the maintenance contract you also receive activity reports and the deliverables of the work, from code to documentation.
We gather context, goals and ideas, even when the requirements are still rough or missing. That's fine, because that is where we start.
We define business and user goals in several scope plans. Each one is a work item with its own scope, meaning what is in and what is out. Together they are a projection far less binding than an execution roadmap, because we are still at an embryonic stage with no technical analysis.
If needed we meet again, then we send you a proposal. We plan for a first version and later developments. We start with what is needed right away and the rest grows afterwards.
We refine the scope of the first version, set up the technical side and the infrastructure, and research the needs of you and your users.
The execution roadmap comes out of what we learn at kick-off. It includes the first version and is more precise than the scope plans. It stays more uncertain the further ahead it looks, and we tell you straight away where there are uncertainties and simplifications. From there we proceed by milestones, usually monthly.
Every feature and every technical task is first described as expected behaviour, which then becomes a test. Every change goes through a Continuous Integration and Delivery pipeline.
We always deliver to a test environment and let you know that the work is complete. With the delivery you receive what has been developed, the technical and user documentation and, where applicable, the graphic materials.
We usually present what we have produced. Where needed there are also interim demos. You can try out the work in the test environment as it arrives.
The delivery arrives in test. The release to production goes ahead when you give us the OK, even from the first milestone. With every release you receive release notes, with links to the artefacts generated.
With every delivery you receive a snapshot of the roadmap, with the next milestones. It may change, because the roadmap is a living one and is updated in light of what happens in the project.
In a progress review we look together at your priorities and at how the roadmap is advancing, at a frequency that depends on the project and the client.
There is always a roadmap. The Delivery Manager plans and updates it, you see it at every progress review and you can ask us for it at any time.
It depends on the project. In new projects deliveries follow the milestones, usually monthly. On ongoing development of a live portal a release goes out in cycles of about three weeks. In other cases the cycles can be as short as two weeks.
A request that changes goes to the Client Manager, who brings it to the team: together with you we decide how to handle it in relation to the roadmap, milestones and priorities.
Along with all the project deliverables, you will also receive a report on the work carried out.
Responsible for your priorities. Collects your requests and takes them to the team.
Responsible for the technical choices.
Responsible for the roadmap and deliveries. Plans and updates the roadmap.
We avoid waste and constantly review our workflows. We start from what is really needed, looking first for the needs of you and your users. We expand later, so the budget goes where it is needed.
For years we worked with Scrum. Since spring 2026 we have worked with a roadmap and, where objectives are broader and well defined, by milestones. Deliveries to a test environment let you try the work before the release.
We describe infrastructure as code and automate builds and releases in all our projects. Development and operations work together, with development and test environments as close as possible to production.
Before writing code we try to understand what your users need, through research and clickable prototypes. The Design System that comes out of it lives in the frontend and keeps your applications consistent as they grow over the years.
We design cloud native platforms sized for production, with infrastructure, pipelines and environments built together with the portal.
The whole team built the method over years of retrospectives. It keeps growing from within. With clients we look for a relationship of collaboration and trust, with no opposition between those who ask and those who build. Alongside this idea we would like to add a way of building software that is more efficient in its performance, which we discuss on a separate page.
Drupal, Monolitich, Operations, Continuous Integration
In 2022 we started with an assessment, the analysis we use to check whether a portal can keep growing on its current foundations. It gave a red light, so we rebuilt the portal, keeping the previously approved design. It has been live since 2024.
Drupal, Next.js, Decoupled, Continuous Integration
In 2022 digital was becoming central to Flexform's work, and the portal needed new tools. The choice: content on Drupal, with the frontend rebuilt in Next.js. Since 2023 the portal has grown every year, with new features for users and retailers.
Strapi, Next.js, Decoupled, Continuous Integration, UX & UI
We're Drupal specialists, and for Vivo Concerti we advised against it: their editorial team needed a lighter CMS that suited its work. Strapi manages the content, while Next.js, running separately, renders the pages and handles the high traffic.
Every delivery arrives in a test environment and goes to production only with your OK. Every change goes through an automated pipeline, the roadmap is kept up to date and we meet at the progress reviews. That way problems surface early, when they cost less.
How often we hold progress reviews, the cadence of milestones and releases, and the type of report change from project to project, depending on the contract and the people working with us.
Surprises remain. The method lets us catch them early, because every milestone goes through a test environment before release, and decide how to handle them against the roadmap.
We evaluate a portal on a platform other than Drupal case by case. If it falls within the technologies and skills we have, we can work on it, otherwise we tell you straight away.
It depends on the project. In an incremental migration of a Drupal portal the first family of pages is usually live within two to three months. On ongoing development of a live portal the cycles last about three weeks. In new projects the milestones are usually monthly and you try every delivery in a test environment; the release to production goes ahead when you give us the OK, even from the first milestone.
Yes. In general we work through incremental deliveries and releases, whatever the architecture. With a monolithic Drupal portal with limitations to overcome you start with a call and an assessment, then a pilot: a first objective in production, chosen with you based on your budget. With a live Drupal portal, decoupled or not, that needs to keep evolving, you start with the development cycles. In a new project we plan for a first version and later developments.
The code we develop and release for a client belongs to that client. What we build as open source, for example Drupal modules for the community, stays open source, even when it comes out of a client project.
The assessment document stays yours. For a portal to be migrated it contains the list of blockers, the pilot proposal with an estimate and the traffic light. Whether to continue with us is your decision.
For a monolithic Drupal portal with limitations to overcome the call is free and gives you an order of magnitude for the investment; the assessment is paid, the pilot is estimated together with the assessment and the milestones are evaluated one at a time. In every case the figures depend on the portal and the goals, so we give them once we have understood your case.
Let's talk about your project with the people who will design it