Practical tips on changing the service provider and still delivering your digital product

The most common reasons for ‘divorce’

As in any other business, different service providers offer different levels of service. The contractor’s development stack may look promising as you’re signing the commission contract, but it can turn out to be insufficient to realize your ideas in practice. In such situations, the limited know-how of the contractor’s company is the main reason you’re considering the change of the service provider.

This is not the only reason for deciding to switch one company for another, though. Other factors might include:

• Cultural differences
• Political and economic situation
• Time zones
• Values and modes of work
• Languages

In the “Global Outsourcing Survey 2016” report, Deloitte identified the following factors in a change of contractor, based on the responses made by companies themselves:

• 46% Providers are reactive rather than proactive
• 33% Don’t provide enough innovation
• 29% Have high staff attrition rates
• 25% Lack of leading practices
• 23% Unqualified resources
• 22% Lack of internal integration
• 20% Poor service quality
• 20% Lack of cross provider integration

All of the above issues can prompt you to change your service provider. It may be just one or a combination of many but when they occur to a sufficient degree, the divorce is inevitable. What can you do to go through it as smoothly as possible, and what is important when choosing a new contractor?

Good practices for entering a new relationship

The choice of a new partner should be a well-considered decision, if only to avoid the problems that ended the last relationship, but also to minimize the risk of new ones. This is not a simple or quick process. Some make use of opinions shared on various websites, such as Clutch.co, others look at portfolios of similar projects, follow friends’ or network recommendations, or carry out research online.

You might be also interested in the article:

Digital Product

Product-Market Fit for expanding market demand

The quality of the first contact can say a lot about a company. If you have to wait for a reply for a couple of days or their first question is about budget, you can walk away. If the communication (via email or phone) is quick, the company is honestly interested in the problem and able to offer adequate persons to solve it, you can move on to the next level of talks.

These should involve the presentation of the business and technical problems and the development of a further plan of cooperation. Sometimes an audit is required as a separate task, so if the company undertakes to work on the app or web, you can concentrate on drafting a support agreement.

The new partnership begins

Unlike starting a new project from scratch, where it is necessary to build the architecture, select technologies, etc. in a project which has already been started by another company, the focus is on what’s already there.

The code, technology, and architecture are probably already chosen or in place but the previous contractor might have worked on them using a different process, in a different spirit, or with different values. That’s why the best solution to begin with is to audit the product in order to find out whether the business and functional requirements have been implemented, what the code quality is, and which features of the digital product are weak (e.g. security gaps).

The digital product’s audit

Here are the most important points to pay attention to during the audit:

1. A detailed analysis of the system: what it serves, what problems it solves, if and to what extent it is used.
2. The identification of the most serious problems with the system – based, among other things, on the backlog. These can include, for instance, slow operation, malfunctioning options, or instability. This process will result in a better understanding of the system.
3. A system test using a local installation. The process of installation itself can say much about the state of the product. Without ready automatic scripts, the app is probably rarely updated.
4. Checking if the app collects logs and if it has a data backup and cleanup mechanism. Without the logs, in case of a breakdown, all you’re left with is pure guesswork, and I don’t think I need to tell you how products without backups end up.
5. An analysis of the code. At this stage, it’s a good idea to answer a series of crucial questions:

• Are there any tests? If so, that’s great, because this gives you a chance to check if anything is tested at all. Analyzing tests has another benefit: you get to know the system and the principles governing it better. If there aren’t any tests, you’re going to face a big challenge, as you cannot be sure you’re not going to spoil some element while editing or fixing the product.
• Are the coding conventions consistent?
• Are design patterns used?
• Are the frameworks and libraries reliable? Here, it’s worth taking a look at their versions. It often happens that security bugs turn up because the installed versions haven’t been updated.
• Is the product secured against attacks? Security bugs can be detected during the code analysis; for example, you can verify whether the entry fields data are correctly processed to prevent SQL injection. There are many more possible attacks and each should be well analyzed.

To analyze the source code you can also use static code analyzers which can give additional support to the audit with data from an external tool.

After the audit

A well-run audit will help you take the next step. Its results will determine the following scenarios. For example, if the audit’s results are not good, you should think about several issues:

Should everything be rewritten? If the app is small and it’s possible to rewrite it quickly, this makes sense.

But what if the app is large? It’s hard to accept that nothing might be released to production for a whole year due to rewriting the product’s code. What’s more, during rewriting, some significant assumptions from the beginning of the project may be missed, and that can harm the business logic of the digital product.

In this situation, it’s a good idea to place a “cap” over the product and to create new functionalities directly inside it and transfer the old code along the way, taking small steps towards better practices.

The audit can result in many similar scenarios to take into consideration. The ideal way to address each one is in cooperation with your new partner.

Backlog

The next step is to get acquainted with the backlog, both in terms of the tasks already performed and those that are still in the planning stage. You should discuss your short-term and long-term plans with your new or potential partner. Don’t forget to add new tasks to the backlog, those resulting from the audit and subsequent prioritizing.

Infrastructure

The infrastructure used by your ex-contractor is a key element. Normally, the list of tasks as well as the whole work history are in their system, e.g. Jira or Redmine, and the code is in the provider’s version control system, e.g. GitHub. Frequently, the product can be found on your previous contractor’s servers (usually in the cloud but sometimes also on physical servers).

You should transfer all the required data to your own or your new provider’s infrastructure. Remember to check that the previous contractor no longer has access to databases, apps, and other data.

Before the app or web starts on the new infrastructure, it must undergo tests to make sure everything works just like it did in the latest version, and if all the integrations - e.g. with an external payment system - function correctly. When the product’s functionality has been verified, it can be offered to users.

Development and maintenance

If you already have a working product on a new infrastructure, a task checklist (backlog), and testing and development environments, you can start off (or re-start with your new contractor, that is) development and maintenance works for the product. Usually some members of the team work on the quick improvement of any essential errors (especially security bugs and those concerning other sensitive components), while the rest works on the development of the product, i.e. adding or changing functionalities.

A working relationship

Even though the whole process may look money- and time-consuming, sometimes there’s no other way and you just have to change the service provider instead of staying stuck in an unhealthy relationship. The cost of failing to realize your business goals, not to mention the stress of collaborating with an unsuitable team, can be much higher than that of changing provider and finding a new team.

That’s why it’s so important to create a product roadmap, on your own or along with the potential new partner, to make a precise estimate of the costs of changing contractor. That way you can make sure the profits will balance the possible initial costs in the long term. If the numbers are right, it’s better to finish the unhappy relationship and start a new one, giving you new opportunities and perspectives for the future… and a better chance of project success.

Read more about our approach and the way we work with our partners.