Mobile
Native Android in Kotlin and Java on the Jetpack stack, and Flutter when one codebase has to serve both stores. Offline behaviour, state that survives process death, and releases that ship on schedule.
I'm Rakesh — Principal Engineer, Application Development at Vanilla Transtechnor. 11+ years building native Android and Flutter clients, and 4+ years of the Python / FastAPI microservices they talk to. The same person designs the screen and the schema, so the contract between them actually holds.
Native Android in Kotlin and Java on the Jetpack stack, and Flutter when one codebase has to serve both stores. Offline behaviour, state that survives process death, and releases that ship on schedule.
Python and FastAPI microservices on AWS — async APIs, WebSocket channels, Kafka and SQS for everything that shouldn't happen in the request, containerised and deployed on Kubernetes.
Most engineers pick a side. I ended up on both — a decade of Android taught me exactly what a bad API feels like at 3G on a mid-range phone, and in 2022 I started building the services myself, which is how I stopped shipping those APIs to other people.
As Principal Engineer, Application Development, the work is mostly decisions: where a service boundary goes, what the client is allowed to assume, which things belong on a queue, and what the team can maintain after I've moved to the next thing. Architecture reviews, mentoring, and the unglamorous release plumbing that keeps both halves shipping.
What I'm actually selling is longevity. Anyone can ship a v1. The difference shows up in month eighteen — when a new requirement lands, and the system either absorbs it or fights back.
Kotlin and Java apps on Jetpack, with a codebase you can hand to any team. Performance, offline behaviour and Play Store releases handled end to end.
One codebase serving Android and iOS without the app feeling like a compromise on either — for when you need platform parity and a budget that stretches to one team.
Async REST and WebSocket APIs, split into microservices that stay independently deployable. Postgres and Redis underneath, Kafka and SQS for the work that belongs off the request path.
Service boundaries, API contracts, event flows and auth — plus the Docker, Kubernetes and CI/CD path that gets all of it to production repeatably. Architecture review and mentoring included.
Own application architecture across both halves of the product: Android and Flutter clients, and the Python/FastAPI microservices behind them on AWS. Service boundaries and API contracts, Kafka and SQS event flows, WebSocket delivery, Kubernetes and CI/CD — plus architecture review and mentoring for the engineers who maintain it.
Led mobile delivery across native Android and Flutter: architecture decisions, code review, release process, and the team practices that outlast any single project.
Client-side ownership across native Android and Flutter — feature architecture, code review, and the release process that carried each build to the stores.
Java and the Android SDK, alongside PHP/Laravel web projects — the years that everything since is built on, and where the backend half started.
Client and product names stay off this page. The problems don't — and the problems are the part worth hiring for.
Balances, top-ups and peer transfers, with a transaction history that has to reconcile to the last paisa. The interesting part is never the happy path — it's the timeout, the retry, and the user who taps “Send” twice.
Money moving between countries: recipients, live rates and fees, compliance checks, and a payout whose status keeps changing hours after the app was closed. Long-running state that the client has to render honestly.
Live support chat between customers and agents — routing and queueing, presence, delivery and read state, message ordering under reconnects, and push notifications for when the socket is gone.
Activity and workout tracking that has to keep counting with the screen off and the network gone, then reconcile cleanly when the phone comes back. Sensors, background work and battery, all pulling against each other.
Live face detection with OpenCV and Java — camera pipeline, frame processing and detection overlay. Public on GitHub, no NDA attached.
Internal tools, third-party integrations and services that can't be named here. I can walk through the architecture and the trade-offs in a call without going anywhere near a client name.
Tell me what you're building and where it's stuck. I reply to every serious enquiry, usually within a day.