Dual-brand consumer platform

As Android engineer on a major B2C consumer platform, the work started with one consumer app in the store—not a dual-brand portfolio on day one. The first priority was reliability and store presence: leadership wanted predictable releases, stronger quality bars, and public ratings that supported acquisition—not a constant cycle of reactive fixes.

Separately, the company added a second consumer brand in the same category. The follow-on engineering was to add dual-flavor support to the existing master codebase: keep one shared implementation for core product behavior, isolate brand-specific packaging, and ship the second store listing without building a second app from scratch.

The company had a single recognizable consumer app in the category. Store ratings and retention mattered for discovery and paid acquisition, so mobile quality was treated as a growth lever—not only an engineering backlog item. The goal was a more dependable experience users could recommend and re-open.

Leadership wanted that app to behave like infrastructure: predictable releases, clear ownership when issues surfaced, and quality bars product and finance could plan around.

The company also wanted a second brand with its own listing, marketing story, and support expectations. The risk was treating that as a greenfield rewrite: doubled feature cost, doubled regression surface, and months before a second app could reach the same level of polish and feature parity.

Accounts, safety tooling, notifications, and the flows that turn a download into a paying relationship were largely the same behind the scenes. The business question was how to add a second store presence without building and maintaining two separate apps.

Reliability and release work connected directly to marketplace perception. Public store ratings on that app moved from roughly 3 stars to above 4 stars and held there—the kind of floor consumer brands need when acquisition costs are high and alternatives are one tap away.

To ship the second brand without a from-scratch rebuild, dual-flavor support was added to the existing master codebase: one shared implementation for core product behavior, with brand-specific layers for identity, store listings, configuration, and the parts of the experience that must feel distinct in the market.

Shared work (core domain logic, messaging, account lifecycle, safety paths, and the release train) lives in one place. Brand-specific work (visual identity, copy, store assets, and go-to-market packaging) stays isolated so the second brand could launch without a parallel rewrite.

Stabilize one product users already download, then publish a second store listing from the same engineering system instead of building two separate apps from scratch.

Public ratings on the original app moved from roughly 3 stars to a durable position above 4 stars, aligning mobile quality with what marketing and paid acquisition need to work. When mobile quality supports the listing, growth spend works harder.

Adding a second flavor to the master codebase and launching the follow-on brand that way avoided the cost of building and maintaining a fully separate second app. The savings show up as faster roadmaps, a smaller regression surface, and one release train for shared product work.