Un piccolo laboratorio per il ML in produzione.
Siamo ingegneri che preferiscono parlare del suo processo piuttosto che del nostro stack. Inseriamo i modelli nel flusso di lavoro che già spende il budget, concordiamo la metrica prima del training e consegniamo serving, monitoraggio e rollback insieme.
- Fondazione
- 2025
- Team principale
- ML lead senior e ML engineer, specialisti per progetto
- Dove
- Minsk, Bielorussia · da remoto, orario lavorativo CET
- Contratto
- La proposta indica la controparte contrattuale; i pagamenti passano per la Georgia
SwankyForge è un piccolo team di ingegneria. I casi studio su questo sito sono reference design: ognuno mostra come si misurerebbero il prima e il dopo, e nessuno è presentato come risultato di un cliente. Definiamo i prezzi con un calcolatore pubblico che usa le stesse tariffe che le quoteremmo. Siamo la scelta giusta quando qualcosa costa troppo o richiede troppo tempo, e quella sbagliata quando serve una demo per un consiglio di amministrazione.
Partiamo dal suo problema, non dal nostro stack.
La maggior parte dei progetti ML fallisce per un problema di comunicazione, non di modellazione. Queste sono le abitudini di lavoro a cui ci atteniamo, e su cui può chiederci conto anche lei.
La prima call è una conversazione, non una demo.
Vogliamo capire il processo che già oggi assorbe il budget, chi ci lavora e cosa si rompe quando la risposta è sbagliata. Niente slide finché non lo abbiamo capito.
Un ingegnere con nome e cognome, dall'inizio alla fine.
Chi definisce lo scope del progetto è la stessa persona che lo porta in produzione e che risponde quando scatta un alert. Nessun passaggio tramite account manager, nessun junior subentrato dopo la firma.
Le diremo di non comprare ML.
Se un motore di regole, un report fisso o un inserimento dati migliore spostano il suo numero a un costo minore, lo mettiamo per iscritto e lo diciamo. A noi costa un progetto, a lei fa risparmiare due trimestri.
La trasparenza è l'impostazione predefinita.
Una metrica fissata prima che inizi il training. Un aggiornamento scritto ogni settimana, che le notizie siano buone o no. Il repository nella sua organizzazione dal primo giorno: nulla resta sui nostri laptop.
Ogni decisione tecnica ha una versione in linguaggio semplice.
Il suo CFO deve poter mettere in discussione la nostra architettura senza un traduttore nella stanza. Se non sappiamo spiegare un trade-off in un paragrafo, non lo abbiamo ancora capito abbastanza bene.
Restiamo dopo il lancio.
Serving, monitoraggio, alert di drift e un percorso di rollback vengono consegnati insieme al modello. Un sistema su cui nessuno può fare rollback non è finito.
Su cosa può chiederci conto.
Non i risultati: quelli dipendono dai suoi dati. Questi sono gli impegni di lavoro presenti in ogni contratto.
- 01
Una demo funzionante ogni settimana
Non un report di stato. Qualcosa che gira, sui suoi dati, dalla seconda settimana in poi.
- 02
Il repository vive nella sua organizzazione dal primo giorno
Codice, pesi, runbook e cronologia sono suoi. Nulla viene trattenuto fino all'ultima fattura.
- 03
Accettazione della milestone prima della fattura
Ogni milestone ha criteri di accettazione scritti e concordati in anticipo. Lei approva, poi fatturiamo.
- 04
Monitoraggio e rollback consegnati prima del passaggio di consegne
Una dashboard sulla metrica che ha indicato, alert di drift e un rollback che può attivare senza di noi.
Ha una voce di costo da spostare?
Risponda a sei domande e le diremo cosa faremmo davvero, anche quando la risposta è che per ora non ha bisogno di noi.