At AITOM, we refer to this work as “change requests” – these are tasks and assignments that go beyond the scope of the project brief and are therefore not included in the order or contract. We have drawn up a detailed brief for the entire project and we stick to it. Above all, we have set our work schedule according to these specifications so that we can meet the deadline.
How does a coder view a change request?
Modern websites are deeply interconnected. A seemingly minor adjustment, such as moving a logo, can be very demanding from a coding perspective. And if the website is optimised for mobile devices – i.e. responsive – these changes are all the more demanding.
You can think of such a website as a house. Imagine choosing a standard house from a catalogue and starting to build it. Once the foundations are complete, you decide you want just a tiny change – to extend one room by half a metre. That’s a negligible difference for a house, isn’t it? But you need to take into account the potential impact on structural integrity, recalculate the materials, redraw the plans and, of course, rebuild the foundations that are already in place. From the user’s perspective, a minor change to the specifications can then mean a significant difference in both cost and completion time.
What the user ultimately sees is therefore just the tip of the iceberg. It’s not enough just to tweak the code; you also have to test and check everything on every possible device.
The coder’s iceberg
Let’s look at some examples of the individual steps we take at AITOM to handle change requests. Every reputable development agency has an established procedure for ensuring that all changes to the code are implemented in the final presentation without causing errors, downtime, or similar issues. Let’s consider some model examples:
Example 1: Button modification
| Step | Time required |
| The coder studies the brief and finds the optimal solution | 10 minutes |
| Creating a feature branch (essentially a copy of the code) | 5 minutes |
| Launch the copy of the site on a local server on their computer | 10 minutes |
| Making the necessary changes | 5 minutes |
| Testing the changes on all necessary devices | 30 minutes |
| Uploading the change back to the production server | 10 minutes |
| TOTAL | 70 minutes |
Example 2: Adding further items and a slider effect
| Step | Time required |
| The coder studies the brief and finds the optimal solution | 10 minutes |
| Creating a feature branch (essentially a copy of the code) | 5 minutes |
| Launch the copy of the site on a local server on their computer | 10 minutes |
| Making the necessary changes | 120 minutes |
| Testing the changes on all necessary devices | 30 minutes |
| Uploading the change back to the production server | 10 minutes |
| TOTAL | 185 minutes |
As you can see, even a seemingly minor change takes a significant amount of time due to the technological process, which is practically unavoidable. At AITOM, we handle transfers between local servers and production servers automatically. The developer clicks three times and the automatic deployment takes care of the rest. This not only eliminates errors but also dramatically reduces the time required for all changes.
Draw twice, code once
Generally speaking, it is better to avoid change requests during development. If you prepare your materials well in advance, you won’t have to deal with change requests. At AITOM, we prepare the complete design of the website as part of the brief – in the initial study. Thanks to this, we know exactly where and what buttons will be, whether and what kind of carousels we want, and we prepare a responsive version, etc.
So consider in advance what you actually need on the website. Think about the website’s future development. Do you want to expand your portfolio on the website? Tell the developers straight away. They will prepare the code in advance to allow for this expansion. It is far better not to fully utilise the website’s potential in the first phase than to add components to the site in the future that the website was not built for from the start.
What if change requests do arise?
Sometimes change requests cannot be avoided. For example, if significant changes occur within your company during the implementation of a web project – such as changes to your service portfolio – we, as your agency, must respond to this. Essentially, there are two main ways to deal with these inevitable change requests.
a) Change requests that need to be incorporated into the website during its development
If the changes are necessary and merely affect, for example, the text content of the website, it is usually no problem to incorporate these changes into the development immediately, and thanks to a pre-agreed buffer, meeting the deadline is rarely an issue. However, if the changes are more complex, requiring alterations to the design, structure or core functions of the website, you must expect that the completion of the website may be delayed and, potentially, become more expensive.
b) Change requests that can be incorporated into the website after its launch
Unless the changes are dramatic, we usually suggest, in consultation with the developers, that they be included in the second phase of implementation, i.e. after the website has been completed. These requests accumulate gradually during the website’s development, and once the website is live, their priorities are assessed and addressed through amendments to the contract or order.
Seek advice
The most important thing is to keep a cool head and, together with the developers, consider which changes need to be reflected on the completed website immediately so that they can be implemented before it goes live, and which can be deferred to the list of future website developments. Discuss the changes, their significance for your business strategy, and the complexity of their implementation, and have a solution proposed that will be the most acceptable for your business. We always do our utmost to find the right compromise together with the client.