After all the functionality and features described in the PRD are developed and deployed on the Dev server, the final demonstration to the client takes place. The whole project is ready and you can click it through again and approve. Now, the project is deployed on the Product server and launched. Though, often the work of the development agency is not over because your website, web application or browser extension will also need maintenance. And often, you already have features planned for the next versions.
Installing and setting up Google Tag Manager and all analytics services
Google Tag Manager (GTM) is a management system that allows you to install and update tags of various analytics, marketing, and support services from one place, without editing your site code. It can be Google Ads, Google Analytics, and other, non-Google, tags.
With GTM you can add and use analytics tracking code by yourself, without any help from a development team. Note that some services can harm your website performance, so, to be on the safe side, it’s better to consult the developers before adding them.
So, we add GTM and set up Google Analytics’ goals and events (page views, newsletter sign-ups, etc.) for monitoring sales funnels, conversion rates, bounce rates, etc.
Production server deployment
A Production (Prod) server is a core server accessed by users. When a web app or a website is developed and tested in full, it’s deployed to the prod server. Deploying the project on the Prod server doesn't happen at once. The first run after the client approves the final version happens on the Development server again. The team completely removes the project and deploys it again. It can also happen on a Stage server if a company is ready to invest in one. Sometimes it can be done on the Production server at once - when it's a completely new project, and there is no current version of the website that will be deployed. Otherwise, we can't afford to tweak the project on the working website while the users wait.
All the accesses are changed to production, the website is opened for indexation, all the services (previously run in an isolated environment) are connected for real, the background processes are checked, the database is filled. Then, a full regress test is conducted.
Although each website is unique, there are certain common requirements which should be in place before opening a website to the public. Even the most basic website needs basic security guidelines to be followed, needs to have a procedure to deploy source code updates, basic DDoS protection implemented, backup procedure configured, etc.
At this moment, you already have a PRD. The unnecessary sections are removed so that the last version of the PRD contains only the information relevant for the website maintenance. After the project is launched, the PRD serves as its complete technical documentation.
When you decide to develop new features and functionality for your project, it's important to update the technical documentation. Up-to-date documentation makes the maintenance easier and faster, even if the project is handed over to another team. It's often reasonable to hand over the maintenance of your project to your in-house team, or maybe, a freelancer. But to do so, you need proper technical documentation. Otherwise, maintaining the website might be next to impossible. It'll be expensive and take longer for sure. Don't postpone or skip the documentation update to avoid investing much more time to bring it back to life later.
Current maintenance tasks
For the maintenance of a web project after it's launch, it’s reasonable to use Kanban methodology. It’s very useful for managing the development team moving from a task to a task.
Adding new features or functionality
Suppose, you want to add to your website a new feature, for example, a new filter for an e-commerce website or a registration via Facebook (Gmail, etc.), or another payment system. How does it happen?
First, you need to update the technical documentation, adding all the details about the new task. The wireframes or mockups that show the logic of a new feature (all the cases of user interaction with the UI using the new feature) are created.
The task is estimated. Usually, it's decomposed to smaller blocks and subtasks for better planning. After the approval, it's taken into development. The development process is the same, as described above for each task.
To ensure the seamless website functioning, you should consult your web development team and schedule regular regressive testing, at least once in a month, or biweekly. Regressive testing serves to find bugs that can appear when new modules are added, or that might be not discovered during previous tests.
Regular refactoring should be conducted at least once in six months. Refactoring means restructuring the code without changing its external behavior. It's the code review of the entire project, similar to the clean-up in a garage or a wardrobe. It’s easier to find things after such a clean-up when everything is in its right place. Similarly, the website works better after the refactoring.
If you don't need any new features, you don't need any website maintenance. But usually, living projects are regularly updated.
Suppose, you want to add an incentivization module to the CRM. It can take up to 2-3 months. And this development will take place while the current version of the website or a web application is working and being on the maintenance.
This happens similarly to the development of the first version, starting from the discovery and moving to the final testing and deployment of the functionality (sections 2 - 5).
Note: You shouldn't collect all the small changes and make a V2 of a product updated with all these small features. First, it might be more expensive than moving a feature after feature. Second, the end-users are accustomed to constant small changes and updates, they're used to seeing that a website gets more convenient. The long absence of such updates may seem a worrying sign that the project is abandoned.