Who Actually Runs Your Project: Team Questions to Ask Now

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A seed-to-Series A Indian SaaS or consumer-app founder who has shortlisted two or three dev studios, received proposals, and is about to sign — but has no idea whether the senior architect who ran the sales call will ever touch their project again

Before you sign, ask the vendor for the GitHub handle, LinkedIn URL, and current project allocation of every named engineer in the proposal — and ask them to commit in writing that any replacement needs your approval, not a 30-day notice. That one request will tell you more about who actually runs your project than ten reference calls. The rest of this post is the full interview script: 15 questions designed for the final vendor meeting after proposals are in and before the MSA is signed, with what a good answer sounds like and what should make you walk.

The reason this matters is structural, not anecdotal. Talent turnover in outsourcing firms averages 20% annually and affects roughly 40% of projects, according to Gitnux's 2026 outsourcing data. Industry analysis of staff-augmentation failure modes names the pattern directly: a principal architect runs the technical interview, then gets reassigned to another pitch two weeks after the SOW is signed (NextGenCodingCompany, 2025). The same source estimates engineering teams waste up to 30% of contract value when vendors pass mid-level bench staff off as senior engineers. And bench pressure is getting worse — major Indian IT firms including HCL and Tech Mahindra have cut bench tolerance from ~120 days to ~60, per Staffing Industry Analysts, which means any engineer sitting idle is being rotated onto your project whether or not they are the right fit.

You cannot fix this with a better contract alone. You fix it by asking the right questions before you sign and refusing to accept vague answers.

Before the call: what to have in hand

Have the proposal open, the MSA draft open, and a notes doc with the names of every person the vendor has put in front of you so far. If a name appears in the proposal but you have never spoken to the person, flag it. That gap is where bait-and-switch lives.

The 15 questions, grouped by what they expose

Group 1: Who is actually on the team (questions 1–5)

1. Can you share the LinkedIn profile, GitHub handle, and current client allocation of each engineer named in the proposal?

Why it matters: Names on a slide are cheap. A GitHub handle and a current allocation percentage are not. If an engineer is listed at 100% on your project, they should not also be listed at 60% on someone else's.

Good answer: "Here are the five profiles. Priya is at 80% on your project starting Feb 1, 20% on internal R&D. Rohan rolls off his current engagement Jan 25, then 100% on yours." Specific, dated, additive to 100%.

Red flag: "We'll finalise the team after kickoff" or "Our resource manager assigns people based on availability." This is the single most common dodge and it almost always means a bench rotation.

2. Of the people in this room right now, who will be writing code on my project in week one?

Why it matters: The sales call is often staffed by a solutions architect, a delivery head, and a BD lead. None of them may ever commit a line of code to your repo.

Good answer: A named engineer in the room says "I will. Here's what I'd start with in week one." Then they describe it in technical specifics.

Red flag: Everyone looks at the account manager. The account manager says the tech lead will be "introduced during onboarding."

3. What is the ratio of senior to mid to junior on my proposed team, and how is each defined internally?

Why it matters: "Senior" at one studio is 8+ years and three production systems; at another it is 3 years and a certification. Pricing is usually blended, so the ratio directly determines what you are getting for the blended rate.

Good answer: "One senior (9 years, led two fintech backends to production), two mid (4–6 years), one junior (1.5 years, mentored by the senior, ships under review). Senior at our firm means has owned at least one production system end-to-end."

Red flag: They cannot articulate the internal definition, or the ratio is 1:4 junior-heavy with the senior at 20% allocation.

4. Who is the escalation path when the lead engineer is on leave, sick, or gets poached?

Why it matters: Single-threaded leads are a continuity risk. You need to know the bus-factor before, not after.

Good answer: A named backup engineer who has been pair-reviewing from day one, plus a delivery manager who runs the standup if both are out.

Red flag: "We'd assign someone from the bench." Translation: an engineer with zero context on your codebase will be reading your Confluence for a week while your sprint burns.

5. What is your attrition rate for engineers in the last 12 months, and how many of the people on my proposed team have been at the company for more than two years?

Why it matters: Industry average is around 20% (Gitnux, 2026). Significantly worse than that is a tell. Significantly better suggests either strong culture or they are hiding something — ask for the methodology.

Good answer: A real number, honestly. "We ran at 18% last year. Of your five proposed engineers, three have been with us 3+ years, two joined in the last 12 months but came from [named prior employer] with 5+ years each."

Red flag: "We don't share that" or a suspiciously low number with no methodology.

Group 2: The contract clauses nobody reads out loud (questions 6–9)

6. Show me the exact clause in the MSA about resource substitution. What rights do I have if you want to swap an engineer?

Why it matters: Most Indian studio MSAs include a 30-day substitution clause that lets the vendor replace any named resource without your written approval. You can usually negotiate this out, but only if you ask before signing.

Good answer: They open the MSA, read the clause, and offer to amend it to "replacement requires written client approval, replacement must have equal or greater years of experience in [stack], and there is a 2-week paid overlap for handover."

Red flag: "That's standard, every client signs it." Standard does not mean non-negotiable.

7. What percentage of your current revenue comes from your three largest clients?

Why it matters: If one client is 40% of revenue and that client ramps up, your team is the first to get raided. Industry sources on common failures in India IT outsourcing flag concentration risk explicitly.

Good answer: A clear number. "Our largest client is 22% of revenue. No single client is more than 25%. Your project would be ~8%."

Red flag: Evasion, or a number above 50% on a single account.

8. If I need to pause the engagement for 60 days for fundraising, what happens to the team?

Why it matters: Startups pause. Vendors need to warehouse your team or let them go. The honest answer tells you whether the same humans come back.

Good answer: "We can hold the team for up to 45 days at a retainer. Beyond that, we release them to other projects and reassemble on a best-effort basis — we'd be honest that two of five may not be available."

Red flag: "No problem, same team whenever you come back" — this is almost never true after 60 days.

9. Who owns the IP, the repo, and the deployment infrastructure during and after the engagement?

Why it matters: Some studios host your code on their GitHub org and transfer only on final payment. Some keep AWS accounts in their name. Both are leverage against you.

Good answer: "Your GitHub org from commit one. Your AWS account from day one. IP assigns on invoice payment per sprint, not at project end."

Red flag: Any version where you do not control the repo and infrastructure from day one.

Group 3: The technical deep-dive signals (questions 10–12)

10. Walk me through a production incident one of your teams handled in the last 90 days. Who was on-call, what was the root cause, what changed afterward?

Why it matters: Studios that have never run anything in production will not have a story. Studios that build and hand off will tell you the client's on-call handled it.

Good answer: A specific incident with a named engineer, a clear RCA, and a concrete process change. Bonus if the engineer on the call was involved.

Red flag: "We don't typically handle production — that's the client's responsibility." Fine, but then they have never felt the consequences of their own code at 3am.

11. What is your code review process, and can you show me a recent pull request from a project of similar scope?

Why it matters: Rework rates on outsourced code average 27% (Gitnux, 2026). Review discipline is the single biggest predictor.

Good answer: "Every PR needs one senior approval and passes CI. Here's a redacted PR from a recent engagement — note the review comments, the test coverage requirement, the deployment gate."

Red flag: "We review internally" with no artifact.

12. How do you handle the gap between what the sales team scoped and what the engineering team discovers in week two?

Why it matters: 35% of outsourcing projects face scope creep leading to 20–30% budget overruns (Gitnux, 2026). The handoff between sales and delivery is usually where this starts.

Good answer: "We run a paid 1-week discovery before fixing scope. If the engineering team finds the sales estimate was off by more than 15%, we re-baseline with you before sprint 1." The engineer who will lead the project is in the discovery.

Red flag: "We'll flag change requests as they come up" — this is how 30% overruns happen.

Group 4: The reference call questions you probably forgot (questions 13–15)

13. (To the reference client) Was the team on your project the same team pitched to you in the sales process? If people changed, how was it handled?

Why it matters: This is the one question that cuts through everything. Ask it on every reference call.

Good answer: "The tech lead stayed throughout. One mid-level engineer rotated after month 4 — we were told two weeks in advance, got to interview the replacement, and had a two-week overlap."

Red flag: "Honestly, the team changed a lot. We never met half of them before kickoff."

14. (To the reference) When the project ran into trouble, who showed up — the account manager, or the engineers?

Why it matters: You will have hard weeks. You want to know whether the vendor sends a project manager with a status deck or an engineer with a laptop.

Good answer: "Their CTO joined a call within 24 hours when we had a production issue. The senior engineer stayed late twice to debug with our team."

Red flag: "We mostly dealt with the account manager."

15. (To the vendor) What is one project in the last two years you wish you had not taken, and why?

Why it matters: A vendor who cannot name one is either lying or has no reflective practice. Both are bad.

Good answer: A specific story about misalignment, scope, or a client-fit issue, and what they changed in their qualification process afterward.

Red flag: "We're proud of every project."

What this costs you in time, and why it is worth it

Running this interview properly takes one 90-minute call per shortlisted vendor, plus two reference calls of 30 minutes each. Call it 4–5 hours per vendor. Across three shortlisted studios, that is roughly 15 hours of founder time before signing.

The alternative, per PMI's Pulse of the Profession, is that 12% of organizational resources get wasted on poor project performance — $1 in every $8 produces no usable output. On any engagement past six figures, 15 hours of interview time is the highest-ROI work you will do all quarter.

The number itself — what a project will cost and how long it will take — is driven by three things these questions expose: the seniority mix you actually get (not the one on the slide), the rework rate (which tracks review discipline), and scope stability (which tracks the sales-to-delivery handoff). Pin those three down and the range narrows sharply. Leave them vague and you are signing a blank cheque with a fixed-price label.

How CodeNicely can help

We get asked these questions. We prefer it. On GimBooks — a Y Combinator-backed accounting SaaS for Indian SMBs — the founding team interviewed our engineers directly before signing, kept the same core team through multiple product pivots, and owns every line of code and every AWS resource. That continuity is not a slogan; it is the reason the product shipped and scaled. If you are at the signing stage with another studio and want a second-opinion technical call with the engineer who would actually lead your build — not a sales lead — that is a conversation we are happy to have. See how we work with startups or browse the full offerings.

The one thing to do before you sign

Open the MSA. Find the resource substitution clause. If it lets the vendor swap any named engineer within 30 days without your written approval, ask for an amendment that requires your approval, equal-or-greater experience, and a two-week paid overlap. If they refuse, you have your answer about who actually runs your project.

Frequently Asked Questions

How many vendors should I shortlist before running this interview?

Three is the sweet spot. Two gives you no comparison; four or more and the 15–20 hours of interview time starts to eat into the time you should be spending on your own product. If you only have two, run the full interview on both and add a third for pricing calibration.

Is it reasonable to ask for engineer LinkedIn profiles and GitHub handles before signing?

Yes, and any reputable studio will share them. Some will redact last names on the first pass for privacy, which is fair, but they should be willing to introduce you to each named engineer on a 20-minute technical call before you sign. If they refuse this entirely, the "dedicated team" in the proposal is probably not real yet.

What drives the cost of a dev engagement in India, and how do I turn a range into a quote?

Three things move the number more than anything else: the seniority mix of the team (a senior-heavy team costs more per hour but typically ships faster with less rework), the scope stability (fixed scope is cheaper upfront but punishes change; T&M is more flexible but needs tight governance), and integrations (every third-party system — payments, KYC, mapping, telephony — adds discovery and testing time). To turn a range into a real quote, a vendor needs to see your current product state, your target scope for the first release, and your must-have integrations. Any studio quoting a price without those three inputs is guessing.

How long before kickoff should I ask these questions?

At least two weeks before you intend to sign. You want time to get written answers, verify a couple on reference calls, and negotiate contract amendments without feeling rushed. Vendors who pressure you to sign within 48 hours of a proposal are flagging their own cash-flow situation, not your urgency.

What if a studio refuses to amend the resource substitution clause?

That is useful signal. Push once, politely, with specific language. If they still refuse, either the clause is genuinely load-bearing to their business model (meaning they rotate people frequently) or they are testing whether you will fold on contract terms generally. Either way, you have learned something important before signing. Contract language itself should always be reviewed by your own lawyer — nothing in this post is legal advice.