Hire a Kotlin Developer Directly
One developer, one contract, nobody in between. Message me today and the person who answers is the person who writes your Kotlin, submits the build to Google Play and is still reachable six months later. No agency layer, no account manager, no junior swapped in after the pitch — just a fixed quote, an installable build every two weeks, and full ownership of the code at the end.
Every app below was scoped on a call with the client and written by the same person who took that call — no agency in the middle, no team you never met. Native Android in Kotlin where the platform matters, Kotlin Multiplatform where a second store genuinely pays for itself. All of them shipped to the store and all of them are still running.
See the full portfolio
Talk today, hire today
Consulting- $20
Before you commit to anything, we talk — and the call is with the developer, not with someone whose job is to get you to sign. Thirty minutes costs $20: enough to keep the calendar honest, small enough that it is never the reason you hesitate. Slots usually open the same day, so you can talk and hire today rather than waiting on an agency to route your enquiry to whoever is free next month. I scope your app, tell you honestly whether Kotlin native, Kotlin Multiplatform or something else entirely fits what you are building, and hand you a plan you can act on with me or without me. Most people arrive with a feature list about twice the size of what a first release needs, and the fastest way to save real money is to find that out before anyone opens Android Studio. If we go on to work together, the $20 comes off your first invoice.
Talk to me today — 30 minutes for $20Send the idea, a rough feature list and the deadline you are working to. A few sentences is enough — no brief to fill in, no form routed to a sales team, and the reply comes from me.
Consulting is $20 per 30 minutes, usually bookable the same day. In that half hour I cover what your app actually needs, whether Kotlin native or Multiplatform fits, what it will cost, and which features are safe to cut from version one — developer to client, no intermediary.
You leave with a written scope and a fixed quote that is yours to keep, whether you hire me or not. Say yes and the build starts the same week, on one contract, with no third party attached. The $20 comes off your first invoice.
Pricing
Anyone who quotes your app before hearing what it does is guessing. A Kotlin developer on a marketplace might list $20 an hour and a European agency will bill $120 for the same job title, and neither number tells you what your build costs — because the hours are decided by your feature list, not by the rate card. Hiring direct removes one whole layer from that number: no agency margin, no recruiter percentage, no marketplace commission skimmed off the top of every hour. You pay for engineering time and nothing else.
What actually moves the number: how many screens genuinely ship in version one, whether you need Android only or shared Kotlin Multiplatform code for iOS too, how much design already exists, and how deep the backend has to go. Payments, offline sync and real-time updates each add real engineering time. So does anything touching money, personal data or a third-party system you do not control, because those parts have to be tested far harder than a screen that only displays information.
The quiet costs are where most quotes go wrong. Play Store submission and the data-safety declarations, push notifications, analytics and crash reporting, an admin panel so you can change your own content, and the servers underneath it all. None of it is expensive alone, but leaving it out of an estimate is exactly how a project ends up over budget in month three. I quote fixed prices per milestone, directly to you, so the number you approve is the number you pay — and when you want to know why a line costs what it does, you are asking the person who priced it.
About Me
There is no sales team here, no account manager relaying your words, and no junior quietly assigned to your project after the pitch. The person answering your first message is the person whose name ends up on every commit, and the quote you get comes from the developer who has to meet it. I write in this journal about the craft of shipping Android software — the trade-offs, the decisions that cost money later, and the small wins that make the work worth doing.
More about me
Hiring directly means the technical answers come from the person doing the work, so here is what that person actually writes. Kotlin is what I use nearly every day, and it has been my production language for four years — not a framework I picked up for a portfolio piece. That means coroutines and Flow for anything asynchronous instead of a callback pyramid, sealed classes and exhaustive `when` blocks so an unhandled state fails at compile time rather than in a crash report, and Jetpack Compose for the UI unless a project has a good reason to stay on XML views. Null safety is the quiet one people underrate: a whole category of production crash simply stops existing when the type system refuses to let you ignore it.
The work goes well past the screens. Room and DataStore for offline-first data so the app still opens on the metro, WorkManager for background sync that survives a reboot without draining the battery, Hilt for dependency injection that keeps modules testable, and Retrofit or Ktor against whatever backend you have. Then the parts nobody demos: R8 rules that do not strip the wrong class in release, baseline profiles so the first launch is not the slowest one, StrictMode and LeakCanary during development, and ANR and crash dashboards wired in before launch rather than after the one-star reviews arrive.
Working direct also changes what you own at the end. You get a codebase another developer can pick up cold: clear module boundaries, readable commits, unit tests on the logic that matters, and a signed release build you can ship yourself. Keystore, Play Console access, source and documentation are handed over in your name at the end of every project — not held by a studio, not sitting in an agency's account. If you decide to bring the work in-house or hire someone else next year, nothing about the way I write Kotlin, or the way we contract, is designed to make that hard.
Android Studio
Kotlin
Jetpack Compose
Gradle
Firebase
Figma
Git & GitHub
Postman
Workspace
When you hire directly you know exactly where the work happens: a quiet desk, a Mac, a second screen and a drawer of real Android devices — including the slow, three-year-old ones your users actually own. Everything on it exists to shorten the gap between you asking for a change and seeing that change running on a real phone.
The emulator is fine for layout work and lies about everything else: jank, battery, camera behaviour, the way a mid-range device handles a cold start. Physical devices catch those before your users do. And because the Mac signs iOS builds too, a Kotlin Multiplatform project ships both sides from one desk — no subcontractor, no third-party handoff, no week lost because the person with the build machine works for someone else.
What I Offer
Strategy, design, development and launch, handled by one developer who stays accountable for the result. Nothing is subcontracted, nothing is passed to a partner studio, and you are never routed between an account manager, a designer you never speak to and a team in another timezone. The person who scopes your project is the person who writes the Kotlin, submits the build to Google Play and answers the phone six months later when you want a new feature. That means fewer things lost in translation, honest answers about what a change really costs, and one point of contact from the first message to the release build — plus source code, documentation and store accounts that belong to you at the end.
See all servicesKotlin, the way the platform intends.
Production Android apps written in idiomatic Kotlin: coroutines and Flow for concurrency, sealed classes for state that cannot silently go wrong, Room and DataStore for offline-first storage, WorkManager for background sync that survives a reboot. Built on a clear MVVM or MVI structure with Hilt wiring it together, so the codebase still makes sense to whoever opens it in two years.
Declarative screens, fewer bugs.
Compose UI built from a real component library rather than a pile of one-off screens — including the states most mockups skip: empty lists, slow connections, failed payments, long names in small spaces. Material 3 theming with dark mode from day one, proper accessibility semantics, and recomposition kept under control so scrolling stays smooth on the mid-range phone your users actually own.
Share the logic, not the compromises.
When iOS genuinely matters, KMP shares the expensive part — networking, data models, validation, business rules — while each platform keeps its own native UI. You get one source of truth for the logic and an iOS app that still feels like an iOS app. I will also tell you when KMP is the wrong call, because for a single-platform MVP it usually is.
The part users never see.
REST and GraphQL APIs, authentication, roles and permissions, payment integrations, file storage and the database schema underneath. Written in Ktor when the stack should stay Kotlin end to end, or Laravel when your team already lives there. The parts touching money and personal data get tested hard, because those are the ones that cost the most when they break.
From release build to live listing.
Submission is where a lot of first projects stall, so I handle it end to end: signing keys and Play App Signing, release tracks, the data-safety form, target API level requirements, screenshots, store copy, and the review notes that come back asking for one more change. I ship the build, answer the reviewers, and hand you the Play Console and keystore afterwards so the listing is genuinely yours.
Inherited a codebase that scares you?
A paid audit of a few days on an existing Kotlin or Java Android project, ending in an honest recommendation: continue, refactor or rebuild — with the reasoning written down so you can get a second opinion. Then the actual work: migrating Java to Kotlin, moving XML views to Compose incrementally, untangling a God activity, or getting a stalled build back into the store.
Watch before you hire
Actual screens from shipped Kotlin apps rather than stock mockups, the Figma prototype that let a client change their mind before anything was coded, and the moment a build lands on a real device and something obvious turns out to be wrong. That part is normal, and watching how it gets handled tells you more about working directly with a developer than any agency portfolio can.
It also covers the ending, which most third parties stay quiet about: exactly what lands in your account on launch day. Source code, documentation, the signing keystore and the Play Console listing, all in your name. No slides, no pitch, no jargon — a few minutes of the work as it actually happens, so you can decide whether this is how you want your own project to run before you send a single message.
3 min watch Process walkthrough Recorded 2024
3:04
How I Work
Four predictable steps — discovery, design, development, delivery — and the same person at every one of them, so you always know where the project stands and who to ask. Most of the stress in a software project does not come from the code; it comes from silence, from not knowing whether the thing you paid for is on track or quietly falling apart. So the process is built around visibility instead of surprises. You get an installable build at the end of every sprint, not a status report, and every stage ends with something concrete in your hands: a written scope, a clickable prototype, an APK on your own phone, a live store listing. If something needs to change, the cheapest moment to say so is early — which is exactly why half this process happens before a line of production Kotlin is written.
Step 01
We map the problem, the users and the budget before anyone mentions a library, and you do it with the developer rather than a salesperson taking notes. I ask what the app has to do on day one and what can wait for version two, because that single distinction moves the price more than any architecture choice ever will. Most people arrive with a feature list roughly twice the size of what a first release needs, and finding that out on a call costs nothing. You leave with a written scope and a fixed quote that is yours to keep, whether you hire me or not.
Step 02
Wireframes and user flows become a clickable Figma prototype you open on your own phone and tap through before a line of production Kotlin exists. This is the cheapest possible moment to change your mind, so we use it properly: screens get reordered, steps get cut, and things that felt obvious in conversation get tested against how they actually feel in the hand. The states most mockups skip get designed here too — empty, loading, offline, error.
Step 03
Development runs in two-week sprints, and every sprint ends with an APK you can install and use rather than a status report you have to trust. You see progress on a real device while there is still time and budget to react to it. Between sprints you get a short written update covering what shipped, what is next, and anything that turned out harder than expected. Nothing is hidden until the end, because problems found in month two are cheap and problems found in month five are not.
Step 04
I handle Play Store submission end to end: signing, release tracks, data-safety declarations, screenshots, store copy and the review notes that come back. Crash reporting and analytics go in before launch, not after, so the first week of real users tells you something useful. Afterwards there is a support window for defects, and the keystore, source, documentation and store accounts are transferred into your name with no lock-in.
The direct working agreement
One contract, between you and the developer, written down before the first sprint so nobody has to guess who owns what when a deadline gets close. Almost every project that goes badly does so for the same reason: two people each assumed the other was handling something, and by the time anyone noticed, a week was gone. So we settle it up front — who writes the copy, who supplies logos and brand assets, who owns the Play Console and Apple accounts, who signs off a design before it gets built, and how long a review should take before the build moves on without it. None of this is legal padding; it is the short list of things that quietly stall real projects. You keep full ownership of the code, the accounts and the data throughout, and I stay accountable for the parts that need a developer. If something falls outside what we agreed, you hear about it when it comes up rather than in an invoice at the end.
Direct vs third parties
An agency sells you a senior team and staffs your project with whoever is free that month. A marketplace inserts itself between you and the developer, takes a cut of every hour and owns the conversation. A recruiter charges a fee to introduce you to someone you could have messaged yourself. Hire directly and all of that disappears: you get the person whose name is on the commits, and the difference shows up everywhere once the work is running — in how fast a question gets answered, in whether the estimate came from the person who has to meet it, and in what happens when something turns out harder than anyone expected. This does not make agencies wrong for everyone. A fifty-screen product with three integrations and a compliance audit needs more than one pair of hands, and I will tell you if that is what you have. But most first Android apps are not that. They are a focused idea that needs someone competent to build it properly in Kotlin, ship it to Google Play and stay reachable afterwards — and that work does not get better by adding people between you and the code.
Pay for the build, not the layers
No agency overhead, no recruiter fee, no marketplace commission, no payroll tax, no share of an office you will never visit. A studio has to bill your project for account managers, sales staff and the gap between the developers they employ and the developers who are free this month. Hire direct and you pay one person for the hours that go into your app, which is usually a fraction of an agency quote for identical scope.
Days, not hiring quarters
Hiring an in-house Kotlin developer means job posts, screening, notice periods and onboarding — realistically a quarter before anyone writes a line of your code. An agency books you into a slot that opens next month, after two calls with people who will not build anything. Direct, you talk to the developer today, get a quote tomorrow and start the same week, which matters when your idea has a season, a funding round or a competitor attached to it.
The person writing the Kotlin
You message the developer, not an account manager relaying your words to someone you have never met. Nothing gets lost in translation, nobody quotes a change without knowing what it touches, and there is no meeting to schedule a meeting. When you ask how long something takes, the answer comes from the person who has to live with the estimate — and it comes back the same day.
Match the work to the month
Add hours when a launch is close and pause when it is not, without a redundancy conversation or a contract renegotiation. Software demand is lumpy — a heavy build, a quiet stretch of small fixes, then a burst before a release. Paying a full-time Android salary through the quiet months is how budgets get eaten by nothing in particular.
Overlapping your working day
Working hours that overlap the whole European day and most of the US morning, so a question sent before lunch is answered before you finish it. Offshore teams twelve hours out turn every clarification into a lost day, and three lost days a week quietly becomes a month over the life of a project.
No lock-in, no third-party accounts
Source code, repositories, signing keystore, Play Console, design files and documentation all transfer to you, in your name, at the end of the project — never registered under an agency that then holds the keys. You are never in the position of needing permission to move your own product, and any competent Kotlin developer can pick it up after me, which is the point. Work you cannot leave is not work you own.
Client Reviews
These are people who hired me directly, paid for the work, sat through the awkward middle of a build and shipped something at the end of it. Read them for the specifics rather than the adjectives — the deadline that held, the brief that was understood without three rounds of clarification, the developer who answered the message himself and was still reachable after launch. Those are the things you are actually buying when you hire a Kotlin developer without a third party in the way, and they are what I would check first if I were the one writing the cheque.
4.9 out of 5 from 27 client reviews
France
Figma design in line with project specifications. Vision well understood.
Hong Kong
Zakaria was helpful and mindful of deadline... can't wait to work with him again!
United Kingdom
Very professional, extremely hard working and goes way beyond.
Common questions
These come up on almost every first call, so they are answered here in full rather than left for you to ask — by the developer, not by a marketing team. Most of them are really the same question underneath — what am I committing to, and what happens if this goes wrong — which is a fair thing to want settled before sending money to someone you found in a search result. The answers below are the same ones you would get on a call, including the less flattering parts: what a build actually costs, where timelines slip, and when a project should not go ahead at all.
It means one contract between you and the person writing the code. No agency reselling my hours, no recruiter taking a placement fee, no marketplace sitting between us and taking a cut of every invoice, and no subcontractor you were never told about. You message me, you talk to me, you hire me, and the same person builds the app, submits it to Google Play and answers you afterwards. Practically, that shows up as faster answers, quotes from the person who has to meet them, and accounts registered in your name rather than a studio's.
Usually, yes. Messages come straight to my inbox and WhatsApp, and I answer within 24 hours — often within a couple of hours during the European working day. If a call slot is free we talk the same day, and if the scope is clear you can have a written quote that evening and a contract signed before the week is out. There is no procurement queue, no discovery workshop to schedule, and nobody who has to check with a manager before giving you a number.
Not for this. Clients here contract with me directly, which is what keeps the price honest and the communication short. I do take white-label work for agencies occasionally, but that is a different arrangement and it is never how a direct client is billed — you are not quietly paying an intermediary. If you found me through a platform, we can still move the contract direct, and if you would prefer an escrow arrangement for the first milestone that is fine too.
Rates run from roughly $20 an hour on freelance marketplaces to $100–150 an hour at a European or US agency, and the rate is the least useful number in that sentence. Hiring direct at least removes the part you get nothing for: the agency margin, the recruiter fee and the platform commission. What you pay is hours multiplied by rate, and the hours come from your feature list. A focused Android MVP in Kotlin typically lands in the low thousands; a product with payments, chat, offline sync and an admin panel is a different order of magnitude. I quote fixed prices per milestone after a scoping call, so you approve a number before work starts rather than watching an hourly meter.
Kotlin, without hesitation. It has been Google's preferred Android language since 2019, the modern Jetpack libraries and Compose are designed Kotlin-first, and null safety alone removes an entire category of production crash. Java still runs fine and interoperates cleanly, so an existing Java codebase does not need throwing away — new code goes in Kotlin and the two live side by side. But starting a new Android project in Java in 2026 means writing more code to get less, and hiring for it gets harder every year.
KMP lets you write your business logic, networking and data models once and share them between Android and iOS, while each platform keeps its own native UI. It is genuinely good technology and it is not free: you take on more build complexity, and you still need someone who understands both platforms. If you are shipping Android only for now, skip it — you can adopt KMP later without a rewrite. If both stores matter from day one and the app is logic-heavy, it usually costs meaningfully less than two separate native builds. I will tell you which case you are in on the call.
Ask for a Play Store link, not a portfolio screenshot — anyone can show a mockup, far fewer have shipped and maintained a live app. Then ask what they would cut from your feature list and why; a developer who agrees with everything you say has not thought about your project. Ask who owns the code and store accounts at the end, and how you would hand the project to someone else. The answers to those three questions tell you more than any technical quiz you could run.
Compose for anything new. It is less code, the state handling is far harder to get subtly wrong, and previews shorten the design feedback loop considerably. For an existing XML codebase I do not propose a big-bang rewrite — Compose and Views interoperate, so new screens get built in Compose and old ones migrate when they are being touched anyway. That keeps the migration inside work you were already paying for instead of becoming a project of its own.
Small builds ship in three to five weeks. A full product with a backend, payments and an admin panel usually runs eight to fourteen weeks, split into two-week sprints with an installable build at the end of each. Play Store review adds a few days on top and occasionally more if the reviewer wants a change. Those are real ranges from shipped work, not best-case numbers — if your project does not fit them, you will hear that during scoping rather than in week nine.
Often, yes. I start with a paid audit of a few days — building it, reading the architecture, checking test coverage and dependency age — and then give you an honest recommendation: continue, refactor, or rebuild, with the reasoning written down so you can get a second opinion. Roughly half the projects I take on started somewhere else. A rescue is usually cheaper than a rebuild, but not always, and pretending otherwise helps nobody.
Yes, and hiring direct is part of why that is simple. Repositories, design files, the signing keystore, Play Console access and any credentials are yours and transfer to you on final payment, with no third party holding an account in the middle. There is no licence fee, no hosting you are locked into and no proprietary framework that only I can maintain. The code is written so another Kotlin developer can pick it up without a handover call, because that is what ownership actually means.
They are reasonable choices for content-driven apps that must look identical on both stores. Native Kotlin wins when the app leans on the platform — camera and media, Bluetooth, background work, widgets, deep system integration, or performance that has to hold on cheap hardware. It also wins on day-one support for new Android releases, where cross-platform frameworks wait for a plugin to catch up. I recommend based on what your product needs, and I will say so if native is not the right answer for you.
A shared channel on Slack or WhatsApp for daily questions, a short written summary each week covering what shipped and what is next, and a call whenever a decision needs one. Every one of those is with the developer writing the code — there is no account manager in the thread, no ticket queue, and nothing gets relayed second-hand. Time zone overlap covers the European working day and most of the US morning.
Work splits into milestones with a payment attached to each, so you are never more than one stage ahead of what has been delivered. A deposit reserves the slot, then each payment follows a milestone you have seen running on your own device and approved. No hourly invoices arriving with numbers you have no way to check.
Every project includes a support window for defects. After that you can move to a monthly retainer covering new features, Android version updates, dependency and target-API bumps that Google mandates each year, and crash monitoring — or take the code fully in-house. There is no obligation either way, and the handover is the same regardless of which you choose.
Talk today, start this week
Three steps between the idea in your head and a signed build in the Play Store, with no third party in any of them. The first takes about five minutes of your time, and none of them commit you to anything before you have seen a scope and a price in writing.
You do not need a specification, a designer, a technical co-founder or an agency to translate for you. A paragraph describing what the app should do is enough for me to tell you what it takes to build in Kotlin, what it should cost, and which parts are worth cutting from a first release — usually the same day you send it.
No third parties
Tell me what you are building. The message comes straight to me, and you get a reply within a day with a clear next step — no sales call, no lead form passed to an agency, no gatekeeper.
Direct channels
Email or WhatsApp reach me directly — same inbox, same person, same day. Nobody screens these messages before I see them.
Email contact@expertappdeveloper.com WhatsApp +212 631 189 491 Response time Within 24 hoursCurrently
Taking on two new projects this quarter — talk and hire today
A paragraph is enough to start. The more you can say about what the app does and who it is for, the more useful my first reply will be.
From the journal
Anything I learn on a project that seems worth writing down ends up here, usually within a week of learning it. Not tutorials rewritten from the Android docs, and not opinion pieces about which architecture won this year — notes on the decisions that actually cost money: when Kotlin Multiplatform is the wrong call, what offline-first really involves once sync conflicts show up, why Play review rejected a build that worked perfectly in testing, how to read a quote from a development agency. Some posts are for founders trying to understand what they are buying and some are for developers solving the problem I solved last month. Both are written for the person who has to make a decision today rather than for a search engine.
Read the journal
AI Coding
Vibe coding can build a working app in one afternoon. But is it safe for real users? Here is a simple, step-by-step way to check AI-written code, plus free tools, a checklist, and a real bug fix, before you launch.
Business
Business
Productivity
Development
Artificial Intelligence
