Shared core
How the work gets made
A shared core is a decision about what everyone has to agree on: the data, the rules, the review gate, the order the work moves in. The platform code at the edges stays small because the core settled it first.
Fleet management, US.
Software Engineer 2
- Motive Fleet App. Kotlin, Coroutines, Compose, and KMP business-logic modules under Clean Architecture.
- Bluetooth device-verification flows, CI/CD and workflow automation.
Three of the four gates on the home page have her on them, two of them hers alone. She writes the spec that says what the thing deliberately won't do, she runs the build on physical phones, and she reads what it collects and what the listing says about it before anyone outside sees either. At Motive she owns releases the same way: phased rollouts, crash and ANR monitoring, and CI/CD work so the path from merge to store is one a person can repeat. A studio selling "agents write it, humans review it" needs someone whose subject that already is, and the shared core is the same argument one layer down: agree the data, the rules and the order of the work once, and the platform code at the edges stays small enough to review.
Owns
- Spec
- code and design review
- device QA
- security and privacy
- ASO
- release cut.
Android
MotiveJetpack Compose migration, and the Android releases she owns: phased rollouts, crash and ANR monitoring.
Global bank.
Software Engineer
- Mobile banking. Migration to MVVM, UI performance work, and diagnosis of production issues.
Naskay Technologies
2020 – 2021
Mobile and product studio, Noida. Around 20 people, client work.
Android Intern
- Kotlin, Glide, Retrofit. A UI rebuild, APK size cut through code and resource work, and refactoring.
The four gates on the home page are this layout applied to a build: one core everyone agrees on, and edges small enough to review.