Come scegliere un contractor software per progetti B2B

Quando un contractor è meglio di agenzia o assunzione

Il contractor funziona quando hai ownership chiara delle priorità e ti serve capacità senior senza team permanente. L'agenzia aggiunge strati di coordinamento, utile se manca direzione prodotto e vuoi design, dev e PM insieme. L'assunto interno ha senso su roadmap pluriennale; è lento da avviare e costoso se l'ipotesi è ancora da validare. Il contractor eccelle in fasi delimitate: discovery, MVP, layer di integrazione, modernizzazione di un modulo legacy, o accelerazione di sei mesi prima del passaggio a team interno. Soffre quando nessuno interno sa dire no allo scope e ogni settimana riapre decisioni architetturali già chiuse.

• Contractor: delivery senior, comunicazione diretta, milestone a fasi
• Agenzia: squadra completa, più overhead, più processo
• Assunto: orizzonte lungo, conoscenza istituzionale, cicli sperimentazione lenti
• Ibrido: product owner interno + engineering contractor (frequente su B2B)

Abbina il profilo al problema, non al logo in CV

Un ottimo CV in fintech non garantisce il tuo tool di pianificazione industriale. Cerca overlap sui vincoli: integrazioni multi-sistema, workflow con ruoli, ambienti regolati, software vicino all'hardware, console admin B2B ad alto volume. Chiedi due storie: una dove ha ridotto scope per spedire, una dove ha bloccato scorciatoie pericolose. Vuoi prove di trade-off, non solo metriche di successo. Per SaaS B2B chiedi di billing, tenancy e job in background. Per tool interni chiedi migrazione da Excel e UX per operatori. Per portali enterprise chiedi accessibilità, audit trail e coordinamento release con altri team.

Consulta contesti di delivery simili al tuo, piattaforme assicurative, backoffice pagamenti, IoT industriale, app campus, non come prestigio di brand ma come prova di vincoli di produzione affrontati prima.

Shortlist: cosa mettere nel brief e nell'RFP leggero

Prima di parlare con qualcuno, scrivi un brief di una pagina: risultato di business, utenti principali, sistemi da integrare, deadline fissa e non-goal espliciti. I non-goal evitano discovery infinite che diventano tour architetturale di sei settimane. Un RFP leggero non è un documento legale di 40 pagine. Sono tre-cinque domande: descrivi un ingaggio simile, proponi fasi con criteri di accettazione, elenca assunzioni che cambiano il preventivo, spiega come gestisci la crescita dello scope. Chiedi opzione discovery a forfait così confronti il pensiero, non solo la tariffa oraria. Shortlist di tre-cinque candidati, non quindici. Valutazioni parallele costano anche a te, ogni call richiede gli stessi referenti interni. Se hai un advisor tecnico, mettilo nella prima call; altrimenti tratta la proposta a milestone del contractor come primo artefatto tecnico da criticare.

• Includi screenshot di flusso o forme dati (redatti) per risposte concrete
• Indica se servono hosting UE, accesso on-prem o framework di compliance
• Chiedi chi sarà assente dal vostro lato e per quanto, il contractor pianifica sui vostri colli di bottiglia

Processo di valutazione pratico (senza quiz da leetcode)

Salta i puzzle da lavagna se il ruolo non è ricerca algoritmica. Per delivery B2B usa discovery breve pagata o take-home sul tuo dominio: modello dati del flusso principale, rischi, piano in tre milestone con non-goal espliciti. In sessione live attraversa architetture o codice passato (in NDA). Chiedi cosa rifarebbe oggi. Chiedi come testa integrazioni quando le sandbox terze parti sono instabili. Verifica comunicazione: sa spiegare un vincolo tecnico a uno stakeholder non dev in un paragrafo? I progetti B2B falliscono per disallineamento quanto per qualità del codice. Valuta le proposte su chiarezza delle milestone e onestà sugli ignoti, non sull'ottimismo. Chi segnala rischio integrazione presto vale più di chi promette tutto in otto settimane senza aver visto il modello permessi.

• Discovery pagata (1–2 settimane) batte spec gratuite infinite
• Referenza con ex cliente, chiedi change di scope e supporto post-lancio
• Demo su staging di qualcosa che mantiene ancora o ha spedito di recente
• Proposta scritta con criteri di accettazione, non solo tariffa oraria

Red flag che predicono rimpianti costosi

Diffida di prezzi fissi senza discovery, soprattutto se le integrazioni sono menzionate a voce. Diffida di chi non mostra CI/CD, test o deploy. Diffida di chi dice sì a ogni feature senza documentare trade-off, pagherai in tempo calendario. Altro flag: subcontracting opaco, pensi di avere un senior ma il codice lo scrive un junior. Chiedi chi scrive e chi fa review ogni giorno. Timeline aggressive prima di vedere modello dati o permessi è un pattern. Anche rimandare IP, accessi e handover a fine progetto.

Condizioni commerciali che proteggono entrambi

Struttura a fasi: discovery (forfait), MVP (milestone), evoluzione (sprint o T&M con cap). Definisci cosa è incluso: accesso repo, documentazione infrastruttura, test suite, sessioni di transfer. Chiarisce IP sul codice su misura, licenza di librerie riusabili, riservatezza. Per clienti UE allinea ruoli GDPR se il contractor tocca dati personali in staging o supporto. Concorda aspettative post-lancio: finestra bug-fix, cap ore supporto, o retainer. Supporto indefinito genera attrito al primo incidente di venerdì sera. I pagamenti devono seguire valore dimostrato: acconto su discovery è ragionevole; legare la parte più grande a demo milestone riduce il rischio. Evita prepagare tutto l'MVP prima dello staging, se la fiducia è bassa, accorcia le milestone invece di aumentare il cash upfront.

Se stai budgettando, incrocia le fasce milestone con la guida ai costi di sviluppo SaaS e prodotto nel 2026. Scegliere la persona giusta non elimina il costo di integrazioni, compliance e hardening operativo, fa solo spendere quelle voci con intenzione.

• Accettazione milestone su demo staging, non slide
• Processo change request quando lo scope cresce (impatto scritto su tempi/costi)
• Accessi: repo, cloud, secret, chi tiene le chiavi e rotazione
• Uscita: checklist handover, documentazione minima obbligatoria

Progettare la prima milestone per costruire fiducia

La prima milestone deve essere piccola, visibile, orientata alla produzione: scheletro auth, un flusso end-to-end, o integrazione read-only con dati reali in staging, not un mese di fondamenta invisibili. Includi basi operative presto: ambienti, logging, error tracking, percorso di deploy. Se arrivano solo in fase tre, scopri il rischio deploy tardi. Paga su demo più checklist: test ok, README per run locale, niente secret in repo. La fiducia accelera quando entrambi vedono software funzionante presto.

Ritmo di lavoro che tiene i progetti B2B in carreggiata

Demo settimanale su staging, log decisioni scritto, backlog prioritizzato unico. Chat async per dettagli; i trade-off strategici servono slot ricorrente con chi può decidere sul business. Limita WIP: una iniziativa principale per stream contractor. Tre iniziative parallele distruggono contesto e qualità. Quando dipendenze bloccano, legal su API, coda team interno, metti blocker per iscritto con date. Il contractor non può assorbire latenza organizzativa invisibile senza rinegoziare timeline. Definisci come si registrano le decisioni: ADR leggero o voce di log con data, owner e alternative scartate. Tra sei mesi, quando un nuovo assunto chiede perché PostgreSQL, ringrazierai te stesso. Il contractor non deve essere l'unico a ricordare perché lo scope è stato tagliato in settimana quattro.

Fissa aspettative di review: chi approva le PR dal vostro lato, tempo massimo di risposta, se serve security review prima della produzione. I go-live B2B si fermano quando 'rivediamo quando possiamo' incontra un contractor che aspetta tre giorni per merge.

Pianificare il passaggio a un team interno (anche se è dopo)

Molti ingaggi B2B finiscono con team interno che subentra. Pianifica dalla milestone uno: standard di codice documentati, CI nell'account vostro, infrastruttura come codice nel vostro repo, almeno un ingegnere interno in shadow sulle decisioni chiave. Budgetta due-quattro settimane di handover esplicito, walkthrough, pairing su incidenti, runbook per deploy e rollback. Saltare il passaggio risparmia sulla carta e costa mesi al primo bug in produzione dopo l'uscita del contractor. Se non c'è ancora team interno, richiedi comunque operabilità: un altro contractor deve poter continuare senza archeologia. Quella disciplina protegge anche se la relazione finisce prima.

Controlli extra per software enterprise e industriale

Contesti enterprise e industriali aggiungono requisiti non funzionali che sviluppatori web generici sottostimano: audit log, segregazione ruoli, accesso VPN/on-prem, connettività intermittente, sessioni lunghe su device in produzione, coordinamento con vendor hardware. Chiedi esperienza WCAG se contano interfacce banking o PA. Chiedi osservabilità su job notturni tra stabilimenti o batch pagamenti. Se il sistema tocca macchine o ricarica EV, chiedi versioning firmware/API e override manuali sicuri, domini dove solo web non basta. In Italia e in UE, verifica anche come gestiscono hosting, backup e responsabilità su dati in staging: un contractor serio distingue ambiente demo da produzione e non mescola dati reali nei laptop senza policy scritta.

Se stai ancora decidendo tra prodotto esterno e piattaforma interna, leggi quando conviene costruire tool interni invece del SaaS prima di ingaggiare, il tipo di contractor che ti serve cambia se il deliverable è integrazione su ERP o un nuovo prodotto digitale.

Prossimi passi prima di firmare

Scrivi brief di una pagina: problema, utenti, sistemi, deadline, non-goal. Valuta due candidati in parallelo se puoi, confronta chiarezza milestone, non solo tariffa oraria. Per una valutazione di fit e scope, invia un messaggio o prenota una call breve. Sfoglia altre risorse su budget e architettura da chiudere prima che parta il contratto.

Domande frequenti