The Questions Non-Technical CTOs Ask Before Signing a Mobile Development Contract

A non-technical CTO evaluating a mobile development vendor faces a specific problem. The vendor's pitch is full of claims that are difficult to verify without a technical background — framework choices, architectural approaches, tooling decisions. All of it sounds credible. Very little of it is directly observable.

The good news is that the factors that actually predict whether a vendor will deliver are not technical. They are operational. How fast they ship. How they communicate when something goes wrong. Who is actually doing the work. What happens when a deadline is at risk.

The twelve questions below are designed to surface the answers to those questions. None require technical knowledge to ask or interpret.

What you are actually evaluating

When a non-technical CTO selects a mobile vendor, the decision comes down to three things: whether the vendor will deliver on the timeline and quality they are committing to, whether you will know about problems early enough to act on them, and whether the team doing the work is the team being presented. The twelve questions below are organised around those three dimensions.

Questions about delivery

Question 1: What was your average release cadence across your last three engagements?

What you are looking for: a specific number — weekly, biweekly, or monthly with a clear reason. A vendor that answers in ranges without specific data ("it depends on the project") is not tracking delivery cadence. A vendor that tracks it can tell you immediately.

Question 2: What is your estimation accuracy over the last six months?

What you are looking for: a number and a method. "We estimate within 15 to 20 percent on most features" is a real answer. "Estimates vary by project" is not. The follow-up question: how do you track this, and can you show me an example? A vendor with a real estimation process has a way to measure it.

Question 3: Can you share release notes from a recent engagement?

What you are looking for: specific, detailed notes that describe what changed, what was fixed, and what is coming next. "Bug fixes and performance improvements" is not a release note. It is a placeholder. The quality of a vendor's release notes predicts the quality of everything else they communicate. Ask to see two or three from the last month.

Question 4: What is your App Store approval rate on first submission?

What you are looking for: above 90 percent. App Store rejections add days to every release cycle. A vendor with a low first-submission approval rate is not running pre-submission compliance checks. Ask specifically what their process is for reviewing features against App Store guidelines before submission.

Questions about communication

Question 5: Can I see a sample weekly status report?

What you are looking for: a document that covers what shipped, what is on track, what is at risk, and what you need to decide. Not a meeting agenda. Not a slide deck. A written document that arrives without being requested. A vendor that cannot produce a sample in 24 hours does not have a reporting process. A vendor that says they prefer verbal updates is describing a process that will leave you without a record when something goes wrong.

Question 6: Walk me through the last time a deadline was at risk. When did you tell the client, and what options did you give them?

What you are looking for: a specific story with a specific timeline. The vendor told the client two weeks before the deadline was at risk, not on the day it was due. They came with options — adjust scope, extend the timeline, reprioritise. A vendor that answers this question vaguely, or describes finding out close to the deadline, is telling you how they will handle the same situation on your engagement.

Question 7: What does your escalation process look like when something goes wrong?

What you are looking for: a named person, a defined response time, and a format. "You would contact our account manager and we would schedule a call" is a process. "We would figure it out as needed" is not. Ask what the response time is for a critical production issue. Above four hours for acknowledgment is a problem.

Questions about the team

Question 8: Who specifically will be working on my product, and are those the people I am meeting today?

What you are looking for: names and roles. A vendor that presents senior engineers during the sales process and assigns junior engineers after signing is common. Ask directly whether the people in the room are the people who will be doing the work. Ask what happens if one of them needs to be replaced and what the notification process looks like.

Question 9: How long has your team worked together?

What you are looking for: a team with six or more months of shared history. Teams that have worked together long enough to have developed a process deliver more reliably than teams assembled for a specific engagement. The answer tells you whether you are getting a stable team or a set of individuals.

Question 10: Can I speak to a client whose engagement is similar to mine?

What you are looking for: a reference in your industry, for a project of similar complexity, who is willing to take a direct call. Not a written testimonial. Not an email exchange. A phone call where you can ask the four questions that matter: what was the release cadence, did they hit milestones, how did they communicate when something went wrong, and would they use them again?

Questions about risk

Question 11: What is the biggest risk in the way we have described this project, and what would you do to address it?

What you are looking for: a specific answer based on what you have shared, not a generic risk list. A vendor that has thought carefully about your project will name a specific risk — a third-party integration that is hard to predict, a compliance requirement that takes time, a platform capability that has to be tested across device models. A vendor that lists generic risks — "scope creep," "changing requirements" — is giving you a boilerplate answer.

Question 12: What happens to our engagement if a key person on your team leaves?

What you are looking for: a specific answer, not reassurance. "We would replace them within two weeks" is the start of an answer, not the whole one. How would the replacement ramp up? What documentation exists to make the handover possible? What is the notice period? A vendor that has not thought about this has not built the continuity process that protects you when it happens.

What the answers tell you

The questions above do not test what a vendor can build. They test whether the vendor has built the processes required to deliver at enterprise scale.

A vendor that can answer every question specifically and quickly has those processes. The answers are not rehearsed — they are descriptions of how the team actually operates. The specificity is the signal.

A vendor that answers vaguely, deflects to technical capability, or cannot produce examples of the things it describes — reports, release notes, risk documentation — has not built the processes the questions are probing for. The absence of the answer is the answer.

This set of questions takes about 45 minutes to run through in a vendor evaluation call. The output is a comparison that is independent of technical knowledge: a picture of how each vendor operates, what they do when things go wrong, and whether the team doing the work is the team being sold.

That comparison is reliable. The technical capability claims are harder to verify without specialist knowledge. The operational answers are not.