How to Choose a Contractor for IT Development and Get a Result That Will Benefit the Business? A JetStyle Guide

Development by an external team lets you speed up automation when in-house development resources aren’t enough, and it gives you a cheaper start compared with building your own IT team from scratch. Let’s talk about what matters when you’re deciding on a contractor.

But let’s start with when you should not order development:

1. If you know how to manage development (first) and have no trouble expanding your headcount of qualified programmers (second), then doing it in-house will be more profitable.

2. If you’re going to automate a process that doesn’t exist yet, don’t waste resources — new software won’t help you create that process. (In the next article I’ll explain how to figure out which process is the main one and how to unfold development around it. Subscribe so you don’t miss the announcement.)

But if there is a process that needs automating, and there is a shortage of development — read on.

Two IT outsourcing scenarios

Usually companies turn to custom development when they don’t have enough of either resources or IT expertise inside to automate one process or another, or to scale the business.

And companies that do have IT expertise inside and those that don’t will behave differently.

Option one — IT expertise exists, but there isn’t enough of it. It’s all fairly simple: you hand out the separable parts of the system/product/whatever to an outside team.

The more qualified the client is in this case, the higher the chances that the outside team will be chosen well, the tasks set correctly, and the business will get exactly the effect it needs.

Option two — the company has no IT expertise inside, but it does have processes that need automating. Most often the needs in such cases get phrased as “build an online store,” or “a marketplace,” or “a CRM,” or some other IT system, or something along those lines.

This is where the main risk for this type of client lies. Because if there’s no IT expertise inside, then in most cases there’s no expertise in managing IT either. Often the assignment then gets phrased as a set of features, and along the way the link between the solution and the meaning of the activity gets lost. And the result of the rollout is that even if the system works “as ordered,” it’s badly built into the processes, it’s hard to get any benefit out of it, and it brings no real value.

So if a company has no IT expertise of its own, it’s critically important to find a competent contractor who will share their expertise.

Setting the task: a technical spec or a product approach?

Now let’s look at where the differences show up when tasks are being set.

Most often companies that have no IT expertise, or not enough of it, try to reduce the risks around speed, predictability and quality of the future system by writing a detailed technical specification. But the requirement to follow a detailed spec reduces how well the solution can adapt to the real needs of the business — and those needs, in turn, can only be clarified through experiments. And if at the start of the relationship we’ve nailed down exactly what the IT system must be functionally, changing it later is hard. As a result the company risks getting a solution that at best looks good and doesn’t even glitch too much, but brings no benefit, because it was built on the wrong part of the process — the one that shouldn’t have been automated — and in the wrong way.

A technical spec does help, though, when you need to reproduce something that already works: for example, if the existing automation has proven its effectiveness, but some of its parts have become technically outdated and you just need to update those parts. That is, the more the task resembles the scenario “let’s not invent anything, let’s just make it work the way it already works,” the more likely it is that a technical specification is the right decision.

But the more innovation there is in the activity, the more the company is trying to evaluate something that will change the situation for the better through some invention (it doesn’t matter what in: management, marketing, production technology, etc.), the more you’ll have to experiment — which means the less suitable spec-driven development is, and the more important it becomes to find a contractor you can work with in product logic — one who will let you not nail down the future image of the IT system, but instead approach the image of the result flexibly and iteratively, testing various hypotheses.

Choosing a contractor: what to look at?

Let’s again go through our two cases: when the company has IT expertise and when it doesn’t.

When a company has its own developers, IT expertise, management, and a methodology on which development management is built, and it’s looking for a way to strengthen or expand its resources, the most important thing is to find a contractor who works in similar logic and will slot into the existing processes painlessly.

Usually in such cases people look at the following things:

• Does the contractor have the necessary competencies and IT development skills
• Do they work with the required technology stack
• Have they built systems with a similar functional profile
• Is the contractor’s IT culture similar to the client’s IT culture

In general, you need to answer the question: “How close are the contractor’s ideas about how things should be done to ours?”

And when a company has no developers and no IT expertise of its own, the contractor who gets hired becomes the donor of development culture. Which in turn means you need to find a contractor for whom what matters is not grabbing as much money as possible right now and inflating the contract, but developing the future IT system together with you. They should be set up for long-term cooperation and interested not in simply reporting back in the format “I did everything, give me the money,” but in the client company’s effort paying off — because then the client becomes a repeat client for them, and the invoice will most likely grow, because the client will see their costs paying off.

It’s important that the contractor doesn’t just take responsibility for design and programming, but looks for solutions to business problems through IT together with the client, that they can explain in plain words how the business hypotheses will be tested and by what means. So a good sign is when the contractor immediately talks about:

• How the result of their effort will influence business metrics
• And how to speed up getting a measurable benefit in the client’s processes.

In today’s world, when it comes to creating digital products, a competent client more often chooses a flexible methodology and, consequently, iterative development instead of spec-driven development — especially when it’s about creating a new product. That’s why we believe the most correct way to find an outsourced contractor is to find an external product development team.

I talked about this in a lot of detail here. If you’re currently looking for an external development team, that article will help you understand how the market is set up in general and find the best option for you.

Or you can simply write to me on Telegram or sign up for a short Zoom call — we’ll discuss your task and work out the next steps together.