Mobile: dual-brand consumer platform

Batteries Included documents this case study to describe work completed before our consultancy was formed. 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 reputation: crashes, slow flows, and support drag had pushed public ratings to roughly three stars.

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.

One app, trust slipping in the store

The company had a single recognizable consumer app in the category. Instability was not an internal-only concern: public store ratings had fallen to roughly three stars, which in consumer apps directly affects discovery, trust, and install conversion. Support load and negative reviews clustered around crashes, slow launches, and flows that failed mid-session.

Leadership needed that app to behave like infrastructure: predictable releases, clear ownership when something breaks, and quality bars product and finance could plan around, not emergency firefights after every launch.

A second brand, without a second mobile rebuild

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 the second app matched the quality users already trusted on the first.

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.

Store ratings recovered on the first app

Reliability work connected directly to marketplace perception. Public store ratings on that app recovered from roughly three stars and, after the turnaround, stayed above four stars—the kind of floor consumer brands need when acquisition costs are high and alternatives are one tap away.

Dual flavors added for the second brand

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.

For a non-technical owner, the payoff is simple: you 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.

Trust recovered on the first app

Public ratings on the original app recovered from roughly three stars to a durable position above four stars, aligning mobile quality with what marketing and paid acquisition need to work. When the product stops fighting the store listing, growth spend works harder.

Second brand without doubling mobile cost

Adding a second flavor to the master codebase and launching the follow-on brand that way effectively cut the cost of that expansion in half relative to building and maintaining a fully separate second app. The savings show up as faster roadmaps, smaller regression surfaces, and fewer emergency releases to patch the same defect twice.