Agency recommended separate languages for iOS and Android — how does development stack affect the budget?

Bluetooth mobile printers and barcode scanning work seamlessly via native bridges on modern cross-platform setups. Zero lag at the hardware layer. The agency pushing separate languages usually just means their dev team doesn't know cross-platform tech.

We made the exact same mistake across our wholesale distribution network 3 years ago and went full native. Paid 240,000 TL. Every single Android update or iOS policy tweak meant paying revision invoices twice over. Switched to a single codebase last year, and our monthly maintenance bill dropped from 18,000 TL down to 8,500 TL.

The agency probably has separate iOS and Android devs sitting idle and they're trying to bill their man-hours to your project. 90% of enterprise sales apps ship on a single codebase these days.

Before signing any contract, make sure to ask them: 1) What operational screen do they guarantee will open faster compared to a single codebase? 2) What is the exact scope of the annual maintenance SLA for two separate codebases? 3) Who retains full ownership of the source code for both platforms once the project wraps?

Before committing 340,000 TL, take that same exact spec sheet to two other agencies that build cross-platform. You'll watch that quote drop down to roughly 190,000 TL with a 6-week turnaround.

Do your sales reps in the field go into warehouses with no cell service? If offline database sync is required the architecture matters a bit more, but even that isn't something that can't be solved with a single codebase.

Building native apps in two separate languages for a B2B app that just displays a catalog and scans barcodes is literally throwing money down the drain.

Thanks a lot I'll try it today. Start with a small trial; don't commit to everything at once.

Just leaving this note it might be useful.

The opposite happened to me, that's why I'm writing. Weekly written progress reports are much more useful than asking for dates.

Let me clarify the technical side. The cheapest quote is usually the least thought-out one.

If I were you, I'd go this route.

my questions are cleared up, thanks. when making a decision, first look at what data you have on hand.

Let me summarize the topic, since several different answers were given. The answer varies greatly by industry; there is no one-size-fits-all rule.

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

Here's how it went for us. Most time waste accumulates in tasks waiting for approval.

If you post the result here, it will help others too.

i went through the same thing.

I completely agree. People defend habits, not processes. Resistance comes from there.

Processes without records never improve, because you don't know what to fix. That's all sorry if I went on too long.

I have a question, don't want to go off-topic though. If scope grows either time or budget must grow. There is no third option.

Hope this helps.

Let me share my experience. When making decisions, write down the worst-case scenario too, not just the best.

Start with a small trial; don't commit to everything at once.

Thanks for posting.