Context
During the BrightMinds launch we debated whether minifying HTML/CSS/JS would 'protect' the IP. Instead of arguing, I built a pipeline that showed the trade-offs in numbers.
Threats
- Public repos expose the entire UI stack.
- Unminified bundles slowed First Paint on budget phones.
- Stakeholders risked assuming minification equals security.
Approach
- Added html-minifier-terser, clean-css, and esbuild to the pipeline, producing hashed assets and 70% smaller payloads.
- Created an npm script + GitHub Action that fails builds when bundle budgets regress.
- Documented why security relies on keeping secrets server-side, not on obfuscation, and recommended SSR/token moves for future roadmaps.
- Benchmarked performance gains with WebPageTest so non-technical stakeholders saw objective wins.
Outcome
Static assets shrank ~70%, mobile FCP improved by 320 ms, and leadership finally internalized that minification is an optimization tactic — not a lock. The documentation became our template for future client conversations about frontend exposure.
Lessons Learned
Deliver the optimization, but also teach the boundary. Showing data is more persuasive than debating hypotheticals.