# How to vet a software development partner > What to ask, how to read case studies, who to meet and what to put in the contract before you hand an important system to an outside engineering team. Ilya Ismatov · CTO · 17 August 2026 · Product Bitmason: https://bitmason.dev/en/blog/vetting-a-software-partner/ Choosing an engineering partner is one of the few decisions in a software project that is hard to reverse. Once a team has built the first months of a system, their choices are in the code, the infrastructure and the habits of everyone who works on it. Switching later is possible, but it is slow and it costs momentum. Most selection processes compare the wrong things: portfolios, hourly figures and how polished the proposal looks. This post covers what to look at instead. ## Ask questions that are hard to answer with a script Every partner will say they are agile, transparent and senior. Those words do not separate anyone. Questions that do ask for specifics: - "Walk me through the last project that went wrong. What did you change afterwards?" A team that has never had a project go wrong has either not done many or is not telling you. - "How would you approach the first month of our project?" A good answer asks you questions back. A weak one recites a methodology. - "Who decides what gets built in each iteration, and what happens when we disagree?" You are looking for a clear owner and a way to settle disagreements. - "How do you handle a request that you think is a bad idea?" You want a partner who will say so, explain why, and then respect your decision. - "What does a release look like, from merged code to production?" This shows whether they have real delivery habits or just write code. Listen for the level of detail. Experienced teams answer with examples, trade-offs and the names of tools they use. Inexperienced teams answer with adjectives. ## Read case studies for what they leave out Case studies are marketing, which does not make them useless. Read them for signal: - **The problem.** Is it described in the client's business terms, or only as a list of technologies? - **The scope.** Did the partner build the whole system, or one piece of it? A case study that says "we delivered a platform" might mean a design and a front end. - **The status.** Is the product in production today? Is it still maintained, and by whom? - **The handover.** Does the client own the code and the infrastructure? Was the repository transferred? Absence is informative. A case study with no named client, no status and no scope is a picture, not evidence. When a case is relevant to you, ask to speak to that client. Some cannot agree for good reasons, but a partner with happy clients can usually find one who will take a call. ## Meet the engineers who will do the work The people in the sales meeting are often not the people who will write your code. Ask to meet the lead engineer and at least one other member of the proposed team before you sign. In that conversation, talk about your actual system. Describe a hard part of it and ask how they would approach it. You are not testing whether they know the answer immediately. You are testing whether they ask sensible questions, admit what they do not know, and reason about trade-offs aloud. Also ask how the team is put together. Who has done this kind of work before? Who is new? How much of their time is committed to your project, and what happens when someone leaves? A partner that cannot answer these clearly may be planning to staff your project after you sign. ## Test the partnership with a small paid piece of work The best predictor of how a partner will work is watching them work. Before committing to a large engagement, commission something small and self-contained: a discovery phase, a technical audit, or one well-defined feature. A discovery phase is a good fit because its output is useful whoever builds the product. It usually produces a clarified scope, an architecture proposal, a list of risks and a plan for the first release. Along the way you see how the team asks questions, how they write, how they handle your feedback and whether they deliver what they said on the date they said. Judge the trial on: - Whether the output is specific to your business, or could have been written for anyone. - Whether they found problems you had not seen, and told you about them plainly. - How they communicated when something was unclear or late. - Whether you would want to spend a year working with these people. If the trial goes badly, you have lost a few weeks and learned something valuable. If it goes well, the main engagement starts with a shared understanding already in place. ## Settle contracts, code ownership and access early Legal terms feel like a formality until something goes wrong. A few points deserve attention before you sign anything: - **Intellectual property.** The contract should state that the code, designs and documentation produced for you belong to you, on creation or on payment, without conditions you cannot meet. - **Where the code lives.** The repository should sit in your own organisation on GitHub, GitLab or similar, with the partner as members. If it lives in their account, ownership is a promise rather than a fact. - **Infrastructure and accounts.** Cloud accounts, domains, app store listings and third-party services should be registered to your company. The partner gets access; you hold the keys. - **Exit terms.** Agree what happens if you part ways: notice period, handover documentation, a working build and deployment you can run without them. - **Confidentiality and data.** If the system handles personal or regulated data, the contract should say how the partner treats it and who may access production. A partner who resists any of this is telling you something. In both of the case studies we publish, full repository and code ownership sits with the client, and it is a fair thing to expect from anyone. ## Red flags worth walking away over Some warning signs are worth acting on even when everything else looks good: - A fixed quote and timeline before anyone has asked detailed questions about your system. - No access to the engineers until after the contract is signed. - Reluctance to put code in your repository or to give you admin access. - A team that agrees with every idea you have. You will need someone who pushes back. - Vague answers about who is on the team, or frequent swaps of the people you meet. - Progress reports that list activity (hours, tickets, meetings) with nothing you can run or see. - Pressure to decide quickly, such as a discount that expires this week. None of these proves a partner is bad. Together, or in a critical area, they suggest you will spend your time managing the partner instead of building the product. ## The short version Treat the choice like a senior hire, because in effect it is one. Ask for specifics, read case studies for evidence, meet the engineers, and watch the team work on something small before you commit to something large. Put the code, the accounts and the exit terms in your hands from the first day. A good partner will welcome all of this, because it is how they would choose a partner themselves. ## Questions about this article ### How many partners should we talk to before choosing one? Enough to compare, few enough to go deep. Two or three serious conversations, each with the engineers who would do the work, tell you more than ten sales calls. ### Is a paid discovery phase worth it if we already have a specification? Usually. A specification says what to build; discovery tests whether it can be built as written, and shows you how the partner thinks before you commit to the whole project. ### What should we ask for on the first day of an engagement? Access to the repository in your own organisation, admin rights on hosting and third-party accounts, and a named lead engineer. Everything else can follow. ### Should we choose a partner that knows our industry? Domain knowledge helps, but it matters less than how the team handles unclear requirements. A partner that asks good questions learns a domain quickly.