Android app development languages — which one should be in the quote, and what's the difference?

If the built-in camera or integrated laser barcode scanner will run continuously, memory management becomes critical. Cross-platform frameworks can sometimes cause higher battery drain and latency on these specialized devices. Building natively in Kotlin is always more stable for field hardware like this.

Back in 2021, we didn't specify the language in our spec sheet, and the agency handed over a messy mix of legacy Java and a hybrid web view. Last year, when we wanted to update the barcode scanning module, all three developers we interviewed flat out refused to touch it. We had to pay to have it rewritten completely.

Don't sign any of these proposals right now. Send a written request asking: 'Which programming language, architecture pattern, and minimum Android SDK version will be used for this project?' and attach their written reply directly to the contract.

Keep the contract requirements crystal clear: 1) The programming language must be explicitly defined as Kotlin or an agreed-upon modern framework. 2) The architecture pattern must be specified as MVVM or an equivalent standard. 3) The agency must commit to delivering full, uncompiled source code in an independent repository.

Agencies just writing 'Android app' on quotes is such an annoying habit. Regardless of who you hire if things go south later you should be able to hand that code to another dev without them cringing.

if they write it in java itll work fine today but next year when u need to integrate new libraries good luck finding someone willing to touch it and get kotlin written into the agreement and save yourself the headache.

edit: typed from phone, sorry for typos.

What OS version are these handheld terminals running? Many industrial devices are stuck on older Android builds. Are you certain the libraries the agency plans to use support your specific device firmware?

If the agency is avoiding technical details, they're probably just trying to adapt an off-the-shelf template. An honest dev shop would proudly list their tech stack in the proposal anyway.

How did you solve this? When we decide without measuring, we always end up in the same place.

If acceptance criteria aren't written, when the work is done is open to debate.

I'm a small business, let me explain from my side. When we decide without measuring we always end up in the same place.

Implementing a change request process doesn't slow things down, it speeds them up.

Following.

I have an objection here. Solutions that work at a small scale collapse when you grow; I learned this late.

If you get three different answers on a topic, the question was asked wrong. Thats all, sorry if I went on too long.

There's a part I don't understand. The cheapest quote is usually the least thought-out one.

Correct me if I'm wrong.

You're right.

how did you solve this? trying to do this alone is the most expensive way.

when making a decision, first look at what data you have on hand and btw that's all, sorry if I went on too long.

I felt relieved reading this answer, so it's not just me. When making decisions, write down the worst-case scenario too, not just the best.

i'm curious too.

Let me speak from the other side; I'm on the supplier side. The system lives on after delivery; maintenance is a separate line item.

Proven by experience.