How to Choose a Development Contractor and Not Get Burned

The scenario is a familiar one: you chose on price, signed a one-page contract and paid 50 percent up front. Three months later, instead of a system there is a set of screens that do not work together, the developer has stopped replying, and you have no source code because it lives in somebody else's repository. From there you either pay more or start over. The most galling part is that nearly all the signs of this ending were visible before you signed.

Red flags during negotiations

• They quoted a price and a deadline at the first meeting without asking a single question about your process. That means they costed an industry average, not your project.
• They cannot show working projects, only screenshots. A live link is the minimum proof that a product reached its users.
• The price is half the market rate. A developer of the same calibre costs the same everywhere; the difference usually comes out of scope they did not show you.
• Refusal to break the project into stages with separate payments. Unwillingness to work in stages is almost always about the contractor's cash flow, not about efficiency.
• They do not ask about load, integrations or data. That means those questions will surface mid-project as "additional work".

What to ask before signing

Who specifically will build the project and whether they are currently busy on other work. What happens if that person leaves. How the source code is handed over and where the repository lives — you should have access from day one, not on completion. What stack it will be written in and why: an answer of "on our own framework" means you will never be able to change contractor. How testing is organised. What the warranty covers and how long it lasts — three months is a reasonable benchmark. And separately: what support will cost after launch, because maintenance is not a bonus, it is a permanent budget line.

How to read a portfolio

It is far more useful to look at problems of the same class than at the design. If you need a back-office system, landing pages in a portfolio say nothing about a contractor's ability to design a database and an access model. Ask which part of the work in the project shown was done by this particular team, and what happened after launch: is the product alive, is it still being developed. That is why we keep a portfolio with descriptions of the problems rather than just pictures — projects like the car rental system or the analytics service show what class of work stands behind them.

Contract clauses you must not sign without

Exclusive rights to the code pass to you upon payment — the wording must be explicit, referencing the Civil Code articles on works made for hire and the assignment of rights. Acceptance procedure: what counts as a completed stage and within what period you must submit comments. Liability for missed deadlines in specific figures, not "the parties shall endeavour". The procedure for handing over access, documentation and data on termination — this clause saves people more often than any other. And a confidentiality clause mentioning personal data processing if the system will work with a customer database: the operator's obligations under 152-FZ remain yours, not the contractor's.

Test them on a small piece

The most reliable way to assess a team is to give them a paid two- or three-week task: an integration, a single module, a prototype of one screen. You will see how they communicate, whether they hit deadlines and what happens at the first surprise. That is cheaper than learning all the same things in month six of a million-rouble project. We usually propose this kind of start ourselves, especially on larger projects — it can be discussed at the first meeting.

On requirements and expectations

Half of all conflicts with contractors arise not from bad code but from the two sides understanding the task differently. The cure is a document, not trust: before work begins it must be recorded in writing what exactly is being built and what is not. We covered how to write such a document so that it protects both sides in our piece on the technical specification. One more observation: a contractor who argues with you during the sales stage and says "you should not build this" is usually more reliable than one who agrees to everything. The second one simply has not started counting yet.