As much as we work with clients and communicate with colleagues, we notice one interesting thing: even among experienced customers, even within IT teams, the concepts of “website technical support” and “development” are sometimes confused. Where one ends and the other begins is not always clear.
One of the most common stereotypes: support is when a project is “finished.” In fact, support begins where everything is already “finished”, but the project needs to be kept alive. That is, after the release. For us, support is, first of all, stability. This is so that the site lives and does not crash. To ensure that domains are paid for on time, SSL certificates are fresh, and servers do not die at 3 am. So that backup copies are not “somewhere”, but in an understandable structure and collected regularly.
We show how we divided subscription packages for clients to cover the most diverse range of tasks
We spare no resources to do the “invisible” part of the work, that is, support, reliably and stably. Especially when it comes to technical website support for organizations, where failure can cost image, money and user trust.
If support is so that it doesn’t break, then development is so that it gets better. This is a simple formula we often use when explaining the difference to a client.
Add a new button, implement online payment, rebuild the interface, come up with convenient filters - it’s all about development. And this is always a step forward. It is important for us that clients understand: development is not about “finishing it according to your mood.” This is value work. Above convenience. Over what will happen tomorrow.
Formally, everything is simple: there is an act of acceptance and transfer - the project is completed. From this moment on, everything that happens goes either to guarantee, or to support, or to development. But in reality everything is more complicated. After the release, a “run-in period” begins: users begin to use it, the client begins to look not just at the technical specifications, but to actually poke and try to work with the portal or system. And almost always new input and wishes appear. For example, create a separate service for transferring data to another system, which was not the case in the first project. Somewhere we understand: this is an omission - and we take it upon ourselves as a guarantee. And somewhere new functionality appears. New logic. New need. And here it is - development.
One of the most striking examples is our long-time partner, the Yugra Entrepreneurship Support Fund “My Business”. We have been working with them for several years now; we have created several versions of the site. Another redesign - everything is according to plan, everything is agreed upon, the project is closed. And after some time, the client returns to us for the development of the portal with new introductory information. And we did not go at random - but with facts. We conducted full usability testing (by the way, there is also an article about this). We looked at where users get lost, what raises questions, what gets in the way. At the end we received a specific list of improvements. Not “an outside view,” not “it seems to us,” but live analytics. We formalized the improvements, implemented them - and now this is no longer support. It was just development. Working on the quality of interaction, not just fixing a button. We have many such cases. For example, with the Vera charity foundation, all work is structured as development. We regularly collect backlogs together, discuss new tasks, and package them into applications. And technical support for the site is provided locally - on days of big promotions, when efficiency and stability are needed. For example, after a complete redesign of the “About Palliative” portal, we are moving forward in its further development using backlogs. Because their project lives, changes, breathes. And we grow with him.
For example, the main essence of the new website “About Palliative” is cards. They included all the information: who the material is about, what format it is in, and how much the reader will spend on reading.
Support is a marathon. It runs in the background and requires attention, but not much project planning. Often these are small tasks: change a picture, update a PDF, add a link. Some people have 15 such tasks a day. Development is already a sprint. It requires collecting tasks into a backlog, estimating, planning resources, and assigning a team. There is a budget, terms, deadlines. We even explain to clients this way: if the task takes 15 minutes, okay, we’ll do it as part of support. But if this is “another section”, “new filtering logic”, “layout for another department” - this is already development.
Any organization develops. It has new tasks, structures, and divisions. And the site is a reflection of this life. If flexibility and scalability are not built into it, it very quickly becomes irrelevant. We've seen this happen with our clients. Many of them needed reassembly at some point. Because the structure is outdated, nesting has become unreadable, and the logic is confused. And yes, you can add a section in 30 minutes. But it’s better to rearrange the navigation so that the new section fits logically and the user doesn’t get lost. This is development.
Previously, the client most often initiated. He saw the problem and came with a request. Now we are trying to give advice ourselves: a new law has been issued - here are the changes; the requirements have changed - here is the updated block; users complain - let's test it. We learn to be proactive. And we see that it works. When you care about a client's project, he feels it.
For a client, ideal technical support for a website is when everything works stably, and tasks are solved quickly and efficiently, without failures or loss of attention to detail. Ideal development is when there is a feeling of movement: a clear result, team involvement, mutual understanding, as if everyone is working on the same thing. We know how to work this way. Build a process like a clockwork - with forecasting, priorities, clear roles and deadlines. For us, this is the ideal: when we understand where we are going, we can plan the team’s workload, focus on quality, and not on putting out fires. But we understand that not all processes are smooth. Somewhere there is no way to wait for approvals, somewhere you have to pick up the task “it was necessary yesterday”, somewhere everything is just being built. We know how to work in these conditions - without losing focus and common sense. The ideal is always about partnership. Where both parties understand that a digital project is not just a one-time launch, but a living system that requires care.