How to choose a software development partner

Picking the wrong contractor costs more than any line in the estimate. A missed deadline means a lost season, and code that can't be handed over to another team means a rewrite from scratch. Yet the portfolio and the price — what people usually look at first — tell you the least about how your project will go.

Here is a systematic way to choose a software development contractor: what to prepare before you start looking, when a freelancer is enough and when you need a studio, which 12 points to check, what to lock into the contract, and which signals should worry you as early as the first meeting.

Where to start: define the task before the contractor

Comparing vendors without a task description is pointless: each will estimate their own version of the product, and prices will differ several times over. Before sending out requests, prepare at least a short 2–4 page specification:

• product goal and success metric;
• user roles and key scenarios;
• must-have features for the first version;
• integrations (CRM, 1C, payments, warehouse);
• data and hosting requirements;
• budget range and the date you need the product by.

The same specification sent to 4–6 candidates turns the choice from guesswork into a comparison. A step-by-step structure and an example are in our article on how to write a software requirements specification.

Freelancer or development studio

The “freelancer or development studio” question isn't about quality — there are plenty of strong independent engineers. It's about risk and the scale of the task.

A practical option for many companies: a studio builds the MVP and sets up the architecture, then the product is handed over to an in-house team together with the code and documentation. This only works if the handover was planned from day one — more on that below.

Checklist: 12 points for choosing a contractor

This list works equally well whether you're choosing a development studio for a platform or an independent developer for a bot. Score each point as “yes / partly / no”.

1. Relevant case studies. Not “pretty pictures” but projects of similar complexity: roles, integrations, load. Ask to see a working product, not just screenshots.
2. The people who will build it. Who exactly owns the architecture, who writes the code, and will you talk to the developers directly or only to a manager.
3. Process. How often are demos, is there a staging environment, where can you see the task board. A good answer is a demo every week and a staging environment from the first weeks.
4. Questions for you. A strong contractor asks a lot of uncomfortable questions about your business and metrics. If an estimate arrives an hour later without a single question, it's an estimate of something else.
5. Estimate structure. The estimate is broken down by stages and features, with assumptions and risks visible — not one turnkey number.
6. Code ownership. The contract states explicitly that exclusive rights to the result pass to you, and the repository lives in your account.
7. Hosting. The product is deployed on your servers or in your cloud; domains and access are registered to you.
8. Security. How secrets and credentials are stored, who has production access, how personal data is handled under 152-FZ (Russia's personal data law).
9. Code quality. Is there code review, automated tests, CI/CD, error monitoring. Ask to see a code sample or set up a technical call with your own expert.
10. Documentation and handover. What you get at the end: architecture description, deployment guide, credentials, team training.
11. Post-launch support. Is there an SLA: response time for critical bugs, support hours, hourly rate for further work.
12. References. A chance to talk to one or two past clients is the best way to verify everything above.

If a candidate scores “no” on points 6, 7 and 10, the rest barely matters: even a good product will end up hostage to your relationship with a single team.

Code ownership and where the product is hosted

This is the most underrated part. A typical story: the product works, but it runs on the contractor's server, the domain is registered to one of their employees, and you don't have the repository. Changing teams in that situation turns into a negotiation.

What to put in writing

• Assignment of the exclusive rights to the code and design to you — via signed acceptance certificates, stage by stage or at the end of the project.
• A list of third-party components and their licenses: open-source libraries with “viral” licenses can restrict commercial use.
• The repository (GitHub, GitLab or your own) is created under your company's account, and the contractor works in it as an invited member.
• Cloud, servers, domains, App Store and Google Play developer accounts, payment dashboards — all registered to your legal entity.
• The handover includes documentation, environment variables, an infrastructure diagram and a deployment guide.

Contract, payment and SLA

The payment model shapes how both sides behave. There are two main options:

Either way, tie payments to results you can verify: the stage is accepted, the scenarios pass on staging, the code is in your repository. Paying 100% upfront for the whole project is a bad idea under any model.

Acceptance and warranty

Spell out how each stage is accepted: against a checklist of scenarios from the specification, on the staging environment, with a fixed window for feedback (for example, 5 business days). Separately agree on a warranty period after launch — usually one to three months — during which the contractor fixes bugs in delivered functionality for free. It's important to tell a bug (“the payment button doesn't work in Safari”) from a new requirement (“let's add installment payments”): the latter is paid as a change in scope.

SLA-based support

A support SLA usually covers: incident classes (critical, major, minor), response and resolution times for each, support hours (business hours or 24/7), the escalation path and the cost of work outside the support scope.

Red flags at the first meeting

• An estimate with no questions and no analysis — “we'll do it in 2 weeks” before understanding the task.
• A price 2–3 times lower than other candidates for the same specification, with no explanation of how.
• Refusal to show working products or share the contact of at least one client.
• “We hand over the code after full payment”, “hosting only with us”, “we'll register the domain in our name, it's easier”.
• No developers at the meetings — only a sales manager.
• The same stack for every task: a bot, a marketplace and an AI system all get the same offer.
• No answer to “what happens if we want to switch contractors in a year?”

How to choose a web studio: questions for the meeting

If you're figuring out how to choose a web design and development agency for a website or web app, add these specific questions to the general checklist:

1. What are the speed scores of your latest websites? You can check them in PageSpeed Insights right at the meeting.
2. How do you handle technical SEO: structured data, sitemap, canonical URLs, speed?
3. Which CMS do you use, and how easy is it to change content without a developer?
4. How is analytics set up: goals, events, CRM integration?
5. What does support include, and what is the hourly rate for work after launch?

Budget benchmarks help you screen out unrealistic offers before any meetings: reference prices are collected in the article how much does a website cost and on the development pricing page. What a website project usually includes — from prototype to hosting and analytics — is shown on the website and web app development page.

For transparency, here is our own approach, and you can check us against this checklist too: the code, repositories, servers and domains belong to the client; the product is deployed on your servers or in your cloud and handed over in working order, with documentation; you have direct access to the developers and weekly demos. More about the team is on the about B2B-Lab page, and examples of our work are in the case studies section.