January 5, 2026·4 min read

Zero Third-Party Dependencies: When It's Worth It (and When It's Not)

Lessons learned from choosing zero dependencies for Inner Gallery vs Flutter's rich ecosystem for Coachy. The real decision criteria.

TL;DR

Zero third-party dependencies on Inner Gallery (security app = minimal attack surface). Dozens of packages on Coachy (collaborative app = development speed). The criterion: does the dependency touch what differentiates you?

Inner Gallery uses no third-party dependencies. No CocoaPods, no Swift Package Manager. Only native Apple frameworks -- Swift, SwiftUI, CryptoKit, Foundation.

"Why not an open-source encryption library?" For an app that protects its users' most private photos, I wanted a minimal attack surface.

The Real Criterion: The Level of Trust Required

The question isn't "should you avoid dependencies?" It's "what level of trust does your app demand?"

For Inner Gallery, an app that stores your most private photos, encrypted locally and never leaving your iPhone, the bar is high. Very high. I can't afford to have a flaw in a third-party lib compromise my users' photo vault.

The required level of trust determines your architecture.

For Coachy, my AI coaching app, I made the opposite choice. Flutter with dozens of packages: http, riverpod, json_annotation, flutter_secure_storage, etc. Why the difference?

Attack Surface vs Velocity

With Inner Gallery, every line of code I don't write myself expands the attack surface. The app handles critical encryption, stores private keys, manipulates ultra-sensitive data. The leftpad incident of 2016 stuck with me: 11 lines of JavaScript that broke half the internet.

More recently, the xz utils backdoor of 2024 showed that even the most basic tools can be compromised. Imagine if I had used a third-party compression library for Inner Gallery...

With Coachy, the context changes. The app syncs with a server, uses external APIs (Gemini), handles less critical data. Here, velocity wins. Flutter without its package ecosystem is like JavaScript without npm: technically possible, humanly masochistic.

What I Gained (and Lost) with Zero Deps

On the Inner Gallery side:

Total auditability: code I fully control
Guaranteed security: zero supply chain attacks possible, only Apple-audited frameworks
Native performance: CryptoKit leverages Apple Silicon hardware acceleration
Predictable maintenance: no surprise version bumps from a third-party lib

But also:

Less comfort: no third-party helpers for boilerplate, everything is hand-written
Discipline required: when a package solves your problem in 2 lines, resisting takes conviction

Signals That Justify Zero Deps

You should consider zero dependencies if:

Ultra-critical data: passwords, private keys, private photos
Minimal attack surface required: compliance, strict security audits
Total control necessary: critical performance, specific optimizations
Small and expert team: you can maintain custom code long-term

Zero dependencies is a luxury you pay for in development time. Make sure the security ROI is worth it.

When to Stay in the Ecosystem

For most apps, use the ecosystem:

Standard business apps: CRM, e-commerce, social networks
Rapid prototyping: MVP, idea validation
Commodity features: HTTP, JSON parsing, UI components
Growing teams: simpler onboarding with well-known libraries

With Coachy, I would never have finished in time by reimplementing Riverpod or HTTP requests. The coaching AI doesn't require the same security level as a photo vault.

My Rule of Thumb

I ask myself 3 questions:

What leaks if a dependency is compromised? Private photos vs coaching data
How much time do I have to ship? 6 months for Inner vs 3 months for an MVP
What expertise do I have in the domain? Crypto = expertise, JSON parsing = commodity

If the answers point toward "critical / plenty of time / expertise," then zero deps. Otherwise, ecosystem.