7 Red Flags: Il Tuo Sviluppatore Ti Sta Fregando?

Hai investito decine di migliaia di euro in un software custom. Sono passati mesi e il progetto è sempre "quasi pronto". I costi continuano a salire, le scadenze slittano, e inizi a chiederti: mi stanno fregando? La risposta spesso è sì, ma il problema è riconoscere i segnali d'allarme prima che sia troppo tardi.

In questa guida ti mostro i 7 red flags inequivocabili che indicano problemi seri con il tuo sviluppatore software custom. Se ne riconosci almeno 3, è il momento di preoccuparti seriamente.

🚩 Red Flag #1: "Mancano Solo gli Ultimi Dettagli" (Da 3 Mesi)

Il progetto doveva essere consegnato a gennaio. A febbraio ti dicono "Manca solo qualche dettaglio, questione di giorni". A marzo: "Stiamo facendo gli ultimi test". Ad aprile: "Dobbiamo sistemare alcuni bug minori". E siamo ancora qui a maggio senza software funzionante.

**Perché è un red flag grave:**

Se uno sviluppatore competente dice "mancano 2 settimane", significa davvero 2 settimane, massimo 3. Se dopo 3 mesi ti dice ancora "mancano gli ultimi dettagli", significa che:
- Non ha idea di quanto lavoro manca davvero
- Sta nascondendo problemi strutturali grossi
- Non ha un processo di sviluppo serio con milestone verificabili

**Cosa fare:**

Chiedi una demo di quello che c'è ADESSO, non promesse su cosa ci sarà. Un software al 90% dovrebbe essere dimostrabile e utilizzabile, anche se mancano alcune funzionalità secondarie. Se non possono mostrarti niente di concreto che funziona, non sono al 90% ma probabilmente al 40-50%.

Pretendi una nuova timeline con milestone settimanali verificabili: "Settimana 1: modulo X funzionante e dimostrabile, Settimana 2: modulo Y integrato con X, etc." Se non possono darti una timeline dettagliata, non hanno controllo del progetto.

🚩 Red Flag #2: Comunicazione Fantasma

All'inizio rispondevano in giornata. Ora passi 3-4 giorni per avere una risposta. Le email vengono ignorate. Le videocall vengono cancellate all'ultimo momento o rimpiazzate con messaggi testuali vaghi. Non ricevi mai aggiornamenti proattivi, devi sempre chiedere tu.

**Perché è un red flag grave:**

La comunicazione scarsa è il sintomo numero uno di un progetto in crisi. Gli sviluppatori evitano di comunicare quando:
- Hanno preso troppi progetti e il tuo è finito in fondo alla coda
- Ci sono problemi tecnici grossi che non sanno come risolvere
- Sono in ritardo e sperano che tu non te ne accorga

**Cosa fare:**

Manda una email formale stabilendo regole di comunicazione chiare: "Da ora pretendo aggiornamenti settimanali ogni venerdì entro le 17:00 con stato avanzamento, problemi incontrati, prossimi step. Se non ricevo aggiornamenti, considererò il contratto violato."

Se continuano a ignorare le richieste, attiva le clausole contrattuali. Se il contratto non ha penali per ritardi o mancata comunicazione (errore tuo in fase di firma), valuta seriamente di cambiare sviluppatore anche se significa ripartire da zero.

🚩 Red Flag #3: "Serve un Extra per Questa Funzionalità"

Ogni due settimane ti chiedono costi extra per funzionalità che pensavi fossero incluse nel preventivo originale. "Il login sicuro è un extra", "L'export Excel costa a parte", "La versione mobile è fuori scope", "Il backup automatico è un servizio premium".

**Perché è un red flag grave:**

Un preventivo serio include TUTTO quello che serve per un software funzionante. È normale che funzionalità davvero nuove non previste inizialmente siano extra. Ma se ogni singola cosa che ti serve diventa un extra, significa che:
- Ti hanno dato un preventivo volutamente basso per vincere il progetto (lowballing)
- Non hanno capito (o non hanno voluto capire) i requisiti reali
- Stanno cercando di raddoppiare il costo finale a piccoli pezzi

**Cosa fare:**

Torna al preventivo originale e verifica cosa c'è scritto esattamente. Se le funzionalità che ti chiedono come extra erano ragionevolmente implicite nel progetto (es: un gestionale ordini senza export Excel è inutilizzabile), rifiuta fermamente i costi extra.

Se il preventivo originale era troppo generico senza dettaglio funzionale (errore tuo), hai poca leva. In futuro, pretendi sempre uno scope of work dettagliato con elenco puntuale di tutte le funzionalità incluse.

🚩 Red Flag #4: Il Codice È "Proprietario" e Non Puoi Averlo

Chiedi di vedere il codice sorgente o di avere accesso al repository e ti dicono "Il codice è di nostra proprietà" o "Non possiamo dare accesso per ragioni di sicurezza IP" o "Il codice è offuscato per proteggere i nostri algoritmi proprietari".

**Perché è un red flag GRAVISSIMO:**

Tu stai PAGANDO per quel software. Il codice è TUO, non loro. Se ti negano l'accesso al codice, significa che:
- Vogliono tenerti ostaggio: se cambi sviluppatore, devi rifare tutto da zero
- Il codice fa schifo e non vogliono che altri lo vedano
- Stanno usando codice che non hanno diritto di usare (licenze violate, codice copiato)
- Non c'è nessun "algoritmo proprietario", è una scusa

**Cosa fare:**

Questa è una battaglia che DEVI vincere. Il contratto deve specificare chiaramente che il codice sorgente completo è di tua proprietà esclusiva una volta completato il pagamento. Pretendi accesso a:
- Repository Git completo con tutta la history
- Documentazione tecnica per permettere a un altro sviluppatore di continuare il lavoro
- Credenziali di admin per database, server, servizi cloud

Se rifiutano, interrompi il pagamento e consulta un avvocato. Stai pagando decine di migliaia di euro per qualcosa che non possiedi davvero. È inaccettabile.

🚩 Red Flag #5: Usano Solo Tecnologie "Loro"

Quando chiedi che tecnologie usano, la risposta è vaga: "Il nostro framework proprietario", "Un sistema che abbiamo sviluppato noi in 20 anni", "Una piattaforma custom che solo noi sappiamo usare". Non React, non Laravel, non Django, ma "il nostro sistema".

**Perché è un red flag grave:**

I framework proprietari esistono per UN solo motivo: tenerti vincolato a loro per sempre. Con tecnologie standard (React, Vue, Laravel, Django, etc):
- Puoi assumere altri sviluppatori che conoscono quella tecnologia
- Puoi cambiare fornitore senza rifare tutto da zero
- Hai una community enorme di supporto

Con un "framework proprietario":
- Solo loro possono modificare il software
- Se chiudono o aumentano i prezzi, sei fregato
- Nessun altro sviluppatore può aiutarti

**Cosa fare:**

Pretendi tecnologie standard, moderne e open source. Chiedi esplicitamente: "Che linguaggio? Che framework? Che database?". Le risposte devono essere precise: "Node.js con Express", "Python con Django", "PHP con Laravel", "React + Next.js".

Se insistono sul loro framework proprietario, scappa. L'unica eccezione accettabile è se stai pagando cifre da enterprise (100k€+) per un sistema davvero complesso che giustifica sviluppo ad-hoc, e il contratto ti garantisce comunque piena proprietà e documentazione completa.

🚩 Red Flag #6: Zero Testing, "Testeremo Alla Fine"

Chiedi di vedere il software in funzione con dati reali e ti dicono "Non è ancora pronto per i test" oppure "Testeremo tutto insieme quando è finito" oppure "I test li facciamo noi internamente, tu vedrai solo il risultato finale".

**Perché è un red flag grave:**

Il testing non è una fase che si fa alla fine. Il testing deve essere continuo durante tutto lo sviluppo. Sviluppatori seri:
- Ti fanno vedere demo funzionanti ogni 2 settimane
- Ti fanno testare le funzionalità mano a mano che vengono completate
- Raccolgono il tuo feedback early per aggiustare subito

Se dicono "testeremo alla fine", significa che:
- Non hanno un processo di sviluppo serio
- Il software è pieno di bug che scoprirai solo a fine progetto
- Non vogliono il tuo feedback perché sanno che diresti che non va bene

**Cosa fare:**

Pretendi demo intermedie obbligatorie. Inserisci nel contratto che ogni 2 settimane deve esserci una demo funzionante con le funzionalità sviluppate in quello sprint, anche se incomplete.

Se rifiutano, inserisci almeno milestone di pagamento legate a deliverable dimostrabili: "30% dopo login e dashboard funzionanti, 30% dopo moduli X e Y integrati e testabili, etc". Mai pagare tutto in anticipo o a milestone generiche come "fine analisi", "fine sviluppo".

🚩 Red Flag #7: Il Team Cambia Continuamente

All'inizio ti hanno presentato Mario, senior developer con 10 anni di esperienza. Dopo un mese scopri che sul progetto lavora Giuseppe, junior che ha iniziato 6 mesi fa. Chiedi di parlare con lo sviluppatore e ogni volta è una persona diversa. Nessuno sembra conoscere la storia del progetto.

**Perché è un red flag grave:**

Il turnover continuo del team significa:
- Stanno usando junior sottopagati invece dei senior promessi
- Il progetto è un disastro e gli sviluppatori bravi scappano
- Non c'è ownership: nessuno si sente responsabile del risultato

Ogni volta che cambia lo sviluppatore, si perdono settimane per riallineamento e il rischio di bug aumenta esponenzialmente.

**Cosa fare:**

Pretendi un team fisso con nomi e ruoli chiari: "Mario è il lead developer, Giuseppe il frontend dev". Nel contratto specifica che il team non può cambiare senza il tuo consenso scritto.

Se il team cambia comunque, questo è motivo sufficiente per invocare le penali contrattuali o recedere. Un cambio di team a metà progetto può compromettere gravemente il risultato.

⚠️ Cosa Fare Se Riconosci 3+ Red Flags

Se hai riconosciuto almeno 3 di questi red flags, hai un problema serio. Ecco cosa fare:

**Passo 1: Valuta i Sunk Costs**
I soldi già spesi sono persi (sunk costs). La domanda giusta non è "Ho già speso 20k, come li recupero?" ma "Se continuo con questi, spenderò altri 30k per avere un software che non funziona?". A volte interrompere e ripartire con un altro sviluppatore costa meno che continuare.

**Passo 2: Chiedi un Audit Tecnico Esterno**
Fai valutare il codice esistente da uno sviluppatore terzo indipendente. Costa 500-1000€ ma ti dice: il codice è buono e basta finirlo, oppure è spazzatura da rifare. Questo ti dà la base oggettiva per decidere.

**Passo 3: Esercita i Diritti Contrattuali**
Se ci sono penali per ritardi, attivale. Se hai diritto a recedere, valutalo seriamente. Se il contratto è debole (errore tuo), almeno usa la minaccia legale come leva per ottenere trasparenza.

**Passo 4: Pianifica l'Exit Strategy**
Prima di interrompere, assicurati di avere: una copia del codice esistente (anche se incompleto), accesso a database e dati, documentazione di cosa è stato fatto. Questo permette a un nuovo sviluppatore di valutare se recuperare o ripartire.

✅ Come MPQuest Previene Questi Problemi

Noi operiamo in modo opposto a questi red flags:

- **Timeline Realistiche**: Mai promettere tempi impossibili. Meglio dire 10 settimane realistiche che 6 ottimistiche.
- **Comunicazione Trasparente**: Aggiornamenti settimanali automatici, sempre. Demo ogni 2 settimane, sempre.
- **Scope Chiaro e Fisso**: Preventivo dettagliato con tutto incluso. Zero "extra" a sorpresa.
- **Piena Proprietà del Codice**: Il codice è tuo al 100%. Repository, documentazione, tutto tuo.
- **Tecnologie Standard**: React, Next.js, Node, PostgreSQL. Mai framework proprietari.
- **Testing Continuo**: Demo funzionanti ogni 2 settimane, test con utenti reali durante sviluppo.
- **Team Fisso**: Il team che inizia il progetto lo finisce. Zero turnover a metà progetto.

✅ Conclusione

I red flags sono segnali d'allarme che devi imparare a riconoscere SUBITO, non dopo 6 mesi e 50k€ spesi. Comunicazione fantasma, costi extra continui, codice "proprietario", niente demo funzionanti: sono tutti sintomi di un progetto che sta andando male.

La buona notizia è che puoi evitare questi problemi scegliendo lo sviluppatore giusto fin dall'inizio, con contratti chiari, milestone verificabili e tecnologie standard.

Hai dubbi sul tuo progetto software attuale? Prenota una consulenza gratuita con MPQuest: rivediamo il contratto, valutiamo lo stato del progetto e ti diciamo se ci sono red flags da affrontare. Zero impegno, zero costi nascosti.