Scegliamo insieme i programmi di sviluppo per app mobile — come decidere tra soci?

L'anno scorso su un nostro progetto simile nel settore della logistica, proprio per l'ostinazione di voler fare tutto nativo, siamo passati da 6 mesi di consegna stimati a ben 11 mesi. Il budget inizialmente previsto di 220.000 TL è lievitato a 410.000 TL. Il cross-platform ormai dà problemi di accesso all'hardware solo in casi rarissimi; con budget ridotto, gestire due codebase separate è un vero lusso.

Qui il dettaglio tecnico critico è la latenza dei listener bluetooth in background e della lettura barcode basata sulla fotocamera. Nelle librerie cross-platform la latenza del bridge nativo è a livello di millisecondi, impercettibile per l'operatore di magazzino. Preparate direttamente un piccolo prototipo e misurate il frame rate della fotocamera, il vostro socio si convincerà quando vedrà i numeri.

abbiamo fatto la stessa discussione ci siamo trascinati per 4 mesi. insomma poi invece di impuntarci abbiamo codato una semplice schermata di prova in una settimana, abbiamo visto che funzionava e la discussione è finita. non impuntatevi inutilmente, il tempo vola.

L'esperienza passata del vostro socio è basata su linguaggi nativi? A volte gli sviluppatori, per timore di ambienti che non conoscono o conoscono meno, si rifugiano direttamente nella scusa delle prestazioni. Nel vostro team c'è la stessa padronanza di entrambi gli ambienti, o servirà un nuovo percorso di apprendimento?

Si racconta che il cross-platform sia la panacea di tutti i mali, ma quando un plugin di terze parti salta con un aggiornamento del sistema operativo aspetti la soluzione per settimane. Soprattutto nelle applicazioni aziendali sul campo che lavorano con hardware dedicato, questo rischio non è trascurabile. La preoccupazione del vostro socio non è del tutto infondata, considerate anche il carico di manutenzione a lungo termine.

Datevi una settimana di tempo per decidere. Il vostro socio prepari la stessa schermata di lettura barcode bluetooth nell'ambiente che sostiene, e voi in cross-platform, in 3 giorni. Con quale finisce più velocemente e senza errori, con quell'infrastruttura andate avanti. Quando parlano i dati, la discussione personale finisce.

Se nel vostro contratto di partnership non sono definiti la leadership tecnica e il diritto di veto, questo tipo di stalli è inevitabile. Vi consigliamo di mettere per iscritto e firmare con un protocollo dei fondatori, già in fase di costituzione della società, secondo quali criteri (compatibilità di budget, velocità di ingresso sul mercato) verrà presa la decisione finale sulla scelta tecnologica.

edit: ho scritto da telefono, scusate gli errori di battitura.

Grazie per aver scritto.

Come avete risolto questo? Cercate un socio o un co-fondatore? Sono due cose diverse.

Naturalmente cambia se la vostra situazione è diversa.

Ho vissuto la stessa cosa due anni fa. Inizia con un piccolo test, non impegnarti subito su tutto.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Ha ragione. Se offrite equity invece dello stipendio, scrivete anche cosa offrite in cambio.

ti seguo.

Sono passato da qui, vi racconto. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

È tutto, scusate se mi sono dilungato.

Concordo pienamente. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Mi chiedo anch'io. Cercate un socio o un co-fondatore? Sono due cose diverse.

Preso nota, grazie.

La mia domanda sarà un po' da principiante, scusate. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

Spero che le sia utile.

Questo approccio ha un costo, di cui non si parla. Se cerchi di cambiare tutto insieme niente si stabilizza.

Confermato dall'esperienza.