Logiciel sells engineering teams, so publishing a guide to buying one is awkward and pretending otherwise would be worse. The resolution is that every question here is one we would want a buyer to put to us, and several of them are uncomfortable for us to answer well.
Aim the lot at everybody on your shortlist, this firm included. You are buying people rather than a product, and three things decide how it goes: who actually turns up, who among them may stop a release, and what their AI tooling puts into your repository.
Written replies are claims until the people named in them are inside your repository doing work you picked. A short paid trial turns the claims into evidence inside a fortnight, and it only does that where the terms are agreed beforehand. Three conditions carry most of the weight.
Staff the trial with the exact people proposed for the engagement, not a pre-sales squad and not the firm's strongest pair borrowed for two weeks. Put the names in the trial scope, then require the same names in the statement of work that follows it. A firm proud of its bench agrees to this in an afternoon, and the hesitation itself is the finding.
Give them a slice of the fifteen-year-old estate, with the undocumented behaviour and the test gaps, rather than a clean new service. The greenfield and legacy split is the whole commercial risk in this purchase, so measure the side that carries it. Two weeks on a new microservice confirms only that they can write new microservices.
Put a release candidate in front of the accountable engineer that falls short of the agreed bar, and watch what happens next. How a partner behaves when saying no costs them a milestone is the most informative thing the fortnight will show you, and it is the one answer no reference call has ever reproduced.
Treat it as a hiring loop rather than a meet and greet. Then write those names into the statement of work, with a notice period attached to any swap.
Choose something from the oldest part of the estate, with the undocumented behaviour and the missing tests. A fortnight on a clean new service proves only that they can write clean new services.
Tools, account tiers, retention settings and the data boundary, in writing on day one. At the end of the fortnight, read the pull requests against that list and see whether it described reality.
Every change merges through a named person on your side who has to understand it well enough to maintain it. This is the only test of knowledge transfer nobody can perform for you.
Pretending we have no interest would be worse than naming it. Every question in the paper is one we would want a buyer to put to us, and several are uncomfortable for us to answer well.
Aim them at this firm along with the rest of the shortlist, and read the call to action below as the pitch it plainly is.
The one asking what the proposed people are doing right now. A prepared firm gives current allocation per person with end dates, the share of each week you are buying, and an honest note of who is shared and with whom.
Between engagements, offered with no dates, is a reply nobody can check later.
It is the question that separates an accountable engineer from an account manager. You want one named senior engineer inside the delivery team who can halt a release on their own, including one that costs a milestone, with a worked example of when they last did it and what holding that line cost.
Not on its own. The risk is the undocumented path: a second set of tools and endpoints between your requirements and your branch, under somebody else's retention policy. Ask for the permitted list, a data boundary enforced by configuration rather than by instruction, and how a generated change is labelled and reviewed before it merges.
It should change the price and the sequence, not just the forecast. Ask the partner to separate the greenfield slice from work that has to land inside fifteen years of accumulated behaviour, and to sequence each differently.
One blended velocity across both means they have not read your repository, or are counting on you not noticing until month three.
Partly. This one is aimed at the part of the organisation you are about to rent. Benchmarking Engineering Team Design for AI is the instrument for scoring the structure you already have, domain by domain, against the artefact each row needs. Use that one when nobody new is being brought in.
A VP of engineering or a CTO, with the engineer who will review the partner's commits sitting in the room. Procurement can send the list out. Only somebody who will live with the merge queue afterwards can tell a structural commitment from a reasonable-sounding intention.
Drop your details and we'll send Engineering Team Design for AI: What Buyers Should Ask straight to your inbox - no spam, unsubscribe anytime.
We run a two-week trial sprint at no commitment: working code in your repository, a visible backlog and an architecture note. Give us the same legacy slice you give everybody else on the list. SECTION 7 - FAQ - 5 to 8 questions
Start a trial sprint