Ten years shipping Android at scale — Talabat from ~25 engineers to 10M+ installs, then five years at Floward owning architecture, CI/CD, QA and the entire release pipeline for a 1M+ install app. I take on mobile platform and release engineering: forty-minute builds, manual releases, test suites nobody trusts. Drengr is the tooling that came out of doing this for a decade.
Most mobile teams don't have a feature problem — they have a delivery problem. Forty-minute builds, a manual release checklist, a test suite nobody trusts, and a three-week cycle that should be three days. I spent five years owning exactly that at Floward: architecture, CI/CD, QA and the whole release pipeline for a 1M+ install app, as its highest code contributor.
To start a project, tell me what you want to build at engineering.drengr.dev.
For a decade, mobile tooling broke the same way: bound to the framework, shattered by the next UI change. Drengr is the clean break. One framework-blind capture core, two products. 0-code analytics that reads your app's real traffic and behavior and names your business events by itself (no tracking plan, no data team). And eyes and hands for AI: an actuation layer agents drive from what's on the screen, not a fragile UI tree. It covers what nothing else can: native, Flutter, React Native, web-views, and games alike.
Native, Flutter, React Native, web-views, games — it reads the rendered screen, so nothing's off-limits.
Drop in the SDK. Drengr captures real traffic and behavior, redacts PII on-device, and discovers and names your business events itself.
An actuation layer agents drive to observe and operate live apps — no selectors, no XPath, nothing brittle.
For about ten years I built Android apps. I was genuinely thrilled when I first found Espresso — a framework from Google, deeply integrated with the SDK, that could simulate real user behaviour. I wrote hundreds of tests. Then reality set in. Tests passed locally and failed on CI over animation timing. Tests that worked on a Pixel broke on a Samsung. A designer moved a button into a BottomSheet and forty tests turned red overnight — none of them testing that button. I spent more time maintaining the suite than it ever saved me. I moved through Appium, UIAutomator, Maestro — each a refinement of the same idea: match elements by ID or XPath, and break the moment the UI evolves.
If Espresso — Google's best — was the ceiling, the problem wasn't the implementation. It was the entire approach.
Joined when the tech team was ~25 people; grew with the company as it scaled into one of MENA's largest food-delivery platforms — later part of Delivery Hero. Built core UI and business logic; introduced in-app analytics and A/B testing; helped lead the move to Kotlin.
Staff Android engineer for a gifting platform across the Middle East and the UK, contributing across Android and Flutter. Own architecture, CI/CD, and release pipelines. Highest code contributor in their GitHub to date.
Building a framework-blind mobile-analytics and AI-actuation platform — eyes and hands for AI on any app. Rust core, native SDKs, ClickHouse analytics. Model: subscriptions + SDK.
M.Tech, Computer Engineering — CUSAT, India (2014). Based in Dubai, UAE.
I architect and review; AI agents write much of the first draft. Ten years of production judgement is what makes that safe. It's how one engineer ships a Rust core, native Android, iOS and Flutter SDKs, and a ClickHouse pipeline at a scope that would conventionally need a team.
Drengr is what I'm building. I also take contract work on mobile platform and release engineering, and I'm open to Staff / Lead mobile roles.
sharminsirajudeen11@gmail.com ↗