The team they sold you isn't the team that ships your code

Every portfolio is an edit, and every pitch stars the seniors you will never see again. I keep watching founders sign an international vendor on a slide deck, then meet the real authors of their code in the git history ten months later. Here is how to check who ships before you sign.

Last week a founder sent me two files in the same email, barely a line of text between them. The first was the deck an agency had used to win his contract the year before: seven senior names, three with conference-stage photos, one case study for an app everyone in the room would recognize. The second was the git blame of his product, ten months after signing. Eighty-two percent of the commits came from two logins he had never once seen in a meeting.

He asked me if that was normal. I told him I see it often enough to be bothered by it, and that almost nobody checks before signing. Least of all when the vendor sits in a country you will probably never visit, in a time zone where most of the agreements happen in writing.

If you hire engineering outside your own country on the strength of a proposal, a portfolio, and one friendly sales call, this piece is about the question that usually goes missing: who, exactly, writes your code once the pen touches the paper?

The hand that signs the contract is almost never the hand that writes the code.

The pitch cast is on loan

A proposal is a sales event, and every sales event has one goal: close. To close, you put the most impressive people you have in the room. That, by itself, is not dishonest. It is how nearly every service sale works, from consulting to construction.

The trouble starts afterward. The person who shone on the call is a scarce resource, and a scarce resource gets spread across many deals. Once you sign, they rotate to the next pitch, and your account falls to whoever is free on the calendar. It is a trailer cast: what you meet at the premiere is gone by the time the film starts.

In a managed squad, like the ones we build at Revin, the lineup goes in the contract, with each person's name and seniority. That is not red tape. It is how you keep the deal from depending on whoever happened to have an open calendar the week of the sale.

What the deck never shows

Every portfolio is an edit. The agency picks the cases that photograph well and leaves out the rest, which is fair. It stops being fair when the edit hides three things that would change your decision.

• A case with no scope: "we worked with brand X" can mean one developer parked on it for six weeks, on a product that already existed.
• A portfolio with no live link: a screenshot is not shipped software. Ask for the URL and the name of whoever built it.
• A team of experts with no names: an adjective is not a lineup, and seniority that will not fit in the contract usually will not show up in the work.
• Quiet subcontracting: part of what you pay can be handed to a third party who never joined a single call with you, and your code passes through hands that are not on any contract.

From a distance, the border helps hide all of it. You do not call the previous client, because they are nine hours away, busy, or because the contact from the slide simply does not pick up.

The person writing your code in month three is rarely the one who showed up on the sales call.

The bill arrives as ghost seniority

The damage from this setup never shows on the invoice. You pay a senior rate and get junior work without review, because the senior who would review it is out selling somewhere else. The code moves, but it moves crooked: a giant PR approved in two minutes, the same function copied across three screens, tests nobody wrote.

In the logistics case that opened this piece, we put the rework from the first ten months at somewhere around $38,000. I rounded that down on purpose, because part of it was refactoring they would have done anyway. Even cutting a third, it is far too much for a problem that started in a sales meeting.

When we take over a product like that in a Diagnostic Sprint, the first read already gives away who wrote it before us: you can see in the history where there was real senior work and where someone was learning on your codebase.

Distance becomes a problem when it hides the team

I have to be honest here, because the easy argument would be 'distrust foreign vendors,' and that argument is lazy. I work for a vendor that is 'foreign' to most of our clients, who sit in the US and the UK. Distance, on its own, says nothing about quality.

Opacity is what costs you. Distance only hurts when it hides who does what. A vendor three time zones away who gives you repo access on day one, shows you who commits, and answers for every delivery is closer, in practice, than the agency down the street that vanishes after lunch. What you need is to see the work, wherever it happens.

🔎 How to check that the pitch team is the code team

You can guard against most of this before you sign, and none of the checks is expensive. The first is to ask for each person's name and seniority inside the contract, not on the slide. A serious vendor writes it down; the one that dodges answers with "our team of experts."

The second is to arrange repo access from day one and actually look at who shows up in the history during the first weeks. If the commit names do not match the pitch names, you already have the conversation you need to have early, while it is still cheap to fix.

The third is the reference check almost nobody runs: talk to a current client of the vendor, not the logo on the slide. Twenty minutes with someone in the middle of a contract tells you more than any case study.

And the most honest check of all is working together before you commit. That is why we sell two weeks of Diagnostic Sprint before any long contract: the people who run the diagnostic are the same ones who stay if you go ahead with us. There is no separate sales team and delivery team.

The question that belongs before the pen

The logistics founder is still with us, rebuilding what could be rebuilt. He said something that stuck with me: he had compared six proposals line by line, put price, timeline, and stack in a spreadsheet, and never once asked who would be typing.

Everyone compares the price on the proposal. Almost nobody asks who sits down to write the code every day, and that second answer is the one that decides how your year goes.

And no, not every project needs this care. If your 'system' is a five-page brochure site, hire a good freelancer and get on with your life; A-team and B-team come out the same when the work is small and finishes fast.

If you want to see who actually shows up on our projects, the cases are at revin.com.br/en/cases, with live product names instead of screenshots. And if you already have a proposal in hand and want to check whether the slide team is the commit team, book a call with us before you sign.