What does a freelance Kotlin developer build?
A freelance Kotlin developer builds and maintains native Android apps: the code that runs directly on Google's platform with no translation layer in between. Kotlin has been Google's preferred language for Android since 2019, and most new Android libraries, samples and documentation are written with Kotlin first.
In day-to-day terms that means screens built in Jetpack Compose, background jobs handled with WorkManager and coroutines, local data stored in Room or DataStore, network calls through Retrofit or Ktor, and device features such as camera, Bluetooth and location accessed through Android's own APIs. It also means dealing with the Play Console: signing keys, release tracks, target SDK deadlines and policy declarations.
A good freelance Kotlin developer does something else as well: tells you when you do not need one. Many Indian business apps are catalogues, booking flows, dashboards and forms. For those, a single cross-platform codebase covering Android and iPhone is usually the better buy, and hiring native only makes sense when the app's core job is tied to the device.
- Native Android apps written in Kotlin
- Jetpack Compose user interfaces, or maintenance of XML-view screens
- Background work, sync, notifications and location within Android's rules
- Hardware links: Bluetooth, USB, NFC, camera, sensors
- Play Console releases, target SDK upgrades, crash and ANR fixes
When native Kotlin beats cross-platform
Native Kotlin wins when the most important feature of the app is something Android does, not something the user sees on a screen. If you imagine the app with all its screens stripped away and the key value is still there, going native is probably right.
Examples we would steer towards Kotlin: a billing app that prints receipts on a Bluetooth thermal printer at a shop counter; a field-sales app that must log visits with location all day on a budget phone without being killed by the battery saver; a scanner app processing camera frames in real time; an app with home-screen widgets that customers glance at more than they open the app; or an existing native app with years of Kotlin or Java code behind it.
Examples we would steer away from Kotlin: a restaurant ordering app, a coaching institute's course app, a society maintenance app or a clinic appointment app. They are screens plus an API, and customers on iPhone will want them too. Building them twice in native code costs more for no visible gain.
Go native when
Hardware is central, background work runs for hours, widgets matter, Android-only is permanent, or a native codebase already exists.
Go cross-platform when
The app is mostly screens and API calls, iPhone users matter now or soon, and budget needs to cover both stores.
Kotlin vs Flutter vs React Native for an Indian business app
For most business owners the decision comes down to two questions: will iPhone users matter, and how much of the app talks to the phone's hardware or runs in the background? Answer those and the stack chooses itself.
Flutter draws its own interface and reaches Android features through plugins. React Native drives native views from JavaScript and reaches features through modules. Both give you one codebase for two platforms. When a plugin is missing or unreliable, a developer writes a small native bridge, and that bridge on Android is written in Kotlin. So even cross-platform projects need someone comfortable in Kotlin for the hard ten percent.
Native Kotlin costs about the same as Flutter if the app is Android-only. It becomes the pricier route when you later want an iPhone app, because the interface must be rebuilt in Swift or shared through Kotlin Multiplatform. That future cost is the single biggest reason we ask about iOS plans on the very first call.
If you lean towards a shared codebase, compare React Native and hiring a Flutter developer.
Jetpack Compose or XML views: what a Kotlin freelancer should use
New screens should almost always be written in Jetpack Compose, Google's declarative UI toolkit for Android. Compose lets a developer describe what a screen should look like for a given state, and the toolkit redraws it when data changes. It reduces the glue code that made old Android screens hard to maintain.
Older apps built with XML layouts and Fragments do not need a full rewrite to benefit. Compose and XML views can live in the same app, so a sensible freelance Kotlin developer converts screens that change often or cause bugs, and leaves stable screens alone. A complete rewrite only makes sense when the old code blocks every change you want to make.
Ask any candidate how they manage state in Compose, how they avoid unnecessary recomposition on slow phones, and how they test screens. Specific answers about ViewModels, state hoisting and preview-driven development suggest real practice. Generic enthusiasm for “modern Android” does not.
How to vet a freelance Kotlin developer
Vet a freelance Kotlin developer on shipped Android work, not on language trivia. Ask for Play Store links, install the apps on your own phone, and see how they behave with poor network and after the phone has been idle for a while. Then ask what they would change about their own app. People who have shipped always have an answer.
Next, give a short paid task that mirrors your real problem. If your app prints receipts, ask for a small screen that connects to a Bluetooth printer. If it tracks location, ask for a background logger that survives a reboot. Watch how they handle permissions, errors and Android version differences.
Finally, read one piece of their code together on a call. You are looking for small, named functions, coroutines used with clear scopes, no secrets hard-coded in the app, and tests for the logic that matters. You do not need to understand every line to see whether it is tidy.
- Live Play Store apps you can install and test
- A paid task that matches your hardest feature
- Clear answers on permissions across Android versions
- Signing key and Play Console access handled in your name
- A plan for testing on low-RAM phones, not only flagships
Freelance Kotlin developer interview questions that reveal real experience
Language puzzles show whether someone has read Kotlin documentation. Android questions show whether they have fought the platform in production. Ask the second kind.
You are listening for trade-offs, not definitions. A strong freelance Kotlin developer will say things like “it depends on the Android version” and then explain which versions behave differently and why.
- How would you keep a location logger running all day without the phone killing it?
- What changed for background work and notification permissions in recent Android versions?
- How do you handle a Bluetooth device that disconnects mid-print?
- When would you keep an XML screen instead of rewriting it in Compose?
- How do you find and fix an ANR reported in Play Console?
- Where does the app signing key live, and what happens if it is lost?
- How would you share business logic with an iPhone app later?
Kotlin apps on Indian phones: budget devices, custom skins and data costs
Most Indian Android users are on budget and mid-range phones with limited RAM, and many run manufacturer skins that are aggressive about closing background apps to save battery. An app that behaves perfectly on a developer's flagship can stop syncing overnight on a customer's phone. Native Kotlin gives you the most control over this, but only if the developer tests on the phones your users carry.
We test on a spread of low-cost and mid-range devices, set up battery-optimisation guidance screens where background work matters, and keep the APK and app bundle lean. Android App Bundles let Google Play deliver only the code and resources each device needs, which helps users on limited data plans.
Language and payments matter too. Kotlin apps handle Hindi and regional scripts well with proper font and layout testing. UPI payments are typically started through an intent to the user's UPI app, and card payments go through a checkout provider's Android SDK; we do not tie you to any one provider.
Test on
At least one low-RAM phone, one mid-range phone from a brand with a heavy skin, and one recent Android version.
Measure
Cold start time, crash-free sessions and ANR rate in Play Console’s Android vitals after release.
How a freelance Kotlin developer project runs, week by week
A native Android build moves in short, testable steps, each ending with an APK or internal-testing build you can install. You should never wait weeks without something on your phone.
We start with the riskiest native feature first. If the whole app depends on a Bluetooth printer or all-day tracking, that piece is proven on real devices in the first sprint, before any polish. Screens, login, backend and admin come next. The last stretch is testing across devices, fixing what the internal testers find, and preparing the Play Store listing and data safety form.
Release happens through Play Console tracks: internal testing, then closed testing, then a staged production rollout. Note that new personal developer accounts on Google Play have to run a closed test with a minimum number of testers before production access, so we plan that time in when your account is new.
- Weeks 1–2: screen list, stack decision in writing, riskiest native feature proven
- Weeks 3–6: screens in Compose, backend and admin, offline handling
- Weeks 7–8: device testing, crash fixes, store listing and policy forms
- Weeks 9–10: closed testing, staged rollout, handover
Moving an old Java Android app to Kotlin
If you own an older Android app written in Java, you do not have to throw it away. Kotlin was designed to work alongside Java in the same project, so a freelance Kotlin developer can convert it gradually: new features in Kotlin, old files converted when they are touched, and stable code left alone.
The more urgent issue for old apps is usually Google Play's target API requirement. Each year Play raises the minimum target SDK level for app updates, and apps that fall behind cannot publish updates. Raising the target SDK often means dealing with new permission rules, notification permission prompts and background limits. That work is where a Kotlin freelancer spends most of the first weeks on a legacy app.
We read the codebase first and quote only after seeing it. A small, well-structured Java app may need modest changes; one full of deprecated libraries may need a larger clean-up before any new feature is safe to add.
Our migration work follows the same rule: read first, then quote.
Kotlin Multiplatform lets you write business logic once in Kotlin and use it on Android and iOS, while each platform keeps its own native interface. It is a middle path between fully native and fully cross-platform, and it has matured considerably, with Compose Multiplatform extending shared UI to iOS as well.
It makes most sense when you already have a native Kotlin Android app and now want an iPhone version without rewriting validation rules, pricing logic, data models and network code. The iOS screens can be native SwiftUI or shared Compose screens, depending on how much platform feel matters.
For a brand-new business app with no native requirements, Flutter or React Native is still the simpler choice for most small teams. We will lay out both options with rough effort for each, so you pick with numbers rather than trends.
Play Console, signing keys and code: what you must own
Your Android app should live in your own Google Play developer account, created with your business details. If a freelancer publishes your app from their account, moving it later is slow and depends on their cooperation. This is the single most important ownership point for any native app.
The app signing key matters just as much. With Play App Signing, Google holds the app signing key and your team holds an upload key. Keep the upload key and its passwords in a place you control, and make sure more than one person knows where. If the upload key is lost, it can be reset through Play Console support, but it takes time.
At handover you should receive the full source repository, build instructions, the upload key details, Firebase or backend access, and a list of any paid services the app uses. At BtechWaleTech everything is set up under your accounts from the start, with us added as users.
Red flags when hiring a Kotlin freelancer
The worst native Android hires are rarely bad at Kotlin. They are careless about accounts, testing and scope. Watch for these signs early.
One more warning: a freelancer who insists on native Kotlin for every app, even a simple catalogue, may be choosing the stack they prefer rather than the one you need. The reverse is also a warning: someone who says cross-platform can do everything has probably never shipped a hardware-heavy app.
- Wants to publish from their own Play Console account
- No live Play Store apps you can install
- Tests only on one expensive phone
- Cannot explain Android background limits or recent permission changes
- Keeps the signing key or backend credentials to themselves
- Recommends native Kotlin for every app regardless of need
- No written scope listing screens and native features
Worked example: a Kotlin app for a distribution business
This is a hypothetical example to show how the decision plays out. A packaged-foods distributor in Nagpur sends a dozen salespeople to retail shops every day. Each needs to log visits with location, take orders offline in areas with patchy signal, and print an order slip on a small Bluetooth printer at the counter.
On the first call the stack question is settled quickly: all salespeople use Android phones, iPhones are not planned, and the three core features are background location, offline storage and Bluetooth printing. That points to native Kotlin.
The first sprint proves printing and background logging on the actual phones the team carries, including one budget model with an aggressive battery saver. Only once those work are the order screens built in Compose, with Room storing orders offline and WorkManager syncing them when signal returns. A small web admin shows the day's visits on a map and exports orders to a sheet. The app is published from the distributor's own Play Console account.
- Android app from ₹40,000; web admin priced as its own line
- Riskiest features proven first on the team's own phones
- Two months of free maintenance after release, then optional support
Checklist before hiring a freelance Kotlin developer
Settle these points before work starts. Together they decide the stack, the budget and whether the app will still be yours in five years.
- Is the app's core value tied to hardware, background work or widgets?
- Will iPhone users matter in the next year or two?
- Numbered list of screens and native features
- Target phones listed, including budget models your users own
- Google Play developer account created in your business name
- Upload key and passwords stored where you control them
- Backend, admin and hosting in your accounts
- Payments in stages tied to builds you can install
- Plan for closed testing if your Play account is new
- Support period and monthly rate after it agreed in writing
For general app hiring steps, read how to hire an Android developer.
Freelance Kotlin developer for businesses across India
Native Android work is fully remote: builds reach your phone through internal testing tracks, and reviews happen on video calls and WhatsApp. Where the app talks to a specific printer or device, you send us the model name and we test with the same hardware or ask you to test a build on site.
We work with clients across India. City pages below describe local needs: logistics and distribution in Nagpur and Vijayawada, retail and trading in Surat and Kanpur, field services in Thane and Lucknow, manufacturing in Coimbatore and Indore, and growing businesses in Guwahati, Bhubaneswar and Mangaluru.