Choix des outils de développement mobile : comment trancher entre associés ?

L'année dernière, sur un projet logistique similaire, on s'est entêté à vouloir faire du natif : résultat, le délai de 6 mois est passé à 11 mois. Le budget initial de 220.000 TL a fini par exploser à 410.000 TL. Aujourd'hui, le cross-platform gère le hardware sans souci dans l'immense majorité des cas. Avec un petit budget, maintenir deux bases de code est un luxe inutile.

Le point technique critique ici, c'est l'écoute Bluetooth en arrière-plan et la latence du scan de code-barres via la caméra. Avec les bibliothèques cross-platform, la latence du bridge natif est de l'ordre de la milliseconde, c'est imperceptible à l'échelle humaine pour de la gestion d'entrepôt. Faites directement un petit prototype pour mesurer le framerate de la caméra, votre associé sera convaincu quand il verra les chiffres.

on s'est pris la tête sur exactement la même chose, 4 mois de perdus. genre au lieu de camper sur nos positions on s'est posé une semaine pour coder un petit écran de test on a vu que ça marchait et fin du débat. lâchez l'affaire et testez au lieu de bloquer le temps file.

L'expérience de votre associé repose-t-elle principalement sur les langages natifs ? Parfois, les développeurs se retranchent derrière l'argument de la performance simplement parce qu'ils appréhendent un environnement qu'ils maîtrisent moins. Votre équipe est-elle aussi à l'aise sur les deux approches, ou cela nécessitera-t-il une phase d'apprentissage ?

On vend souvent le cross-platform comme le remède miracle, mais dès qu'un plugin tiers saute après une mise à jour d'OS on attend des semaines pour avoir un fix. Ce risque est loin d'être négligeable, surtout pour des applications métier sur le terrain qui exploitent du matériel spécifique. Les craintes de votre associé ne sont pas totalement infondées pensez bien à la charge de maintenance sur le long terme.

Donnez-vous une semaine pour trancher. Votre associé prépare l'écran de scan Bluetooth sur son stack de prédilection, et vous sur la solution cross-platform, le tout en 3 jours. Celui qui livre la version la plus rapide et sans bug l'emporte. Quand ce sont les faits et les données qui parlent, les débats d'ego s'arrêtent.

Si votre pacte d'associés ne définit pas clairement le leadership technique et un droit de veto, ce genre de blocage est inévitable. Dès la création de l'entreprise, nous vous conseillons de formaliser par écrit dans un protocole entre fondateurs les critères (respect du budget, time-to-market) qui détermineront le choix final des technologies.

edit : j'ai écrit depuis mon téléphone, désolé pour les fautes.

Merci pour votre retour.

Comment avez-vous résolu ce point ? Cherchez-vous un associé ou un cofondateur ? Ce sont deux choses différentes.

Bien sûr, cela change si votre situation est différente.

J'ai vécu exactement la même chose il y a deux ans. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Je suis aussi curieux de savoir si d'autres font autrement.

Vous avez raison. Si vous proposez des parts au lieu d'un salaire, indiquez aussi ce que vous offrez en échange.

je suis intéressé.

Je suis passé par là, laissez-moi vous raconter. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

Voilà, désolé si je me suis étendu.

Je suis entièrement d'accord. Les décisions hâtives finissent par être corrigées six mois plus tard.

Je suis aussi curieux de savoir si d'autres font autrement.

Je me pose aussi la question. Cherchez-vous un associé ou un cofondateur ? Ce sont deux choses différentes.

C'est noté, merci.

Ma question va paraître un peu novice, désolé d'avance. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

J'espère que cela vous sera utile.

Cette approche a un coût dont on ne parle pas. Quand on essaie de tout changer en même temps, rien ne prend.

C'est confirmé par l'expérience.