How to choose an IT contractor

Why companies that combine IT consulting and development more often drive projects to business impact — and where the “just build it to the spec” approach usually breaks.

A practical breakdown: developers, consulting teams, and agencies — without slogans or magic.

There’s one unpleasant type of IT project. It doesn’t fail. It doesn’t burn. You can’t even call it unsuccessful — on paper everything looks great.

The project is “done”. The system “works”. The functionality “matches the spec”. The release is “on time”.

And the business looks at it and doesn’t understand: why didn’t it get better?

People still run part of the process in Excel. Employees try to bypass the system whenever they can. Any change becomes a separate budget and a separate timeline. And the leader catches themselves thinking: “we invested, but we didn’t get the effect”.

And this is where the most dangerous part begins. Not issues with the system — issues with trust. After this experience, phrases appear inside the company like:

— “we already tried automation” — “IT is always slow and expensive” — “let’s not get into this again”

Meaning the company doesn’t lose a specific project — it loses the ability to change quickly.

Most often, the business looks for “strong development” and chooses a contractor based on:

— a good tech stack, — a confident team, — portfolio, — reasonable timelines, — a clear price.

That’s logical. But in complex projects those criteria aren’t enough.

Because pure development has its own nature: a developer is an executor by default. Their work starts where the discussion of “what needs to be done” ends.

If incoming requirements are wrong or incomplete, development will still implement them. Not because they’re “bad”, but because the model is like that: fewer arguments — fewer risks of missing deadlines and taking responsibility.

The result is the situation that makes projects “formally successful, but useless”.

To avoid illusions, let’s look at a typical scenario. It happens very often, and there’s nothing malicious in it — it’s just how the market works.

1) Requirements are taken as given You bring a spec or a set of wishes. They clarify it, “polish” it, sometimes suggest UI or architecture improvements. But the core question “do we actually need this?” usually isn’t asked — because that means stepping out of the executor role.

2) The project becomes a task list Everything is decomposed into sprints: screens, roles, integrations, reports. It’s convenient to manage. But here a substitution happens: the team starts measuring success by closed tasks, not by changes in the business.

3) Acceptance by “matches the spec” The finish can be high-quality: tests, documentation, demo, release. And still the result may not work for the business. Because a spec isn’t always a business goal. More often it’s a description of today’s reality — with its compromises, manual workarounds, and “that’s how it historically happened”.

If you simply digitize that reality, you get exactly what we described: an automated version of old problems.

The system will work. It just won’t help.

In practice, a spec is written from three sources:

1. team habits (“we’ve always done it this way”),
2. current pain (“this part is inconvenient”),
3. compromises (“we do it this way because otherwise it doesn’t work”).

The main layer rarely makes it into the spec:

— what business effect is needed — which metrics must change — where the real bottlenecks are — what blocks growth, not just what annoys people

If this layer isn’t surfaced at the start, the project is almost doomed to become a “thing”, not a “change”.

When a contractor has consulting expertise, their role is different. They don’t start with “what to implement”. They start with “what to change”.

That’s a fundamentally different process, and it usually looks like this.

1) Diagnosis: first we understand the system we’re entering Such a contractor studies not only requirements but reality: processes, people, data, constraints. They look for causes, not symptoms.

At this stage, unpleasant but useful things often surface: — part of the problem is in the process, not the system, — the data isn’t clean enough, — roles and responsibilities are blurry, — people operate “in fact” differently than the regulation says.

This is not delay — it’s savings. Otherwise you’ll build an expensive system on a swamp.

2) Focus on outcomes, not features A clear goal appears: what must speed up, where it must become cheaper, which errors must disappear. Features become tools, not the meaning of the project.

And here something surprising happens: after a proper analysis, half of the wishlist falls away by itself. Not because you “cut costs”, but because it doesn’t create impact.

3) Designing a system, not a set of features When you think from the business, you get answers to: — how the solution will live a year from now — how it will handle volume growth — what happens when processes change — how to make changes predictable, not “a new project every time”

4) Synergy: “thinking” and “building” in one team When consulting and development are in different companies, context is almost always lost. Consultants draw “perfect”, developers say “unrealistic”, the business gets conflict and wasted time.

When consulting and development are inside one team: — ideas are immediately checked for feasibility, — constraints surface early, — solutions become pragmatic, — responsibility doesn’t split into “we designed / they built”.

And most importantly: you get a single chain “analysis → solution → implementation → impact”.

There are things you can’t see from inside a company because everyone is used to them: “this is normal”.

Consultants who have done similar projects many times across industries usually sense in advance:

— where people will resist, — which changes won’t take off because of data, — where the process “on paper” and “in real life” are different, — which architecture will become an expensive trap a year from now, — where automation will amplify chaos if the foundation isn’t fixed.

That is pattern recognition. It has a compounding effect: experience across industries helps you avoid the same rakes that have already blown budgets and timelines for others.

Agencies vary, but the “development agency” model has typical weak points. It’s important to understand them upfront.

1) Agency economics are hours Many agencies earn on the volume of work. Their natural motivation is for the project to continue. The business needs the opposite: for the problem to be solved and the project to end.

2) Context loss because of turnover One developer today, another tomorrow. The PM changes. Context drifts. Decisions are made “on the spot”. And you pay for “ramping up” multiple times.

3) Lots of management, little responsibility for impact Agencies often excel at reporting. But if success is “closing tasks on time”, business impact may have no owner. Then you inevitably hear: “That wasn’t in the spec.”

4) Template solutions where you need process-tailored work Agencies love standard approaches — it speeds up sales and delivery. But complex business processes are rarely standard. Trying to “stretch a template” ends with a system that lives separately from reality.

To be fair: there are situations where pure development or an agency works.

For example: — a clear task, — a detailed spec, — low cost of mistakes, — no complex processes and integrations, — the goal is “build a feature”, not “change the business”.

But if the project affects key processes, money, and operations — if you need resilience and evolution — development alone is usually not enough.

We build projects from the business backward, because otherwise too much money and time goes into rework.

Our approach is simple: — first we understand what really hurts and why, — we remove the unnecessary and simplify before automating, — we design a system for growth and change, — we implement and bring it to the point where people use it, not bypass it.

We combine consulting and development in one team not for positioning, but because it means: — less loss at handoffs, — more responsibility for outcomes, — faster decisions, — and most importantly — the final system becomes part of the real process, not “yet another app”.

The main mistake when choosing an IT contractor is choosing “someone who will build it” when you need “someone who will help you change”.

Pure development is strong at execution. IT consulting + development are strong at driving a project to business impact.

If you care not about checkboxes in a spec but results in metrics, resilience, and scaling — choose a partner who can both think and build.