Android Lead Engineering
Senior Android lead for established products.
Port from iOS, replatform off a fragile codebase, rebuild from scratch, or run as the sole senior on an existing team. I take the Android side end-to-end.
What you get
One senior owning the surface
You get a single senior who can architect, build, and ship the Android side end-to-end. No coordination overhead, no junior + tech-lead pair-up.
Architecture that survives after I leave
Clean Architecture or MVVM with explicit layers, dependency-injection, tests on the bridge and the domain. The next engineer can take it.
Ship in slices, not big-bang flips
Vertical slices ship continuously. Each slice is independently mergeable so the Android side stays deployable from week 2 onward.
Recent lead engagements
Three engagement shapes
The three patterns that cover the lead engagements I take on. Each anchors to a real case study; the audit in week 1 confirms which shape fits your codebase.
How a lead engagement runs
Vertical slices, not horizontal layers. Each slice is independently mergeable so the Android side stays deployable from week 2 onward, and you can pause the engagement at any slice boundary without leaving half-shipped state.
- 1
Week 1
Codebase audit
I read the existing Android codebase end-to-end before proposing anything. Identify what is domain, what is platform glue, what is dead code, what is fragile. The audit output is a concrete recommendation on the boundary: what stays, what gets replaced, what gets scaffolded fresh.
- 2
Weeks 2-3
Architecture + scaffolding
Lay the Clean Architecture or MVVM skeleton the rebuild will run on, plus the test seam, the DI graph, the CI workflow. Existing screens keep shipping; the new layers slot in next to them.
- 3
Weeks 4+
Feature work in slices
One vertical slice at a time: a single user-visible feature ported, refactored, or built; the Compose UI written; the integration test added. Each slice is independently mergeable. No big-bang flag-flip at the end.
- 4
Final week
Hand-off + drift guards
Documentation in the repo, not in a PDF. CI checks that catch contract or architecture drift before it ships. A runbook for the next engineer covering the build, the test seams, and the conventions that keep the architecture from rotting.
When this fits, when it doesn't
A clean read on whether this engagement is the right shape for what you need, with deep links to the alternatives when it isn't.
| When this fits | When it doesn't |
|---|---|
| Existing Android product, debt-heavy or no senior on team | True greenfield startup with no product yet — see /services/fractional-cto |
| Rebuild, replatform, or sole-senior ownership | Strict cross-platform port from iOS, Rust, or web — see /services/android-parity |
| Multi-month engagement, architecture survives after I leave | Short-burst code review or audit — see /services/code-review |
| You want one senior to own the surface | You want me to manage a junior + tech-lead pair-up |
Cross-platform port
Bringing iOS, Rust, or web to native Android?
The Android Parity engagement covers strict cross-platform port work: JNI bridges, Kotlin Multiplatform, or wire-contract rewrites.
See Android ParityBroader Android Dev
Embedding with an existing Android team?
The Android Development page covers Kotlin migration, MVVM, performance, and architecture work that slots into an existing team rather than running as sole senior.
See Android DevelopmentQuestions about Android Lead
How is this different from /services/android-parity?
Android Parity is the strict cross-platform port: bringing an existing iOS, Rust, or web product to native Android. Android Lead is broader: rebuilds of existing Android, replatforms off fragile code, sole-senior ownership on greenfield or established teams. If your source product is on a different platform, start at Android Parity. If your product is already on Android (or starting on Android) and you need senior ownership, start here.
How is this different from /services/android (Android Development)?
The Android Development page is the broader services menu: Kotlin migration, MVVM, code refactoring, performance optimization, embedding with an existing Android team. This page is the lead-engineer engagement specifically: I am the senior owning the Android side end-to-end, not slotting into a team as one of several engineers.
Do you require an existing team or can you go solo?
Either. Many of my engagements run as sole senior Android engineer for the duration; some run with me leading and a junior or two on the team. The deciding factor is whether the long-term maintenance needs more than one Android person; if the answer is no, sole-senior is the cheaper and cleaner shape.
What does an engagement cost?
Scoped per engagement. A rebuild with a defined endpoint runs on a fixed-scope sprint (see /services/scalable-mvp for the shape). A multi-month or open-ended lead engagement runs on a Builder retainer (see /services/fractional-cto for the tier shape). The audit step is always paid + fixed-scope so you have a real recommendation before committing.
What if my existing codebase is in really bad shape?
The Da Vinci Eye engagement started on a ChatGPT-built codebase with no architecture and a tight budget that ruled out a clean-room rewrite. The pattern: navigate around the existing code while replacing the load-bearing layer (in that case the OpenGL + AR pipeline), then document the rest as a refactor guide the client team can apply incrementally. Bad shape is usually a sequencing question, not a stop sign.
Ready to talk?
Start with a free 15-minute discovery call. No commitment, no pitch deck, just an honest conversation about your problem and how I can help.