Four ways to start
Each block is a number of engineering days delivered inside a fixed window, scoped in writing before it begins. The range depends on the size of your codebase; you get an exact figure after the call.
Codebase audit Start here
A written assessment of your Android codebase: what will break next, what is costing you velocity, and what I would fix first. No code, no commitment beyond the week.
Play compliance sprint
Target SDK bump, edge-to-edge, 16 KB page alignment, deprecated APIs, and a clean Play Console before the next deadline.
Compose migration
Hands-on migration of the screens or modules we agree on, with the patterns documented so your team can carry on without me.
Kotlin Multiplatform pilot
One domain (networking, data, or business logic) extracted into a shared module and consumed by your existing iOS app, working alongside your iOS engineer.
Work outside these shapes is £600 per engineering day. Agencies and studios: I take white-label subcontract work on the same terms, under your client relationship.
How it works
No procurement, no onboarding, no standing meetings.
-
A 20 minute call
You describe the problem. I ask what has been put off, and what happens if it stays put off.
-
A scope within 48 hours
One page: what I will deliver, what I will not, the timeline, and the price.
-
The work, with one checkpoint
A working demo and a written status at the midpoint, so there is a decision point before the last day.
-
Handover and invoice
What changed, what to watch, and what I would do next if the codebase were mine.
If the first two days show this is not a fit, we stop and you pay for those two days only.
What I get called in for
Usually the work a small team knows it needs and keeps pushing to next quarter.
Release and compliance
Your Android engineer has left
Someone has to keep the release going while you hire. I can hold it, or hand the next engineer a codebase they can start in.
Target SDK 36 and Play compliance
Deadline work: API level bumps, deprecated permissions, policy warnings cleared before the listing is at risk.
Release pipeline and build times
Signing, staged rollouts, Play Console automation, and Gradle builds that finish before people stop paying attention.
R8 and ProGuard
Shrink failures, missing keep rules, and the crashes that only ever happen in release builds.
Performance and quality
Crashes and ANRs
Getting the crash-free rate back up, including the ANR that only ever reproduces on a cheap device in someone else's hands.
Startup time, jank and memory
Profiling first, then fixing what the trace actually blames rather than what everyone assumes.
Edge-to-edge and insets
Including the awkward version: legacy Activity stacks and mixed View and Compose screens, not just clean single-Activity apps.
Accessibility
TalkBack, contrast, touch targets and focus order, plus the evidence trail for when a customer or a procurement team asks.
Platform and architecture
SDK and library work
API surface design, versioning, and binary compatibility checks so an update never quietly breaks a consumer.
Kotlin Multiplatform
Shared modules for networking, data or business logic, consumed by the iOS app you already have rather than a rewrite.
Compose migration
Moving off Views and Fragments incrementally, with the patterns written down so your team can carry on without me.
Architecture review and due diligence
An outside read on a codebase, for your own planning or for an investor asking harder questions than usual.
What I don't do
Open-ended staff augmentation, and fixed-price commitments beyond six weeks. If that is what you need, I will say so on the call and point you somewhere better.
Who you are working with
I am Nebil Seid. I have spent eight years building Android apps and have shipped more than ten to production, consumer and B2B, most of it as the only Android engineer in the room at startups and scale-ups. That means I have owned everything from architecture to the Play Console listing.
Much of that has been on codebases where a bad release is expensive and one change has to land safely across several downstream products at once. The habits that come from that, an API surface you cannot casually break and a migration path that strands nobody, are the ones I bring to everything else: features, migrations, performance work and the unglamorous release plumbing in between.
Aya Tech is based in London and works remotely with teams across the UK and Europe. I do the engineering myself. For Kotlin Multiplatform work I can bring in an iOS engineer I have worked with for years, if your side does not have one. Code lands in your repository as it is written and the reasoning gets documented as we go, so nothing depends on me still being around next quarter.