Agency said "both iOS and Android with Flutter" — will this lock me in later?

Minor visual glitches can occasionally happen with iOS updates when the rendering engine or OS components change. Definitely make sure to add a clause to the proposal stating they will provide compatibility update support for at least 1 year whenever major iOS versions are released.

We launched our logistics tracking app with Flutter last year. Instead of hiring two separate native teams, we spent 210,000 TL with a single team. We have 12,000 active users right now, and only 2 complaints were about UI stutter, which turned out to be on very old devices.

Most agencies pitch 'two platforms, one codebase' to cut costs, but they never even look at the iOS Human Interface Guidelines. If you end up with an iOS app that feels like Android the second you open it, your iPhone users will immediately leave bad reviews.

Ask the agency for at least three Flutter apps they've already published on the App Store. Download them to your own iPhone and check the list scrolling speed, keyboard show/hide responsiveness, and transition animations yourself.

Will your field technicians need to work offline? Have you asked them how they plan to handle local data storage and sync logic? The real bottleneck is usually local database synchronization not the UI.

weve been using it for two years with zero issues. going native wouldve at least doubled that budget, totally unnecessary early on.

Edit: asked below, I wrote the answer in the second message.

Having to switch to native in the future doesn't mean the app failed; quite the opposite, it means your business grew significantly. When that day comes you'll already have the revenue to fund a rewrite anyway, focus on gaining traction for now.

Going native means ditching the front-end code, but your backend architecture stays intact; 280,000 TL is a very reasonable test budget for taking that risk.

Let me speak from the other side; I'm on the supplier side. The answer varies greatly by industry; there is no one-size-fits-all rule.

I'm also curious if anyone does it differently.

i completely agree but any unwritten clause becomes a point of disagreement later as both sides remember it differently.

thats all sorry if I went on too long.

I'll try it.

You're right, I've been down that road too. Payment schedules should be tied to project phases, not calendar dates.

If code ownership isn't in the contract, you have no bargaining power when leaving. If I were you, I'd go this route.

Theres a trap here, let me mention it. honestly mistakes made on the flutter for ios development side are usually reversible but expensive.

Generally correct, but one part is missing. If it's your first time, start small; scaling comes later.

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

I agree, and I'd like to emphasize that. Trying to do this alone is the most expensive way.

Proven by experience.

The opposite happened to me that's why I'm writing. If it's your first time start small; scaling comes later.

The cheapest quote is usually the least thought-out one.

I went through the same thing... Don't hesitate to ask; those who don't ask always pay more.

When making decisions write down the worst-case scenario too, not just the best. That's all sorry if I went on too long.

Exactly like that. Access credentials should be opened in the company's name, not personal accounts.

If scope grows, either time or budget must grow. There is no third option. If I were you, I'd go this route.