How to Choose the Right IT Company for Your Project

Full disclosure: this is written by a development agency. We have a stake in the answer, so read it accordingly — as a checklist you can also run against us.

A bad contractor rarely looks bad at the start. The problem isn't the ones promising the moon — those are easy to spot. The problem is that the gap between a strong team and a mediocre one shows up in month three, once the money is spent and changing course is expensive.

So the goal isn't to find perfect people. It's to surface in the first two meetings what normally surfaces halfway through the project.

Check what's alive, not the portfolio

A portfolio is pictures. Designers make them, and a beautiful cover says nothing about whether the product works or whether anyone uses it.

Ask for links. Not screenshots, not a case-study PDF — addresses that open. If it's a mobile app, ask for the store listing and look at the last update date: an app untouched for two years is probably dead.

Then the most useful move: ask for a client reference from a case similar to yours. A refusal isn't automatically a red flag — NDAs exist. But if the refusal is vague and repeats across every case, that is your answer.

Clutch and Google reviews beat the agency's own site: they're harder to fake, because the platform verifies the reviewer was a client. Read the text, not the score — and pay attention to what people say about communication and about what happened after delivery.

Ask for questions, not a price

The clearest sign of a good team in a first meeting is that they ask you uncomfortable questions instead of naming a figure.

A contractor willing to quote from a three-sentence brief has either padded the number heavily or misunderstood the task and will come back for more money midway. Both are bad; the second is worse.

Good questions sound like this: who will use it, how many of them, what systems do you already run, who inside your company signs off, what happens if launch slips by a month. If they don't ask you, they aren't asking themselves either.

That said, a starting figure should exist. An agency that after years of work still can't say where a website or an app begins either never counted, or doesn't want you comparing.

Find out who will actually do the work

The people in the meeting are usually the founder and a salesperson. Different people will do your project. That's normal — what isn't normal is not being told who.

Ask directly: how many people on the project team, what are their roles, will they be on other projects at the same time, who is your standing contact, and what happens when they go on holiday. And ask to meet at least one engineer before you sign.

Company size on its own means little. A large one has depth and slack, but your project may rank twentieth. A small one gives you more attention, but one person falling ill moves the deadline. What matters is not the headcount — it's a straight answer about who specifically will spend how much time on you.

Ask about month seven

Almost every question in early meetings is about launch. Almost every problem happens after it.

A product outlives its build. In six months a new iOS ships, your payment provider changes its API, and you think of a flow nobody planned for. Who does that work, and at what price?

Be specific: what does a month of support cost, how fast is a critical bug fixed, do they fix their own bugs for free and for how long, and where do the server and domain live and in whose name. That last one matters more than it sounds: if the domain and hosting are registered to the contractor, leaving becomes a negotiation.

The paperwork worth reading

Two points where you shouldn't compromise.

First, the NDA. A serious agency signs it before you start describing details, not after.

Second, code ownership. The contract should say the source and all rights transfer to you — not that they are "made available for use". While you're at it, ask where the repository lives and whether you get access from day one. Access to the code as work proceeds is the best insurance against an unpleasant conversation at the end.

Where we disagree

Lists like this usually carry two criteria we think are overrated.

"A modern stack." The technology list on an agency site proves nothing — a marketer wrote it. React or Vue, Flutter or native: for your business the difference is almost always smaller than the difference between a strong and a weak engineer using either. Don't ask what they write in; ask why that choice fits your task.

Time zones. People love to bring this up, but after years of remote work it stopped being a real problem: most communication is asynchronous and a call fits any window. If the hours genuinely get in the way, the issue isn't the hours — it's that nobody is replying.

Geography does affect price, though, and that's fair. The hourly cost base in Osh and in Moscow differ several times over, with the same stack and the same level of engineer. Our team sits in Osh — which is exactly why our prices are published.

A short list to take to the meeting

If you read nothing else, bring these questions:

• Can I get links to live projects and one client reference?
• What will you ask me before naming a number?
• Who specifically will work on this, and for how much of their time?
• What does post-launch support cost, and what's included?
• In whose name are the domain, hosting, and repository?
• Do all rights to the code transfer to me?

If they answer half of these confidently and specifically, that's already a good sign. All six is rare.