News

How to choose a reliable partner for software development?

Now, it is much easier to choose a contractor than ten years ago. The development of the vast majority of products is no longer Rocket Science and many tasks have known solutions. In this article we will tell you about the points worth paying attention to.

What should not be done?


Let's start with a list of things that you definitely shouldn't do. It is short, simple, and will keep you from making the wrong choice.
  • Look at the public ratings. Finding a company in the rankings does not mean that you will get exactly the person who secured the ranking. The data for these are taken from public sources - profits, annual turnover, number of employees, etc. In addition, participants in most rankings pay for participation. The algorithm is simple - the more paid, the higher place in the rating.There are resources where people put their work. For example, behance.net. It is more about design, you can look at the outside of the project. But if you want, you can successfully go to the websites of companies and get acquainted with other aspects of the team's work.
  • Choose a contractor only by price. If you are faced with three proposals from similar-sized companies with a tangible spread of prices, you need to find out why there is such a spread at all. There is no need to immediately rush to the cheapest. This information will help you to draw attention over the depth of the team's requirements and may indicate inconsistencies in your requirements.
  • Follow the concept - "the one who pays is right. The right one is the one who can achieve your business goals. Yes, the client pays money. But he also looks to the contractor for help, his experience and professionalism. The client has a need, and the contractor does everything to meet it. And he gets paid for it. And then there is a conversation about mutual trust. Already at the initial stage, the two parties agree that they will develop a partnership, and on this foundation they build their relationship further.
  • Blindly trust the recommendations of acquaintances. If you are advised by someone, do not rely solely on the recommendation. Always make your own decision and check. You have to work with the chosen team, not the one who recommends it.


What is useful to do?


  • Seek and request case descriptions from the companies involved. This is a working strategy, However, there are a couple of things to be aware of. 
First, having a case on the site does not mean that the same people who did the project from the case on the site will do the project for you. It's important to score the team from scratch and draw conclusions based on personal communication. If you communicate with a company that you have chosen based on the cases on the site, be sure to ask who exactly will do the project and how the knowledge of the previous experience will reach the new team (if the case was made by other professionals).
Tip. If you have no one with competence in development at all, then your key query in a search engine may look like this: "a mobile application of the company "..." People care about their cases to be searched. As a rule, companies come to search for contextual advertising and publications about themselves when they already have accumulated experience and have something to show. 
  • Ask about personal experience of acquaintances or partners. Earlier businesses in the same field did not overlap much, but now the business community is quite friendly. Conventionally, if I do packaging and you do packaging, it's likely that we are in contact on some platforms, forums, chat rooms, etc. And it's perfectly fine to ask for references in those communities. But remember, you can't base it solely on them. The choice is up to you. Use the recommendation as a source of contacts and an opportunity to know in advance the potential difficulties in the work.
  • Look at the experience of companies that you like and contact them. Contact those who have already bought such a solution. If it's not know-how, businesses0 are comfortable sharing development contacts.

Doing one item will already be the source of 5-7 contacts. Doing all three will arm you with an excellent set of information to make an informed decision. But before you filter your list of applicants, you need to prepare for a substantive conversation.


What to talk to the contractor with?


Usually developers expect a document with detailed and clear requirements. Most often it is called the Terms of Reference, but everyone understands it differently.
We advise to prepare two documents:

  • A description of the desired result in business format. This is a description of what will need to happen with the product and in what process it will exist. Describe who will use it, what exactly it will do and why, what external services the product should interact with, what sequence of operations is needed internally. Don't try to touch the technical implementation or the choice of framework in the document. Competent engineers will suggest everything themselves. It is important for them to understand the business goals and your business.
  • Non-functional requirements. These are requirements that are not related to what the solution does. They describe the environment, the load on the product, the available technical equipment, etc. For example:
  • - in two years, the system will be used by no more than 1000 users at a time;
- the data catalog from partners cannot be retrieved more than once a day;
- unstable communication at the places where the product is used;
- users are equipped only with Android smartphones and do not have the ability to view graphs on large screens, etc.


These two documents at the start are enough to have a substantive conversation, to make approaches to the specification of the project and to move towards the evaluation and work plan.

How to filter the list further?

How do you choose the one and only candidate list?

1. Call and interview

When I need to understand some area, I take three or four companies and call them as a potential client. By the third call, I can already answer many questions myself, as a contractor. Everyone tells you different things, and by combining the information, you can build a vision of what is really right for you. Don't be shy about sounding like a pro. I don't know of any cases where a team sees a newcomer to a development topic come to them and the guys think "here we go and undress him." The Internet remembers everything. And those companies that have engaged in such deception don't stay on the market. Do not be afraid to sound like a novice on the subject - it is important to clearly define your business goals and listen to what they say on the other side of the wire.
Already after the first call, you will have factors that you definitely need to go over with the next candidate. For example:
  • Contacts (website, phone, manager)
  • Relevant experience (link to portfolio/website page)
  • Total project budget
  • Project timeframe
  • Term of warranty service
  • Ideas for implementation
  • Taxation system
  • Others at your discretion


2. Make an in-person or online appointment

It is imperative that the person who will be the business customer and the person who will accept the work from the contractors take part in the meeting. It is not necessary to separate the responsibility for selecting the contractor and working with him afterwards. Let the decision be made jointly, but always with the participation of the main person responsible for the project. If you have a procurement department responsible for selecting contractors, don't let them go to the meeting alone. They don't have the same goals as the project's business customer. The best option is to invite representatives of all the teams who will be using the solution developed to the meeting. However, you should not turn the choice into a farce and expect the agreement of all participants, leave the final word to the one who will be responsible for the implementation.

It is important that you make contact with the team at the level of internal feelings. There are no indispensable people in development - you can always find someone who will do the job just as professionally. But putting up with people you are uncomfortable with in such a long project work is not worth it. If you do not like the team in terms of human relations, but you still choose to work with them - you automatically fall into the position of the dependent victim. Like, guys, of course, "not the nicest people," but look what projects they create! And you have to tolerate unpleasant behavior throughout the project. This will not end well.

In a personal conversation, we advise you to pay attention to such things as:
  • Team availability. The contractor must have enough specialists to get the job done. Equally important, all of them must be available during production. If there are not enough resources even when you start, you should get a plan - how and where they will come from. Make sure that the contractor is prepared to provide the project with the necessary team and communicate the sources of its replenishment, if it is necessary to shorten the implementation time or someone from the team will not be able to do the work.
  • Management Competence. Managers and accounts must clearly understand the work front and have the skills to manage the project and communicate clearly. In the conversation, pay attention to their business orientation rather than blindly completing tasks. Development is not an end in itself; the goal is for your company to achieve your chosen metrics.
  • The team's ability to plan what is possible to plan. It's hard to produce something if the engineers can't formulate a sequence of actions.
  • Clarity and openness. Most problems arise because of the low quality of synchronization, understatement, the desire to hide something. If you feel that they are trying to hide something from you, it is better to express your doubts "on shore" and, if the situation is not resolved, stop working.
  • Willingness to take big discounts for nothing. If you're getting a discount for nothing, it's probably a contractor:
  1. put a lot of risks in the estimate and now either intends to fearlessly ignore them (which has consequences), or wanted to deceive you and get an extra margin;
  2. plans to finish the project at the expense of low-quality specialists. This guarantees a failure of deadlines and risks getting a hell of a legacy in the future;
  3. expects to optimize the project in the process. The chance that it will work is small. Risks - see the previous point.

Meetings and conversations are useful not only for choosing a contractor. But also to broaden your own horizons. Even a simple half-hour conversation with an expert can illuminate what you really need.
Bring your goals, not formalized objectives, to contractors. Real engineers work with these kinds of inputs.


How to Dialog


No specification or ToR will help to create quality software if you haven't defined the product development goals and figured out a way to measure their achievement. One task "we want to make an online store" can have different goals - increase revenue/margin, increase conversion of incoming leads into sales, reduce ordering costs, collect data about users for more effective production planning, etc. There can be several goals and each should have a numerical indicator.
It's good if you, as a business customer, know exactly the goal of the event before meeting with the development team. A team that is set up for the best result is sure to ask about it. If you only have an objective, however, schedule a meeting with the developer in person and discuss the details of the project. 

Choosing a reliable contractor is not that difficult. If you prepare and approach the process responsibly, a good team is sure to be found. The main thing is:
  • Formulate primary objectives;
  • Determine the most effective way to synchronize with engineers. For example, when developing an application, it can be prototypes with comments and user scenarios + a description of the entities with which the application works. The chosen method, of course, depends on the competence level of the team and the number of participants in the process;
  • Determine the sequence of functional implementation. This is where it's best to think in terms of increments - a limited amount of functionality that adds value to the business and users. This will provide a consistent plan for developing and building functionality;
  • Talk to the development team about when and what documents and materials will appear, how the results will be demonstrated - this will help both you and them stay on schedule.