Outsourcing development: the six questions that decide the outcome

Outsourced development rarely goes wrong on the technical side. The code ends up existing. What is missing six months later is the ability to know where the project stands, to move it elsewhere, or simply to reach someone on a Tuesday afternoon.

The six questions below are asked before signing. None of them requires technical knowledge. And what they reveal has less to do with the content of the answer than with how fast it arrives: a team that has already settled these matters answers in one sentence, without checking with anyone.

1. Who writes the code, by name?

Ask for names, roles, and a written commitment on the composition of the team. Not an org chart: the people who will actually work on your project.

“Our resources will handle it” means you will never know who is working for you, or how many projects that person is running in parallel. This is not necessarily dishonest — it is how a business selling volume normally operates. But it changes what you are buying: production capacity, not a team.

The signal: an answer that gives first names without hesitating. An answer describing a process instead of people tells you the question had never come up.

2. Who owns the repository?

The right answer is: you do, from the first commit. Not on delivery, not on final payment — from day one.

A repository hosted on the vendor's account creates a dependency that stays invisible while things go well. The day of a disagreement — over an invoice, a delay, a technical choice — it becomes leverage. And the day the vendor disappears, which also happens, it becomes a problem with no solution.

Doing it properly costs nothing: creating the organisation in your name and inviting the team takes ten minutes. Which is precisely why a refusal is informative.

The signal: hesitation. There is no technical reason to host the code anywhere but with the client.

3. How will I see progress?

The wrong answer is a percentage. “We are at 70%” is a sentence that means nothing: the remaining 30% holds the integration, the edge cases and the fixes — that is, most of the time. A project stays at 70% for months.

The right answer is a regular demo — weekly, fortnightly — of one thing that works, shown live, on an environment you can open yourself afterwards. It is the only progress indicator that cannot be arranged.

The signal: the answer mentions a permanently reachable environment, not a demo by appointment.

4. Who answers during an incident, and within what time?

Three elements, and you need all three: a name, a channel, a written response time. With one missing there is no commitment — only a cordial intention, worth whatever that person's availability happens to be that day.

Define what counts as an incident. “The site is down” is easy. “The contact form has been sending nothing for a week” is less so, and it is the more frequent case: nobody notices, because nothing looks broken.

The signal: a stated response time that differs by severity. A single figure for everything signals a commitment that has never been tested.

5. How does the exit work?

The question is uncomfortable, which is exactly why it belongs at the start. Asked at the end, it is asked from a weak position: you need to leave, and the other side knows it.

Three things to get in writing: setup documentation that lets another team run the project, handover of credentials — hosting, domain, third-party services, mailboxes — and an overlap period during which the outgoing team stays reachable.

A good answer here is a sign of confidence. A vendor who knows their work stands up is not afraid to organise their own replacement.

6. What is not included?

The right answer is a list. “Everything is included” is not an answer: migrating existing content, training, hosting, fixes after the warranty period, copywriting and translation all cost money, and each will surface sooner or later.

Naming what is excluded, even without selling it, stops it from reappearing mid-project as something obvious — to one party only.

The offshore case

Three objections come up, and they do not carry equal weight.

• Time zone is the best-established false problem. A few hours' offset mostly means work advances while you sleep, and a question asked at the end of your day has an answer waiting in the morning. Beyond six or seven hours, though, a shared window has to be organised explicitly.
• Working language genuinely matters, though not at the level people expect: technical vocabulary travels without friction. What gets lost are the nuances of a scoping meeting — an “it would be nice to” that meant “this is essential”.
• Governing law deserves three lines in the contract, not a meeting. State the competent jurisdiction and the intellectual property terms, and move on.

Two moments benefit from physical presence: initial scoping and workshops with end users. Everything else — development, reviews, releases, support — works just as well remotely, provided the delivery cadence is regular. Cadence is what replaces surveillance, not the other way round.

A team you watch ship every week does not need supervising. A team you never see ship does not become one because it sits in the next room.

What holds true whatever the team

Most organisations do not choose between in-house and outsourced: they mix both, lastingly. An internal team that knows the business, external reinforcement on rare skills or busy periods. The six questions above apply to hiring too — code ownership, visibility and exit documentation are not outsourcing topics, they are management topics.

Our Web & Mobile Development page describes how we work on these six points. If you are preparing a shortlist, send us what you need: we answer all six in writing before making any proposal.