The Context
LancerPay was positioned as a lightweight freelancer product, so app size was not a cosmetic concern. A larger binary would directly conflict with the promise of speed and simplicity, especially for users on limited storage or unreliable connectivity.
The Problem
As the product scope expanded to include SQLite-based local storage, PDF generation, reminder workflows, biometric locking, and branded assets, the Expo app started trending toward unnecessary bulk. The risk was clear: a supposedly lightweight freelancer tool could become harder to install, slower to distribute during QA, and more expensive to maintain as features accumulated.
The Approach
The solution was to treat build size as a product constraint, not just a technical cleanup task. Each dependency, asset class, and native capability was reviewed based on whether it meaningfully improved the user experience relative to the cost it added to the final build.
Dependency Audit First
Large libraries were reviewed for overlap, especially where a narrow utility could replace a broad package with unused surface area.
Asset Compression and Scope Control
Images, onboarding visuals, and exported resources were optimized so the app shipped only what was necessary for the core experience.
Feature Gatekeeping
Nice-to-have capabilities such as heavier media or advanced native integrations were delayed unless they supported the MVP directly.
