Cleaner

Cleaner was not designed as a collection of unrelated utilities. We organized the product around three everyday questions:

Whether the phone had enough space?

Whether it could continue running smoothly?

Whether it was protected from security threats?

The product treated performance and security as separate user needs. Performance tools addressed slowdown, battery drain and heat. Antivirus provided a separate layer of protection against viruses, risky applications and privacy threats.

The logic was similar to caring for a person.

Make room. When our surroundings become crowded with things we no longer need, clearing them away makes us feel lighter and gives us room to breathe.

Recover. When we feel drained or under physical strain, we need to rest, cool down and regain our energy before returning to our normal rhythm.

Get a check-up. Some health risks are difficult to notice from the outside. Seeing a doctor helps us uncover problems early and stay protected.

Many users relied on 32GB or 64GB phones, where storage pressure was immediate. Cache cleaning helped, but large files and accumulated photos often occupied far more space.

We expanded cleaning beyond temporary cache and built dedicated paths for large files and photos. Before deletion, users could understand what was taking up space, review the files themselves and decide what should be removed.

Users of large-file cleanup recovered 1.8GB on average. For people using phones with limited storage, this was a result they could immediately understand and use.

It also established a simple product standard: cleaning should help users confidently reclaim meaningful space, rather than treating all personal files as junk or using exaggerated numbers to create a sense of effectiveness.

Freeing storage did not solve every problem. Users also experienced slowdown, battery drain, heat and security risks they could not easily see.

Utility products often placed these needs under a single “optimize” button, making different problems look as though they could all be solved in the same way.

I organized these capabilities into two complementary areas: performance maintenance and security protection.

We grouped speed boost, battery saver and CPU cooling as performance maintenance. Each flow used simple state feedback to help users understand what the tool was trying to address, without overstating the technical effect.

Antivirus was treated separately, more like a health check than another optimization animation. We first used a limited version to verify demand, then expanded its scope to identify viruses, risky apps and privacy threats.

Performance and security both attracted clear user interest, but they required different product standards.

Performance tools should help users understand the condition being addressed. Security tools must clearly state what they can identify and should never rely on fear to create value.

Cleaner tasks were usually brief. Users completed an action and left, so repeat access mattered. Result pages often ended the flow too early, while persistent toolbars and push improved access at the cost of possible interruption.

The toolbar also presented a genuine trade-off. Enabling it by default improved discovery but required uninterested users to turn it off. Keeping it off reduced interruption but made the shortcut harder to discover.

I compared two activation models: default-on with user opt-out, and default-off with contextual prompts.

I introduced the toolbar after cleaning, boost or battery-saving tasks, with frequency controls that did not block the current action.

Connected result pages helped users move into related tools more naturally. The toolbar experiment exposed the cost on both sides: default-on supported discovery and reactivation, while default-off gave users more control but weakened reach.

The conclusion was not that one default was always better. Persistent access should be judged by both distribution and interruption, with activation tied more closely to context and the choice kept easy to reverse.

Inside SnapTube, Cleaner benefited from an existing audience and product context. A standalone app had to earn the install, communicate its value quickly and pass Google Play review on its own.

The task was not to copy every existing tool into a new package. The product needed a clear reason to exist outside SnapTube.

We kept the standalone product focused on core cleaning scenarios and handled compatibility issues before launch. I learned Google Play policies early and worked with the team to respond quickly to review issues.

Traffic from SnapTube targeted users likely to have cleaning needs and avoided blocking their current task.

Super Cleaner passed one million downloads within two months of launching on Google Play, with 44% next-day retention.

SnapTube distribution provided the starting point, so the result should not be understood as pure organic growth. It showed that an in-app utility could support a standalone product when its core promise, first-use experience and distribution path were designed together.