Solo: Android Across a White-Label Food Platform
I worked in Solo's shared Kotlin and XML codebase, shipping Android features and production fixes used by multiple restaurant-branded apps.
[delivery dossier] 2 sections
It wasn't one restaurant app
Solo supplied a white-label food-ordering platform used by multiple restaurant brands. I worked in the shared Android codebase, which used Kotlin, XML layouts, and Retrofit for API calls. Brand identity and some behavior varied, but a lot of the ordering experience came from the same underlying implementation.
That made a normal production fix less local than it first appeared. Before changing shared code, I had to trace whether the problem came from the base implementation, a brand configuration, or an API assumption. A condition added for the app in front of me could quietly become behavior for several other apps.
How I handled changes
I added Android features and fixed production issues in the shared codebase. I traced each change through the ordering and API paths, then kept it in the narrowest layer that owned the behavior. Where brand-specific behavior was already configurable, I used that mechanism instead of creating another one.
Some modules were old and shared broadly, so a small, reviewable change was often safer than a wide migration. That mattered when one code path could affect several branded builds.
The public developer catalogue shows the breadth of the product family. My work sat in the shared Android platform behind those variants, where one feature or production fix had to behave across more than one restaurant brand.