What to Expect in the First 90 Days With a New Mobile Development Vendor

The first 90 days with a new mobile vendor tell you more about the relationship than the next two years will. The patterns that define how the vendor operates - communication quality, delivery consistency, how they handle ambiguity - are all visible within the first three months. Most buyers do not know what they should be seeing.

A vendor who delivers exactly what was promised in the first 90 days, communicates clearly, and surfaces problems before they become delays has demonstrated the operational character of the engagement. A vendor who is late, vague, or reactive in the first 90 days will remain so. The pattern is the data.

What the first 30 days should look like

The first month is setup and context-building, not full-speed delivery. Expect a lower output velocity than you will see in months two and three. What matters is the quality of the foundation being laid.

By day 14: you should have met the actual delivery team - not the sales team, not the account manager, but the engineers and project lead who will own the work. You should have confirmed environment access, agreed on communication channels, and received a written summary of what the vendor observed in their initial codebase or requirements review.

By day 30: the vendor should have shipped something. It does not need to be a major feature. A bug fix, a performance improvement, a completed audit report - any shipped deliverable demonstrates that the team can navigate your environment and produce output. A vendor who reaches day 30 with no shipped deliverable and no clear explanation for why has a problem.

The architecture assessment is also a day-30 deliverable for any vendor inheriting an existing product. If they are taking over an app that has been running for two or more years, their assessment of what they found - the technical debt, the risk areas, the opportunities - is a mandatory input before committing to a delivery roadmap.

Days 31 to 60: the velocity test

The second month is where the delivery velocity should increase. The team has orientation behind them. They know the environment. The question is whether they can sustain a consistent shipping pace.

By day 45, you should have established a baseline: how many features or fixes are shipping per week, what the defect rate looks like on shipped work, and whether the roadmap commitments made at day 30 are being met on schedule.

The communication pattern in this period matters as much as the output. A vendor who is shipping but not communicating is managing the engagement reactively. You should be receiving weekly written updates without asking for them. Blockers should surface in the weekly update, not in an emergency call after a deadline has been missed.

Days 61 to 90: the pattern test

The third month confirms whether the behaviors in the first two months are the actual operating pattern or a ramp-up anomaly.

By day 90, the team should be operating at full velocity, communicating proactively, and handling the normal friction of a real engagement - scope questions, environment issues, external dependencies - without requiring significant management overhead from your side.

If the team is still requiring heavy direction at day 90, that is not a ramp-up issue. It is how the engagement will run.

Warning signs in the first 90 days

The delivery team is not who you met in the pitch. If the engineers on the engagement are different from the engineers who presented, ask why. A team swap in the first 30 days is a bench depth problem.

Updates only happen when you ask. A vendor who communicates reactively - who provides status only when prompted - will manage problems the same way. Reactive communication means you will learn about delays after they happen, not before.

Estimates shift without explanation. If the first delivery estimate was three weeks and it becomes five weeks without a documented reason, the estimation process is broken. Ask for the written breakdown of why the estimate changed.

The first deliverable has significant defect rate. Some defects in early releases are expected. A high defect rate on the first significant feature shipped - above 15 to 20 percent of acceptance criteria needing rework - indicates a quality process that is not functional.

What to do if things are off

Name it early. A direct conversation at day 30 or day 45 - "the communication pattern is not what we expected" or "the velocity is below what was projected" - is significantly easier than a conversation at month four or month six.

Most vendors will course-correct when the problem is named clearly and early. The ones who will not correct are the ones who defend the current state rather than acknowledge it.

A day-30 conversation that leads to a corrected engagement is a success. A day-90 conversation that leads to a vendor change is an expensive outcome that was avoidable.