Which projects are better not to take into work according to the Red Jumpers’s experience

I am Kristina Martyniuk, a CEO at Red Jumpers Agency. The company is engaged in hiring developers in Eastern Europe and Latin America. I would like to note that we mostly collaborate with partners that are just about to start, they don’t have extensive experience and elaborated cases. Therefore, we provide consultations about what to pay attention to before starting the collaboration with someone.

In this article, I will tell you about how we recognize problematic clients, what we do in those cases and what projects we don’t accept for work. Our experience will be useful for everyone who contacts customers: the CEO of outstaffing agencies, HRs, and developers who are looking for projects directly.

Thus, here are the requirements to watch out for: 

Unknown budget 

Does the customer not know their project’s budget or the rate they are ready to pay to the developer? It can mean that:

• there’s no budget;
• there’s not enough money;
• the client isn’t oriented on realities of the market;
• the customer is looking for where it is cheaper, then, they aren’t quality-oriented (have different priorities than you).

When a client can’t name the budget by themselves, we announce the approximate number on our page from the beginning and watch the reaction: “On average, such work costs from $15 000 to $20 000, are you okay with that?”. 

• If the customer says, “Sure, let’s dive into the details” — we keep going, and then they can’t say it’s expensive. 
• If the client says they expected a lower price, we refuse. 
• If there is no understanding of the budget at all, we don’t accept this work request. 

Such an approach helps you to save time when evaluating and presenting the value, so you can spend more time searching for other requests with higher conversion. 

Blurred criteria for candidates selection

When the customer says, “I need React Native developer”, but they don’t specify stack, experience, or task types — it’s a bad sign. You need the most qualified and detailed requests to choose a relevant candidate and start the project. 

Instead, some clients even know what soft skills suit them, without mentioning technical requirements. If there are no requirements, it’s worth trying to find out the reason and drill down on: 

• Analyze the reason. In case we don’t contact the client directly and receive the request through partners, the details can be lost. Simultaneously, this may indicate that dozens of competitors got the request, there will be many candidates, and the chance to at least get the interview goes to zero. 
• Initiate the call with the client and ask in person. It helps to get the information and create loyalty: we show them that we are truly interested in high-quality service.
• Ask the partners if it’s their request. Do they need the team expansion personally, or does the client need it? Did the customer submit a request only to them or to anyone else? Have they collaborated before? What do they pay attention to when selecting candidates? Also, if it’s possible, we ask for a direct call with the customer.

If as a result of all attempts to know something about the request for a developer, it still consists of one line, we don’t waste time on this project.

Irrelevant working conditions 

That’s why at the start of the work on request, we ask the customer to formulate the key terms of cooperation:

It often happens that several stages of the interview are completed, many hours of work are done, and at the final stage, you can’t sign the contract due to difficult conditions or unacceptable requirements.

• Salary. Prepayment or NET 30 (payment for the previous month’s work within the 30 days of the following month. How many days does the client have to pay for the work? 
• Work tracking. Do you have to use tracking systems or recording of the developer’s screen? Whether there will be reporting, and in what form?
• Weekends (if you and your customer live in different countries). Can the developer rest on days that are weekends and public holidays in their country? Who pays for it — you or the customer? 
• Vacation. Does your developer plan the vacation in the next three months? If so, you better notify the customer. Otherwise, the client can get angry if the developer suddenly disappears for two weeks and misses the deadlines.
• Fines. What are the fines charged for? What is their size? It’s foremost to ensure the clearness of formulations to avoid blurred formulations with huge fines.

Lack of feedback

We had some cases when the customer refused the developer but recommended frameworks and libraries that are trending now and explained why it’s worth learning them. If the client is serious, they typically argue why the candidate doesn’t fit and even can give bits of advice. Such feedback for a developer is a valuable experience and a possibility for self-improvement. 

Instead, often some clients consider candidates several times and refuse without appropriate argumentation. In our experience, there can be a few reasons why customers systematically don’t give feedback:

• they don’t have clear selection criteria (and here we get back to point 2);
• they have incorrectly defined criteria  and don’t understand who fits them;
• trivially they are looking for someone cheaper. 

In any case, catering to such customers is impossible thus, not receiving feedback several times in a row, we merely reject them.

Request for rare or old technology 

Once, we got to work on a request for age-old Cobol technology. As a result of searching for this “dinosaur” on the market, we figured out that these developers have a rating of $100 since it’s an endangered species 🙂 

For now, when the client comes with a similar request, we first contact them and identify the pain points. Why does he need this particular technology? What problem is it supposed to solve? Is it possible to do it with more modern methods?

In most cases, it turns out that it’s better to redo the project with something new. Firstly, it will allow you to quickly find a developer with a rate of $30 instead of $100. Secondly, in the long run, such a project will be easier to maintain, optimize and scale up.

Short duration requests

We don’t take projects that last less than three months. There are several reasons for this: 

• Unprofitable. The longer the project lasts, the more possibilities for upsale. In our experience, there is a high probability that more developers will need to be added in the process in long-term projects of a year or more. Instead, during short-term projects, these chances are going to zero. 
• Unpromising. The duration of the project indicates the client’s scale, the seriousness of themselves, and the task. If it’s about two months’ work, probably, it’s support or reworking someone else’s code which is demanding. In any case, the prospects are doubtful.
• Not in the developer’s favor. To comprehend the tasks, learn the materials, and integrate into the team, the developer requires at least two weeks. Until they pick up the pace of work, the project will be finished, and they will have to learn new things. Such an approach demotivates and exhausts.

Significant test tasks

Once, the customer gave our developer a suspiciously volumetric test task that looked like a module from a complete big assignment. We accidentally found out that our partners got the other part of this task. It became clear that the customer was getting a whole project by giving the test tasks.

We practice a few approaches that allow clients to evaluate developer’s technical skills but don’t use them for their purposes:

• paid test tasks;
• free test tasks that don’t exceed four hours;
• the proposition is to review an available code sample from the developer on GitHub (developers better have one) instead of a test task.

Three tips on how to filter the projects at the very beginning

We’ve decided that you don’t have to grab each project because they are resource-consuming and unprofitable among them. Let’s sum up how to determine it quickly: 

• At the first contact, pay attention to the “red” signs: lots of unknown variables (budget, selection criteria, negative feedback about developers without specifying the reasons), suspiciously large test tasks, short-term projects, and requirements for rare technologies. 
• Don’t be embarrassed to ask questions. Who is a direct customer? Why are they looking for this technology? Do they agree to work on a prepaid basis? The more details you find out, the quicker you will understand if you need to collaborate with this customer.
• Clarify for yourself with whom you will never cooperate and where you can compromise.