You are worried that a senior will sell you the project and juniors will build it.
You are right to worry. I want to start there rather than argue with it, because the fear is not irrational and pretending otherwise is the first thing that makes a vendor sound like a vendor.
One of the technology leads I work with described his previous experience as front-ending done by seniors and code done by juniors, so quality was hampering. That is a direct quote and it is a common enough experience that most buyers evaluating an offshore firm are running a background process the whole time, trying to work out whether it is happening again.
Why it is standard, stated plainly
It is standard because it is profitable, and the arithmetic is not subtle.
A senior architect costs roughly four times a junior developer. The senior is who closes the deal, because the buyer wants to talk to someone who can hold an architectural conversation without checking notes. Once the contract is signed, keeping that person on the engagement costs four times as much as replacing them with someone cheaper, and the buyer has already committed.
Nobody has to lie for this to happen. The senior is genuinely on the account. They are on the kickoff call. They are on the monthly review. They are simply not the person writing the code, and no one ever said they would be.
That is the structure. It exists everywhere, at every scale, and it is not confined to India. It is worth naming that clearly because a lot of writing on this subject is really about nationality when it should be about incentives.
What I got wrong for about six years
Here is the part I am less comfortable writing.
We have never worked that way. The two senior people here have always scoped and built the work themselves. That was not a positioning decision, it was a consequence of being small: there was nobody to hand it to.
And for about six years we never wrote any of that down. Not on the website, not in a proposal, not anywhere a prospect could see it. I assumed it was self-evident from talking to us.
It is not self-evident. It is invisible. A buyer on a first call cannot tell the difference between a firm where the architect builds and a firm where the architect is the closer, because both of them have put the architect on the call. That is exactly the point of the pattern.
So for six years I offered people a reason to trust us that they had no way to verify, and then felt quietly wronged when some of them went elsewhere. They were not being unfair. They were being sensible with somebody else’s money.
What changed is unglamorous. We wrote it down, in the specific form a buyer can check.
What the answer actually has to look like
A promise is not an answer. “We do not do that” is what a firm that does that would also say.
What a buyer can use has to be structural, checkable, and costly to fake. Three things:
Name the people, with exact titles, before the call. Our About page lists eight people, each with the title they actually hold. Two senior architects, and the rest named as what they are: software developers, a test engineer. Not “consultants”. Not a team of twenty-plus in a stock photo. You can open LinkedIn and check every one of them against what we told you, and if the story does not match the profiles, you have learned something useful in about four minutes.
That is a small thing that is hard to fake, which is the only kind of claim worth making here.
Publish the sequence, including the part that is inconvenient. Here is ours.
I do the architecture and all the technical decisions, and I write the first code. My lead architect builds it to demo-ready. We both present at the demo. User-level work happens after you have accepted that demo, and only with your knowledge.
Read that third phase again, because it is the one a marketing page would omit. Junior people do work on your project. Of course they do. A firm that claims otherwise is either lying or charging you architect rates for form validation.
The thing that matters is not whether juniors touch the code. It is when, and whether you were told. In the pattern you are afraid of, the handover happens quietly, early, and you find out from the code review. In ours it happens after you have seen a working system, and you know the day it happens.
Put a cost on being wrong. Ours: if that sequence is ever reversed without your knowledge, you pay nothing for that engagement.
I want to be honest about what that guarantee is and is not. It is not generosity. It is a promise we can make cheaply because the situation it covers does not arise, and any firm structured the way we are structured could offer the same thing. The reason most do not is that they are not structured that way.
A guarantee is only worth what it costs the person offering it. Ask for one. Then work out what it would cost them, and you will learn more from that number than from the guarantee itself.
The check that costs you four minutes
If you are evaluating anyone, here or elsewhere, run this before the second call.
Ask who will write the first thousand lines of code. Not who is on the team. Not who is your point of contact. Who writes the first code, and when does that change.
Then ask what happens if the answer turns out to be untrue.
Both questions are cheap to ask and expensive to answer badly, which is what makes them useful. A firm that has thought about this has an immediate, specific answer with names and a sequence in it. A firm that has not will reassure you about their commitment to quality.
You will know inside thirty seconds which one you are talking to.
The part that is genuinely harder for us
I am not going to end on our strengths, because there is a real weakness attached to this model and you would find it anyway.
Being small enough that the architect builds the work is also being small enough that the architect is a constraint. We take fewer engagements than a firm our size could. We say no to work we could technically deliver, because saying yes would mean breaking the sequence above, and the sequence is the entire thing we are asking you to trust.
That is a genuine cost and it shows up as capacity, not as quality. If you need thirty developers next month, we are the wrong firm and I will say so on the first call rather than the third.
You should be suspicious of a structural claim that costs the person making it nothing. This one costs us revenue, every quarter, and that is the most honest argument I have for it.
