Choosing mobile app development tools together — how do you decide with a partner?

Last year on a similar logistics app, stubbornness around going native stretched our 6-month delivery window to 11 months. A budget we initially pegged at 220,000 TL blew past 410,000 TL. Cross-platform rarely causes friction with hardware integrations these days; juggling two separate codebases on a lean budget is a luxury you can't afford.

The critical technical detail here is the bluetooth listeners running in the background and the camera-based barcode reading latency. In cross-platform libraries, the native bridge latency is at the millisecond level, below human perception for warehouse operations. Just prepare a small prototype and measure the camera frame rate, your partner will be convinced once they see the numbers.

we had the same fight too dragged on for 4 months. then instead of sitting there stubbornly arguing we coded a simple test screen in a week, saw it worked and the argument was over... like i'd say don't waste time being stubborn, time flies.

Is your partner's past experience built on native languages? Sometimes developers hide behind the performance excuse because they're wary of environments they don't know or aren't as proficient in. Does your team have equal proficiency in both environments, or will a new learning process be needed?

They say cross-platform is a cure-all but when a third-party plugin blows up on an OS update you wait weeks for a fix. Especially in enterprise field applications working with custom hardware this risk can't be underestimated. Your partner's concern isn't entirely unfounded, also factor in the long-term maintenance burden.

Set a one-week deadline for the decision. Your partner prepares the same bluetooth barcode reading screen in the environment they advocate, and you do it in cross-platform, both in 3 days. Whichever finishes faster and without errors, continue with that infrastructure. When data speaks, personal arguments end.

If technical leadership and veto authority aren't defined in your partnership agreement, this kind of deadlock is inevitable. We recommend that at the company formation stage, you sign a written founders' protocol specifying which criteria (budget fit, speed to market) the final decision on technology choice will be based on.

edit: typed from phone, sorry for typos.

Thanks for posting.

How did you solve this? Are you looking for a partner or a co-founder? They are two different things.

Of course, it varies if your situation is different.

I went through the same thing two years ago. Start with a small trial; don't commit to everything at once.

I'm also curious if anyone does it differently.

You're right. If you're offering equity instead of salary, also state what you're offering in return.

following.

I've been down this road, let me tell you. Everything goes well for the first three months; problems arise in the fourth.

That's all, sorry if I went on too long.

I completely agree. Hasty decisions become decisions you have to fix six months later.

I'm also curious if anyone does it differently.

I'm curious too. Are you looking for a partner or a co-founder? They are two different things.

Noted, thanks.

My question might sound amateurish, sorry about that. Processes without records never improve, because you don't know what to fix.

Hope this helps.

This approach has a cost, which isn't discussed. When you try to change everything at once, nothing settles.

Proven by experience.