Everything you need to know if you want to transfer your software to a different Web Development Company

People prefer what they are familiar with, or how to choose a Web Development Company?

While an Interactive Agency derives from the marketing needs of its clients and develops its expertise in the direction of technology, a Web Development Company follows the opposite path. It already possesses knowledge of technology but is acquiring marketing competencies.

Interactive Agencies are attracting more interest from Marketing Directors, and clients of Web development companies often employ a CTO (Chief Technology Officer).

The blending of competencies (technical with marketing) is the market norm today. It has its obvious advantages (everything under one roof) but also clear disadvantages (not everything is under control).

Be patient; I will explain what I mean by this. In a moment ;) For now, let's get back to Marketing Directors and CTOs.

A more technologically proficient customer (CTO) will be able to assess the quality of the code of a web application. A client with marketing expertise will focus primarily on the overall impression the app makes. For example, to what extent does it fit in with the company's branding and image? To what extent is it consistent with it?

When selecting a software vendor, it would seem that a company represented by a CTO is in a better position than a company with a marketing-oriented representative, right? Yes and no. It depends.

On what? Or rather, on whom? It depends primarily... On the software vendor. That's right; they are to blame for everything! Even if they are often a classic "winner."

If an Interactive Agency or Web Development Company plays fair, offers high quality, and takes care of its client. Both the "technical" and "non-technical" individuals will be satisfied with the cooperation. If a software developer is messing up from the beginning, the only difference is that the "technical" client will discover sooner that their expectations are not being met.

For example, they may realize that the application is not working correctly. It is not being developed according to plan, etc. I'll talk about the typical problems and typical reasons for switching developers in more detail in a moment. Have patience ;)

Meanwhile, let's get back to the main thread, which is the impression that not everything is going as it should.

If the situation doesn't improve, then regardless of the scope of the client's competence, the decision will be only one! "We are changing the software vendor. This time we will look for a Web Development Company."

Seemingly it's nothing unusual. But in such a situation, it's not so much a matter of saying to ourselves, "Well, tough luck," but rather a matter of not making the same mistake again.

Not everything is under control or the most common reasons for abandoning the services of software developers

Whether you are a CTO or Marketing Director, CEO, Company President, or Company Owner, this situation will annoy you. How often can you ask "the other side" to correct something?

How many times can you ask for an e-mail, a phone call, an explanation, or an indication of a deadline? How often is not receiving an answer, not calling back, or not meeting a deadline an accident that can happen to anyone?

The quality of service is declining, the code quality is decreasing, and an application or a website is not working as it should. The product is not being developed as planned. And yet this is not the end of the problems with this company. This is why changing Interactive Agencies or web development companies is a common phenomenon today. There are reasons for it. The most common issue is that the vendor:

• works too slow
• doesn't meet deadlines
• doesn't keep up with developing their technological competencies
• raises prices without raising quality
• perpetually "doesn't have time" to develop your project, and eventually, you start to think that you are the 7th customer in line. It's like being on a hotline.

How much can you take? The vendor works slowly and misses deadlines because they are either busy with something else or are just learning how to solve a problem. Or, even worse, their best specialist has just changed jobs.

You analyze the code's quality and clutch your head in disbelief. It's not clear at all, it's inefficient, and you don't even want to think about the possibility of expanding it in the future. You may also discover that the vendor thinks you know nothing about the topic.

And since you don't know anything, it probably makes no difference to you if they do the website documentation or hand over the software without testing. They only forgot that you are also learning, and you are well aware that you can't develop software without automated tests because it significantly reduces its quality. Or that the documentation of the complex website is an obvious thing.

When you ask, for example, about the possibility of applying Python technology to your project, the Project Manager dismisses you with vague excuses. As if they themselves didn't quite know whether it would make sense.

One of you doesn't know something, but why should you pay for their lack of knowledge? And you're paying more and more. And you pay, more and more, you wait and wait, you contribute to the project... And nothing. Nothing happens.

You don't receive project documentation, and you should have it. You don't have test results, and you should have them. You don't know what's going on, what stage of the project you're at and when your software will be developed... And so on. There are many things you should have, and you don't have. And you are unlikely to receive them.

Well, let's leave it at that. You know what the issue is. Everything was supposed to be under one roof, only that the roof was leaking, resulting in a short circuit. At first, there was one, followed by a second, and finally, thirty-third. Enough! Something must be done about it! Just what?

It's time for a change! This is not how professional software is developed. You have to make a change as quickly and wisely as possible, according to a specific plan. I will discuss it in a moment. Be patient ;)

Access to the source code and software documentation

Let's start with a definition and an overview of the source code concept, which is simply a record of the operations expressed in programming languages that a computer is supposed to perform. Operations are performed on data acquired or possessed.

It's worth specifying that the source code, i.e., the code that will be understood by the machine, is the output code, so it must undergo compilation. It usually consists of a collection of files.

It is recommended to consolidate them, that is, to collect them within a single file. This is no surprise; large projects consist of hundreds and thousands of files that need to be correctly organized to quickly and easily work with them.

One more clarification. The source code includes not only the program but also scripts, libraries, and documentation. With a rough but incredibly practical definition behind us, we can move on to the following issues.

The problem of access to source code is a problem of its owner, the medium, and the form of access to it (security).

The owner of the source code is usually the company or the developer. However, we often have a situation (especially for large and huge projects) in which the source codes are deposited (Software Escrow) to a depositary.

The depositary (company) is a third party that commits to store and protect access to the code and issue it in the situations detailed in the contract.

Most often, it is about protecting the commissioner of software from losing the source code due to:

• the bankruptcy of the developer (which no company can rule out)
• cessation of development and maintenance work
• malfunction of media (e.g., servers on which it is stored)
• physical destruction of the code (e.g., as a result of random or criminal circumstances – hacker attacks)
• and last but not least, to increase mutual trust. A developer who places source code and software documentation in escrow cannot demand their return at any time.

Access to the source code is, therefore, not only a formal and legal issue. It is also a matter of the market's Best Practices. Thanks to this, both parties can protect their basic interests. So if you didn't protect yourself in this way when you chose your first vendor, you should think about it this time.

It is not absolutely necessary, but it is a practice that increases the sense of security. The depositary, within the capabilities specified in the contract, will serve as a substitute for the institution of arbitration in situations of conflict.

So if you are already using the Software Escrow service (which more and more companies are using), all your company needs to do is request the most current, complete version of the source code along with full documentation.

Access to the source code is also a matter of media. In the case of Software Escrow, it will be a physical medium in the form of a CD or a portable drive. In other cases, data is stored on servers, access to which is secured in the form of:

• login and password (FTP – File Transfer Protocol – this method is still used, but is considered increasingly less professional, risky, and is not recommended)
• login and key (SSH – Secure Shell – is a much more secure method and is now considered the standard).

The transition from FTP to SSH is motivated by the security of data, which is protected much more effectively under the latter option.

In the first case, the login and password are stored on the server. Access to the data occurs after successful verification, comparing the data entered during login with the data on the server. Unfortunately, this method is extremely vulnerable to cyber-attacks.

The SSH protocol is based on generating much more complex, unique access keys with private and public variants. The public key is stored on the server, while the private key is deposited in the hands of the owner of the source code. Files can be accessed only with a private key.

The private and public keys must be compatible, but this does not mean they are identical. That's the difference that determines safety. As a result, your data (think of the consequences of a data leak, not only your personal data but also that of your customers) is much better protected.

With logins, passwords, and keys, you can start working on the application, but to make it smooth and trouble-free, your new Web Development Company will also ask you to provide project documentation. What should it contain? Above all, instructions, descriptions, and specifications, for example:

• instructions for generating the output code, configuration of the environment for such activities
• description of catalog structures of the source code
• specifications of the hardware and system environment.

Source code is a structure that, because of its complexity and size, requires organization. Source Code Repositories are used to control the results of multiple developers (teams usually handle large projects). Without going into technical details, the Repository also allows you to control the flow of the entire software development process and enables you to synchronize work more efficiently and conveniently.

Even more importantly, it is used to document the work. In other words, we have an overview of the history of changes. We have access to information and previous versions so that it is possible to recover them (such as versions without bugs, vulnerabilities, and conflicts).

When changing a Web Development Company, you also need to remember to provide access to the Code Repository. It can be accessed via login and password or login and key.