Google Androidify

Prototyping selfies into Android mascots

01 · The Challenge

Google wanted to give people an Android mascot that looked like them. The core question: could a generative system deliver personalised output at scale while preserving the Android character's distinctive visual grammar?

The client had already seen fine-tuning's potential in a prior project. This prototype needed to demonstrate that brand integrity and personalisation could coexist — and that the technology was ready to deliver.

02 · The System

A two-phase pipeline.

Phase 1 — Extraction. A vision-language model reads a selfie and extracts clothing, colour, accessories, and hairstyle into a typed JSON schema. The extraction vocabulary was co-designed alongside the training dataset captions, so the schema and the model share a language.

Phase 2 — Generation. A fine-tuned image model trained on Android character data generates a mascot from that schema. The schema acts as an interface contract between two independently developed models.

A parallel pipeline handled dataset prep, LoRA fine-tuning, and iterative testing. An evaluator stage for brand-reference validation was scoped but not implemented — the prototype was about proving feasibility, not building a production system.

03 · The Decisions

The hardest problem was applying personalised clothing to the mascot without destabilising the base character. Generating the full mascot from scratch caused clothing attributes to bleed into the character's form — the Android Bot stopped looking like itself.

The solution was masked regional generation: establish a neutral-coloured base Bot, then constrain generation to specific regions for clothing, preserving the character's structure underneath. This treats the mascot as a stable substrate rather than a fully generative output — an architectural choice that kept the brand's visual grammar intact while allowing personalisation to sit on top.

04 · The Complexity

This prototype was simultaneously a pitch and a proof of concept.

The audience included R/GA's global CTO, VP Creative Technology, and a key technical leader — people who could assess both the technical architecture and the commercial implications.

Imagen 3 was under strict confidentiality at the time. Direct evaluation wasn't possible, so the case for fine-tuning capability had to be made without demonstrating it on the actual model. The submission was convincing enough to negotiate access — the prototype unlocked the resource.

GCP compute infrastructure raised an unresolved scalability question around production cost modelling. A prototype can prove technical feasibility; proving economic feasibility requires different instrumentation.

05 · The Evidence

Over one week, I produced a preliminary system architecture and a structured evaluation framework across four models: SDXL, Flux.1 Schnell, SD 1.5 + ELLA, and Imagen 3.

Evaluation prioritised prompt adherence first (does the output match the clothing description?) and style fidelity second (does it look like an Android character?). Both were assessed manually against reference Droids — brand fit doesn't reduce to a metric.

ComfyUI was the testing environment for four approaches: pure prompt with fine-tuned model (LoRA/DoRA), masked regional generation, and ControlNet. Avatar outputs documented how each technique handled clothing transfer to the character.

06 · My Contribution

Sole technical lead on the prototype. Designed the two-phase pipeline, extraction schema, and masked generation approach for clothing. Ran model evaluation across all four candidates. Collaborated with 3D artists building the fine-tuning corpus for SDXL using AI Toolkit. Built and presented the feasibility case to R/GA leadership. GCP ComfyUI infrastructure was set up with a senior technical director during the prototype phase.

Collaborators

R/GA: Katrina Bekessy, Nick Coronges