The Dependency Audit Every Founder Should Demand From Their Dev Shop

A typical modern mobile app ships with somewhere between 200 and 800 third-party dependencies — open-source libraries, vendor SDKs, transitive dependencies pulled in by other dependencies. The founder has never seen the list. The agency that built the app may not have the full list either. Some of those dependencies are excellent. Some are abandoned. A few are security risks. None of them have been audited unless someone deliberately decided to audit them.

SEM Nexus runs a dependency audit at v1 and a quarterly refresh on retainer clients. This isn't sexy work, and it doesn't sell well in agency pitches — but it's one of the more responsible practices a serious dev shop should do. This post is what the audit looks like and why every founder should demand it.

What's actually in your dependency tree

When you ship a Flutter app, you ship:

• The Flutter SDK and Dart standard library
• Every Pub package your code directly imports
• Every package those packages import (transitive dependencies)
• Native iOS and Android dependencies pulled in via Pods + Gradle

For a real production app, the count adds up fast. A modest Flutter app we audited recently had 412 total dependencies across direct + transitive. The founder thought it had "around 20."

React Native is similar. Native iOS/Android, despite being closer to the metal, still pulls in significant numbers via Pods, Carthage, or Swift Package Manager.

Every one of those dependencies is code running in your app. Code your team didn't write. Code that can have bugs, abandonment, or security vulnerabilities.

What the audit looks for

Five categories of risk:

1. Abandoned dependencies

A package whose last commit was 3+ years ago, or whose primary maintainer has clearly moved on, is a risk. When iOS 19 changes something, no one will update it. When a security vulnerability is found, no one will patch it.

We grade dependencies on activity: commits in the last 6 months, open issues with no responses, the maintainer's other public work. Abandoned packages get flagged for replacement.

2. Security vulnerabilities

CVE databases track known vulnerabilities in open-source packages. Most package managers integrate with these — npm audit, flutter pub outdated, etc. The audit isn't just running the tool; it's reviewing the output and acting on it.

We catch transitive vulnerabilities (vulnerable packages pulled in by other packages) that the founder's direct dependencies hide. These are the ones that bite hardest in surprise security incidents.

3. License compliance

Some open-source licenses (GPL, AGPL) have copyleft requirements that may not match the founder's commercialization plans. MIT, Apache 2.0, BSD are usually fine. A surprise GPL dependency in a closed-source mobile app is a real legal problem.

We surface every license in the dependency tree and flag anything that conflicts with the founder's intended distribution model.

4. Heavy / unused dependencies

A 30MB package pulled in for one utility function is dead weight. We surface dependencies that aren't materially used and recommend lighter alternatives or removal.

This matters for app binary size, which matters for App Store conversion (users skip large apps), startup time, and runtime memory.

5. Risk concentration

When 30% of your app's functionality depends on one third-party vendor's SDK, that vendor's outage / acquisition / pricing change is your problem. We flag risk concentration so the founder can decide whether to accept it or reduce it.

Want the audit run on your existing project? SEM Nexus offers dependency audits as a standalone engagement for founders who inherited a build from a prior agency and want to know what's actually in it.

When the audit runs in a SEM Nexus build

Three times:

At v1 sprint zero. Before the build commits to a stack, we audit the proposed core dependencies. Anything risky gets surfaced and an alternative chosen.

At v1 launch. The full transitive dependency tree gets audited. The audit results are documented and shared with the founder as a one-page summary.

Quarterly on retainer clients. Every 90 days, the audit re-runs. Dependencies change. New vulnerabilities are reported. New maintainer issues surface. The quarterly cadence catches them before they become incidents.

A real audit finding

On one client engagement, the quarterly audit surfaced that an image-processing library the founder's prior dev shop had pulled in for v1 had:

• Last commit 4 years ago
• 18 open issues including 2 mentioning crashes on iOS 17+
• A transitive dependency on a library with a known CVE
• Was used by exactly 1 screen of the app for exactly 1 effect

We replaced it with a maintained 12KB library that did the same job. The audit took 45 minutes. The replacement took half a sprint. The crash risk + CVE risk + binary bloat all disappeared together. The founder wouldn't have known to look.

Why most agencies skip this

Three reasons:

It doesn't show up on the sprint report. Sprints get measured in features shipped. Dependency audits ship no features. Agencies optimizing for visible velocity skip the work.

It's senior engineering work. Junior engineers can't reliably grade dependencies. The audit needs a senior reviewing each finding. Senior time is scarce.

Founders rarely ask for it. And what isn't asked for, isn't delivered, in pre-PMF agency engagements where every line item is contested.

SEM Nexus does it anyway because the cost of not doing it shows up much later, in production incidents that surprise the founder. We'd rather prevent surprises.

What the founder should demand

Three concrete asks of any agency:

1. "At launch, will you provide a one-page dependency audit summary?" Includes total count, activity grades, license summary, and any flagged risks. Should fit on one page.
2. "How do you handle CVE alerts post-launch?" A retainer client should expect proactive monitoring; a build-only client should at least know what they're getting (often: nothing, unless they ask).
3. "How will dependencies be transitioned when we take the build in-house?" Clean documentation should accompany the handoff so the in-house team isn't inheriting a mystery box.

If the agency can't answer all three with specifics, the dependency tree of your shipped app is probably already an issue you don't know about.

What this signals about engineering maturity

The dependency audit isn't a flashy feature. It doesn't sell well on a cold call. Its presence in an agency's standard practice is a signal that the agency thinks about the project past launch day.

Agencies optimizing for the one-time build don't audit dependencies. Agencies treating the build as a multi-year engagement do. SEM Nexus operates in the second category — most of our clients stay on retainer through the first year of production, and the quarterly audit is part of why that retainer is worth its cost.

If you'd like a build done by an agency that treats your dependency tree as your dependency tree — not a sunk cost they walk away from at launch — SEM Nexus's retainer engagements include the audit cadence. The work is invisible when it goes well, and very visible when it doesn't. We'd rather invest in the invisible version.