Your Mobile Vendor Says the Project Is on Track. How to Know If That Is True.

"On track" is the most common phrase in a mobile vendor's weekly update. It is also the least informative. On track against what schedule? On track as of when? On track according to whose assessment of the underlying work?

When every update says on track and a deadline is then missed, the problem is not that something unexpected happened. It is that the information system the vendor was running was not designed to surface risk — it was designed to manage it out of sight.

Why "on track" means nothing

"On track" is an assessment, not a fact. It describes the vendor's current belief about the project's trajectory — which is based on information the vendor has and the client does not. When that assessment is wrong, the client finds out when the deadline passes, not before.

The problem with purely status-based updates is structural. A vendor that summarises project status as "on track" is asking you to trust their assessment of their own work. That trust may be warranted. It may not be. Without access to the underlying data, you cannot tell.

The four data points below are observable without technical knowledge and do not depend on the vendor's assessment. They tell you what the delivery looks like in practice, independent of how the vendor characterises it.

What to look at instead

The release history. How many builds have been submitted to the App Store or Play Store in the last four weeks? A team shipping weekly will have four or more submissions. A team shipping biweekly will have two. A team that has not submitted a build in three weeks is not shipping. App Store submission history is recorded automatically — your vendor should be able to show it on request.

The ratio of completed to open work. Ask your vendor for a snapshot of the current project board: how many tickets are completed this sprint, how many are in progress, how many are blocked. You do not need to understand what each ticket contains. The ratio tells you whether work is moving or accumulating. A project board where 60 percent of tickets are perpetually in-progress without completing is a project in trouble, regardless of what the status update says.

The last time a risk was surfaced. Think back through the last four weeks of updates. Has the vendor mentioned anything at risk — a feature that might slip, an integration that is harder than expected, a dependency that has not responded? A vendor running a healthy risk process surfaces small risks frequently. A vendor that has nothing at risk, ever, is not looking for it.

Whether you have been asked for any decisions or inputs. A project that is genuinely progressing regularly requires client decisions: content approvals, design sign-offs, clarification on requirements, access to backend systems. A project where the vendor never asks you for anything is either unusually well-specified at the start — rare — or is operating without the client inputs it needs, which tends to surface as a problem when the deliverable arrives.

Four questions that cut through

Question 1: "Can you show me the last four App Store or Play Store submissions and their dates?"

This is the most direct observable test of release cadence. The data exists in the App Store Connect or Google Play Console accounts. If you have access to those accounts — and you should — you can look yourself. If you do not have access, ask why. App Store accounts should be in your name, not the vendor's.

Question 2: "What is at risk in the next two weeks, and what would you do if that risk materialised?"

This question does two things: it asks the vendor to look forward rather than report on what has already happened, and it asks what the contingency is, not just whether the risk exists. A vendor with a genuine risk process will answer specifically. A vendor without one will say "nothing is at risk" or give a vague answer about general project complexity.

Question 3: "How much of what was planned for this month has shipped versus how much is still in progress?"

This is a throughput question. It measures whether planned work is converting to shipped work on the cadence that was committed to. The answer should be expressed in a ratio — "seven of the ten planned features shipped, three are in progress and will complete next week" — not in a qualitative summary. If the vendor cannot give you this ratio, the project is not being managed against the plan.

Question 4: "What have you found in the last four weeks that you did not expect, and how did you handle it?"

Every mobile project encounters unexpected things: a third-party API that behaves differently than documented, a device model that exposes an edge case, a compliance requirement that adds work. A vendor that has encountered nothing unexpected in a month is either working on an unusually simple project or is not looking carefully enough. The answer to this question tells you whether the vendor is running a discovery process or executing against assumptions.

Reading the numbers yourself

Two data sources you can access directly, without relying on your vendor's assessment:

App Store Connect and Google Play Console. These platforms record every build submitted, every review status, and every live version. If you own the App Store accounts — and you should — you can see the submission history without asking the vendor. If the submission cadence does not match what the vendor is reporting, that discrepancy is worth raising immediately.

Crash reporting. If the app has crash reporting instrumented — Firebase Crashlytics is the standard — the data lives in an account. Ask for access to it if you do not already have it. Crash rate, session count, and the list of recent crashes are visible without any technical interpretation. A crash-free rate below 99 percent on a mature app is a quality problem. A crash-free rate that is declining week over week is a problem getting worse.

Both of these data sources are yours. They describe your product's performance. A vendor that is resistant to giving you access to data about your own product is managing information in a way that serves their interests, not yours.

What genuine on-track looks like

A vendor that is genuinely on track does not need to say so. The data makes it visible.

Builds are submitting on the committed cadence. The ratio of completed to in-progress work is moving in the right direction. The vendor is surfacing small risks regularly and resolving them before they become deadline problems. When something unexpected happens, you find out from the vendor before you find out from your users. The App Store accounts are in your name and the access is current.

A vendor in this position does not send updates that say "on track" without substance. They send updates that say "this shipped, this is at risk for the following reason, here is the contingency, and we need a decision on this by Thursday." The specificity is the evidence.

If your current vendor's updates read like the first description, ask the four questions above. The answers will tell you whether the project is as smooth as the status suggests, or whether the status is covering for something that has not been surfaced yet.