Who Actually Builds Your Product: Team Questions That Matter

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

For: A pre-Series A founder in Dubai who has received two proposals from offshore dev studios, both quoting similar timelines and prices, but cannot tell whether the team that wins the pitch is the team that will actually build the product

If two offshore proposals look identical on price and timeline, the only question that matters is who sits on your repo on day 30, day 90, and day 180 — and almost no proposal answers it. The questions below are the ones that force that answer out of a vendor before you wire the first milestone. Ask them in the technical deep-dive, before legal review, and insist on written answers you can later attach to the master services agreement.

Context for why this is worth an hour of your prep time: a McKinsey and University of Oxford study found large IT projects run 45% over budget while delivering 56% less value than predicted, and the Standish Group's Chaos Report puts partial or total failure at 66% across 50,000 projects. A large share of that gap is not technical. It is the delta between the team that scoped the work and the team that built it.

The one clause that makes every other question matter

Most startup-tier dev-studio contracts name a "lead engineer" or "project manager" but include no substitution-notice clause. That means the studio can rotate the entire delivery team mid-build without breaching a single term or telling you. Enterprise and government contracts solve this with a key personnel clause — standard language requiring at least 30 days' written notice before any named individual is substituted, and prohibiting substitution without the client's written consent. Startup proposals almost never contain the equivalent.

Before you read the questions below, decide this: you will not sign without a key personnel clause naming at least the tech lead, the senior backend engineer, and the solution architect, with a written-notice-and-consent requirement for substitution. Everything else is downstream of that.

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

1. "Can you send me the GitHub or GitLab handles of every engineer you plan to assign, plus their last three merged pull requests on a comparable codebase?"

Why it matters. Resumes are theatre. Commit history is not. You are checking that the engineers exist, that they ship code at the level the proposal implies, and that their recent work overlaps with your stack.

Good answer. Handles arrive within 48 hours, with links to public repos or anonymised private PR screenshots. The lead's recent commits are substantive — refactors, architecture decisions, not just dependency bumps.

Red flag. "Our engineers' profiles are confidential." "We'll introduce them at kickoff." A vague LinkedIn link for the lead and nothing for the rest.

2. "What percentage of this team is on full-time payroll versus contractors or subcontracted through another firm?"

Why it matters. Subcontracting is not inherently bad, but you need to know. A subcontracted engineer owes loyalty to their employer, not to your project, and when their employer prioritises a different client, your velocity drops.

Good answer. A specific breakdown: "Four full-time employees, one long-term contractor who has worked with us for three years, zero subcontractors." They offer to let you see employment agreements with names redacted.

Red flag. "All our engineers." "We work with a trusted network." Any phrasing that avoids the word "payroll."

3. "What is the average tenure of the five engineers assigned to my project at your company?"

Why it matters. Engineers who joined last month are juniors or lateral hires who have not internalised the studio's practices. If the whole team's tenure averages under a year, you are their training ground.

Good answer. "Lead is 4 years, senior backend is 3, two mids are 18 and 22 months, QA is 2 years. Average 2.6 years." They know the number without checking.

Red flag. "Our team is very experienced" without specifics, or a team where everyone joined within the last six months.

4. "For the senior engineers on this project, how many other active clients are they splitting time with, and at what allocation?"

Why it matters. A tech lead at 25% on your project and 25% on three others is not your tech lead. They are a reviewer, maybe. The real decisions get made by the mid-level engineer doing 100%.

Good answer. "Lead at 50% on yours and 50% on one other maintenance client. Senior backend at 100% dedicated. Two mids at 100%. QA shared across two projects at 60/40."

Red flag. "Our seniors oversee multiple projects." "Allocation is flexible based on needs." Translation: you get them in standups and nowhere else.

5. "Who on this team has shipped a product in my specific domain — not adjacent, the same one?"

Why it matters. "We've done fintech" can mean "we built an invoicing tool once." If you are building a lending product in the UAE, you need engineers who have shipped KYC flows that passed a Central Bank audit, not engineers who have "worked on fintech."

Good answer. Named case studies with named engineers. "Rahul led backend on a similar KYC integration at [client]; he's your senior backend here."

Red flag. Case studies without named team members, or a bait-and-switch where the pitched case study was built by engineers who have since left.

Section 2: Who stays, who swaps, who disappears (questions 6–10)

6. "Will you add a key personnel clause naming the tech lead, senior backend engineer, and architect — with 30 days' written notice and my written consent required for any substitution?"

Why it matters. This is the question. Everything else is diligence; this is the lock. A 2026 vendor contract review flagged the bait-and-switch — senior staff pitched during sales calls get replaced by juniors once the contract signs — as a common vulnerability, and without a named-engineer clause the vendor can satisfy the letter of the contract with an entirely different team each quarter.

Good answer. "Yes, we'll name those three. We'd ask for 14 days instead of 30 for emergencies like resignations, with a replacement of equal or greater seniority subject to your interview." That is a fair negotiation.

Red flag. "We can't commit specific individuals because of our resourcing model." "We guarantee the capability, not the person." Walk away or price in the risk.

7. "What is your voluntary attrition rate for engineers over the last 12 months?"

Why it matters. An Indian or UAE studio with 35%+ attrition will churn through your team no matter what the contract says. The clause gets you notice; it does not stop the departures.

Good answer. A specific number under 20%, ideally with the methodology. "12% voluntary, calculated as departures over average headcount."

Red flag. "Our retention is strong." "We don't track that formally." A number over 30% without an explanation.

8. "If my tech lead resigns in month four, what is your bench depth for a replacement at the same seniority — and will you cover the ramp-up cost?"

Why it matters. Attrition happens. The question is whether their bench is real or whether you'll get a junior with a senior title and a two-month productivity hole on your dime.

Good answer. "We have three engineers at that level currently on billable projects we could rotate; interview them before you accept. Ramp-up time is not billed to you — standard is two weeks at our cost."

Red flag. "We'll find someone." Any version of the replacement being charged at full rate from day one.

9. "Can I interview and reject any proposed replacement, with the same veto rights I had on the original team?"

Why it matters. Written consent in the contract is meaningless if the practical process is "here's your new lead, they start Monday."

Good answer. "Yes. Standard replacement process is a 45-minute technical interview with you, veto with no explanation needed, and we propose the next candidate within five business days."

Red flag. "We trust our hiring process so clients usually accept our recommendation." Translation: no, you don't get a real veto.

10. "Does any part of this build get subcontracted to a third party — including specialist work like ML, DevOps, or mobile?"

Why it matters. Studios that pitch full-stack often subcontract the specialist pieces. Your ML model might be built by a two-person shop in a different city whose work you cannot inspect until it lands in your repo.

Good answer. "All in-house except [specific thing], which we partner with [named firm] on. Here's their lead's background. The contract flows the same IP terms through to them."

Red flag. "We handle everything ourselves" delivered too fast, or a refusal to disclose who touches the code.

Section 3: How the team actually works (questions 11–16)

11. "Who writes the code and who reviews it — can I see your PR workflow for a current project with sensitive data redacted?"

Why it matters. "Senior engineers lead" often means seniors review PRs and juniors write everything. That is fine for some builds and catastrophic for others. You need to know which this is.

Good answer. A screenshot of a real PR with lead-level review comments, reviewer:author ratios, and a stated policy — "every PR needs one senior reviewer; architecture changes need the lead."

Red flag. No written review policy, or a workflow where PRs merge in under 30 minutes with a single thumbs-up.

12. "What does my daily standup look like, who runs it, and which engineers am I in direct Slack contact with?"

Why it matters. Studios that put a project manager between you and engineers are often hiding the engineers. You should talk to the people writing the code, not a translator.

Good answer. "Daily 20-minute standup with the full engineering team on your call. You're in a shared Slack channel with every engineer and can DM anyone. PM runs sprint planning but not daily comms."

Red flag. "Your single point of contact is the project manager." "Engineers focus on code; account manager handles communication."

13. "Who wrote the proposal and the architecture doc — and will those people be on the build?"

Why it matters. PMI's 2023 data cited in project failure statistics puts poor requirements management at the root of 42% of failures. The risk compounds when the person who scoped the work hands off to a team that never spoke to you.

Good answer. "The architect who wrote this proposal is your solution architect on the build, named in the key personnel clause, at 20% allocation through delivery."

Red flag. "Our pre-sales architect scopes, then hands to the delivery team." Guaranteed context loss.

14. "Can you connect me with two references where the team on the engagement was the same team that pitched?"

Why it matters. Most reference calls ask about quality and timelines. Ask instead: "Did the engineers who sold you the project build the project? Did anyone get swapped? Who, when, and with whose approval?"

Good answer. Two references, both willing to answer that question specifically, both confirming continuity or confirming substitutions were disclosed and approved in advance.

Red flag. References who only talk about outcomes. References whose projects started more than three years ago (the current team may be entirely different).

15. "How do you handle the Dubai–India time zone overlap, and which hours is each engineer actually online?"

Why it matters. A Dubai founder working with an Indian studio has a 1.5-hour time difference and a strong overlap window. If the vendor's answer is vague, they are probably planning to shift engineers to US-overlap hours for a US client and give you async-only.

Good answer. "Full team online 11 AM to 7 PM IST, which is 9:30 AM to 5:30 PM Dubai. Daily sync at your 11 AM. Lead available on WhatsApp through your workday."

Red flag. "We're flexible." "We work async." If you are paying for a dedicated team, you should see them live.

16. "What happens to this team after my build ships — do the same engineers do maintenance, or do I get a different pod?"

Why it matters. The engineers who built the system are the ones who can fix it fastest. If maintenance moves to a separate pod, you pay for ramp-up again and lose institutional memory precisely when post-launch bugs hit.

Good answer. "Lead and one mid stay on at reduced allocation for the first 90 days post-launch, then transition to a maintenance pod that shadowed the last sprint. You approve the handover."

Red flag. "Maintenance is handled by our support team." No defined handover.

What this costs you in prep time, and what it saves

Running all sixteen questions properly takes two technical deep-dive calls of 90 minutes each, plus 48 hours for the vendor to pull commit histories and allocation data. If a vendor cannot or will not answer them inside a week, that is itself the answer. The IT outsourcing market is worth over $600 billion and growing — there are other studios. You are not short on options.

The cost side is harder to quantify precisely, but shape it this way: project failures account for an estimated $2.5 trillion in annual global losses per PMI's 2023 compilation, and the single most common proximate cause of a mid-build quality collapse at a startup is a team swap you did not know about until velocity dropped. The questions above cost you a week. A team swap in month four costs you the build.

How CodeNicely can help

If you are a Dubai-based founder evaluating offshore options, we are one of the studios you should put through these sixteen questions — not an exception to them. We publish engineer tenure, commit histories on request, and will sign a key personnel clause naming the tech lead, senior backend engineer, and solution architect with written-notice-and-consent on substitution.

The engagement most relevant to a pre-Series A Dubai founder is GimBooks, a YC-backed accounting SaaS where the engineers who scoped the architecture are the same ones who have shipped against it for multiple release cycles — the continuity point this post is about. If you are building something regulated or data-sensitive in the UAE, our Cashpo engagement on KYC and AI credit scoring is a closer parallel on domain depth. Our Dubai engagement model is built around the 1.5-hour time overlap and in-person quarterly reviews.

Frequently Asked Questions

What is a key personnel clause and why do most startup dev contracts not have one?

A key personnel clause names specific individuals as critical to the engagement and requires written notice (typically 30 days) plus client consent before the vendor can substitute them. It is standard in government and enterprise contracts but rare in startup-tier dev-studio proposals because it limits the vendor's resourcing flexibility. You can request one be added — a vendor that refuses is telling you they plan to rotate the team.

How much should I expect to pay to vet an offshore development team properly?

The vetting itself costs you time, not money — roughly a week of founder and CTO hours across two technical deep-dives, reference calls, and contract review. The variables that move your actual build cost are team seniority mix, time-zone overlap, named-person commitments, and whether specialist work (ML, DevOps, mobile) is in-house or subcontracted. To turn a vendor's range into a quote you can act on, you need the scope locked, the team named, and the key personnel clause agreed — that conversation is one we are happy to have.

Is it legal to require named individuals in a software development contract?

Yes, key personnel clauses are standard contract language in multiple jurisdictions including the UAE, India, and the US. The clause binds the vendor company, not the individual engineer, so if an engineer resigns the vendor must propose a replacement subject to your consent rather than being in breach. You should have a lawyer licensed in your jurisdiction review the specific wording — this post is not legal advice.

What is a reasonable voluntary attrition rate for an offshore dev studio?

Under 20% is good, 20–30% is the industry average for Indian IT services firms, and over 30% signals a studio where you will see team turnover during a six-month build regardless of what the contract says. Ask for the number, the methodology, and the comparison to the previous year's rate.

Should I insist the proposal author is on the delivery team?

At least at the architect level, yes. The person who scoped your requirements and designed the system holds context that does not transfer cleanly to a different engineer, and poor requirements handoff is a documented driver of project failure. A reasonable compromise is the solution architect staying on at 15–25% allocation through delivery as a continuity anchor.