Ho progettato un'app mobile da solo con un tool gratuito: la affido a un'agenzia o la faccio rifare da zero?

Il codice esportato dai tool gratuiti è quasi sempre spaghetti code: pieno di librerie inutili e con un consumo di memoria esagerato. Se i ristoratori devono inviare gli ordini la mattina presto e l'app crasha, perdi subito clienti. Usa la tua bozza come riferimento visivo, ma fai scrivere il codice da zero in modo pulito.

Nel valutare i preventivi fissa tre condizioni inderogabili: 1) cessione della proprietà del codice sorgente alla tua azienda fin dal primo giorno, 2) gestione completa delle pratiche di approvazione su Apple e Google inclusa nella consegna, 3) almeno tre mesi di supporto e correzione bug post-pubblicazione senza costi extra.

Quando quello da 12.000 SAR smetterà di rispondere al telefono dopo due mesi, capirai il reale valore dell'agenzia da 40.000 SAR. Il software a basso costo si finisce per pagarlo sempre almeno due volte.

Cattura lo screenshot di ogni schermata del prototipo e riunisci i diagrammi di flusso in un unico PDF. Presentalo come capitolato tecnico quando chiedi i preventivi: eviterai che trovino scuse per fatturarti costi fuori capitolato a metà lavoro.

A Gedda abbiamo fatto sviluppare da zero un'app simile per la logistica B2B. Presentando noi il prototipo completo, l'agenzia ha abbassato la proposta da 55.000 a 34.000 SAR perché la fase di analisi si è praticamente dimezzata. Il prototipo è una leva contrattuale formidabile.

Secondo la normativa del Ministero del Commercio dell'Arabia Saudita, la proprietà del codice sorgente deve essere indicata chiaramente nei contratti di sviluppo software. In caso contrario, il codice potrebbe essere considerato proprietà intellettuale dell'agenzia. A prescindere dall'offerta che sceglierete, fate inserire nel contratto che l'accesso al repository del codice sia intestato alla vostra azienda.

I ristoranti hanno davvero bisogno di un'app mobile? Per le notifiche e la fatturazione, un pannello web responsive non basterebbe per iniziare? Avete calcolato le commissioni degli store e le spese annuali per gli account sviluppatore?

Hai fatto bene ad aprire questo thread. Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

Io seguirei questa strada.

Non lo sapevo.

Sono d'accordo, anzi vorrei sottolinearlo. Il calendario dei pagamenti va legato alle fasi del lavoro, non alle date.

Il vero problema non è il numero, ma su cosa si basa quel numero. Lascio una nota, potrebbe servire.

mi chieo anch'io.

Salvato. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

C'è un punto che mi incuriosisce. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Se non sono stati definiti i criteri di accettazione, il momento in cui il lavoro è finito è discutibile. Buon lavoro.

Sono d'accordo. Il codice senza documentazione di installazione non è tuo, anche se ce l'hai in mano.

Hai fatto bene ad aprire questo thread.

Direi di non avere fretta. cioè introdurre un processo per le richieste di modifica non rallenta il lavoro lo accelera.

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

Riassumo l'argomento, perché sono state date diverse risposte. Un report settimanale scritto sull'avanzamento è molto più utile che chiedere date.

Se avete domande, scrivete, rispondo per quanto possibile.

Come avete risolto questo? Introdurre un processo per le richieste di modifica non rallenta il lavoro lo accelera.

Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla. Spero che le sia utile.