Signs Your Mobile Development Vendor Is Becoming a Second Job for Your Engineering Lead

Two hours. That is the threshold. If your VP Engineering spends more than two hours a week managing your outsourced mobile vendor — chasing status, writing specifications the vendor should own, reviewing decisions the team should make without escalation — the vendor is not a vendor. They are a workstream you are staffing from inside your own leadership team.

Wednesday tracks time-to-independence across every enterprise mobile engagement. The median for a well-run transition is 18 days. By week four, the team ships without supervision. If your current vendor has been running for six months and your engineering lead is still in the daily loop, the model is broken — and the cost of that broken model does not appear on any invoice.

The two-hour threshold

Two hours per week is not an arbitrary number. It is the time a VP Engineering should spend on any single vendor relationship to run it well: a structured weekly sync, async review of the prior week's output, and any genuine escalation that required leadership judgment.

Everything beyond two hours is spillover — work the vendor should own that has migrated to your team because the vendor cannot run it independently. Specification writing. Ticket grooming. Decision-making on choices the engineering team should resolve at their level. Status updates that require chasing.

The spillover is invisible in a budget review because it does not appear as a line item. It shows up as a VP Engineering who is stretched, a product roadmap that moves slowly despite adequate spend, and a general sense that the outsourced team is adding complexity rather than removing it.

Measure it this way: ask your VP Engineering to track time spent on vendor-related work for two weeks. Not just the sync calls. Every Slack thread, every ticket rewrite, every decision that came upstairs because the vendor could not resolve it at their level. The number is usually higher than expected.

Four signs the vendor is running on your time

Sign one: your engineering lead writes the tickets.

A self-managing mobile team takes high-level requirements — a feature brief, a product spec, a user story — and translates them into actionable engineering tasks independently. If your VP Engineering or product manager is writing detailed tickets, breaking down work, and estimating effort for the vendor's engineers, your team is doing the vendor's program management for them.

The vendor's job is to take requirements and return working software. The translation step in between is theirs to own.

Sign two: status updates arrive on request, not proactively.

A vendor running a well-managed engagement sends status before you ask. Weekly: what shipped, what is in progress, what is blocked, and what decisions are needed from your side. If you are sending "any update on X?" messages, the vendor's communication cadence is not calibrated to your accountability needs.

This matters because a VP Engineering who has to chase status cannot trust the information they receive when they get it. They spend mental bandwidth monitoring the relationship instead of directing it.

Sign three: bugs reach users that a test process should catch.

Every release from an outsourced mobile team should clear a test gate before it reaches users. Automated regression testing, screenshot comparison, device coverage on the platforms your users actually run. If your support queue fills after releases, if app ratings dip after updates, if your engineering lead spends time on post-release bug triage — the vendor's QA process is transferring risk to your users instead of absorbing it.

Sign four: decisions come upstairs that should not.

Technology choices, testing approach, architecture trade-offs within an agreed scope — these are decisions a competent mobile team makes without involving your VP Engineering. If the vendor is regularly escalating choices that a senior engineer should own, they are either understaffed at the senior level or lack the confidence to operate independently. Either way, the deficit is being filled by your team.

What a self-managing team looks like

India's largest exam prep platform — a $400M revenue edtech business with five million students — hired Wednesday to augment their mobile engineering team. Their bar for hiring was high. Their internal team was strong but grew slowly. The roadmap could not wait.

The Director of Product's requirement was direct: a partner who could be handed work and trusted to deliver it without becoming a second job for engineering leadership.

Wednesday embedded with the product and engineering teams on day one. The team took high-level requirements and translated them into specifications independently. Weekly delivery cycles ran without status chasing. The engineering leadership did not review daily output or make decisions the team should own. The engagement ran for 12 months. Zero missed deadlines. Scope grew — the platform gave Wednesday more projects over time, not fewer.

The clearest signal of what self-managing looks like: Wednesday was handed the platform's NPS system — one of only two internal services that every other service in the platform's ecosystem depends on. That level of trust does not come from a vendor that needs managing. It comes from a team that has earned it by operating without supervision from the start.

How to measure your current vendor

Four questions to answer before any vendor conversation:

How many hours per week does your VP Engineering spend on vendor-related work? Include sync calls, async communication, ticket writing, decision escalations, and post-release issue resolution. Anything below two hours is healthy. Anything above four is a structural problem.

What percentage of releases required a post-release fix in the last 90 days? Pull the last 12 releases. Count the ones that required a hotfix or rollback within seven days of going live. Above 20% means the QA gate is not working. Above 35% means the QA gate does not exist in a meaningful form.

When was the last time the vendor proactively flagged a problem before you asked? A self-managing team surfaces blockers and risks before they become escalations. If you are always the one who finds the problem first, the vendor is reactive by design.

Who writes the detailed specifications? If your product manager or VP Engineering is the person who turns a feature idea into actionable engineering tasks, the vendor is missing program management capability. That capability should be theirs to provide, not yours to supply.

The switching decision

Most enterprises stay with an underperforming vendor longer than they should because the switching cost feels high. It is not as high as it feels.

A structured mobile vendor transition takes 18 to 25 days of parallel running: the new team onboards, reviews documentation, runs a structured handoff with the outgoing vendor, and ships independently before the prior team exits. Wednesday's median across 2025 enterprise transitions was 18 days from signed agreement to the new team running without supervision.

The calculation is straightforward: add your monthly vendor invoice to the undeclared management cost (VP Engineering hours multiplied by fully-loaded hourly rate). Compare that total to what a self-managing team costs. The management cost alone often closes most of the gap between your current vendor and a better one.

The second calculation: what is each month of the current situation costing in roadmap delay? Features that do not ship have a real cost — competitive lag, board confidence, and the compounding effect of a product that falls further behind every quarter the velocity gap persists.

If your VP Engineering is spending four or more hours per week managing the vendor, and the release cadence is slower than your roadmap requires, both numbers are telling you the same thing.