Web App Su Misura O SaaS Pronto All'uso

Quasi nessuno sviluppo di web app su misura comincia da un capitolato. Comincia da un foglio di calcolo che qualcuno ha creato per tenere traccia di una cosa sola, che ha messo una seconda colonna, poi una scheda, poi una formula che capisce una persona sola. Tre anni dopo quel file contiene la pianificazione, i prezzi e metà dell’anagrafica clienti, quattro persone lo modificano insieme e nessuno sa dire con certezza quale copia sia quella buona.

È questo il vero punto di decisione, e non è quello che affrontano la maggior parte degli articoli sul costruire o comprare. Non state scegliendo tra una pagina bianca e un prodotto. State scegliendo tra tre vie d’uscita da un processo che funziona ma è fragile: comprare un prodotto, assemblare qualcosa su una piattaforma no-code, oppure commissionare un software modellato sul vostro modo di lavorare.

Conviene costruire una web app su misura o comprare un SaaS? Comprate, a meno che non valgano almeno due di tre condizioni: il processo è un fattore di differenziazione e non un costo di struttura, nessun prodotto lo sostiene senza distorcere il vostro modo di lavorare, e il lavoro di integrazione è il grosso dell’incarico. Se ne vale una sola, un prodotto più configurazione costa quasi sempre meno. Uno sviluppo su misura porta inoltre un pavimento di costo ricorrente pari a circa il 15 o 20 per cento del prezzo di costruzione ogni anno, per sempre.

Il foglio di calcolo diventato portante

Lo schema è abbastanza preciso da meritare un nome, e di solito è dandogli un nome che una squadra si riconosce.

Comincia con una persona e uno scopo. Qualcuno deve sapere quali lavori sono prenotati questa settimana, quindi apre un foglio. Una seconda persona deve leggerlo, quindi finisce su un disco condiviso. Poi una terza deve modificarlo, e adesso in più scrivono nelle stesse celle nello stesso momento. Poi una scheda per ogni mese. Poi una ricerca su un secondo file. Poi una macro, scritta da un consulente che nel frattempo se n’è andato.

I segnali sono sempre gli stessi. Il file ha una data e un suffisso di versione nel nome. Esiste una copia principale e tutti sanno chi la custodisce. Inserire una persona appena assunta significa mostrarle il file invece di spiegarle il processo, perché il processo non è scritto da nessun’altra parte.

A questo punto il foglio di calcolo non è un documento. È un’applicazione senza controllo degli accessi, senza registro delle modifiche, senza convalida, senza una politica di backup che difendereste, e con un solo manutentore. Funziona, ed è esattamente il motivo per cui nessuno l’ha sostituito, ed è anche il motivo per cui sostituirlo adesso costa caro.

Quanto costa davvero lo stato attuale

Nessuno quantifica il foglio di calcolo, quindi sembra gratis. Non lo è, e il conto è facile da rifare per la propria azienda.

Partite dalla ridigitazione. Se due persone passano ciascuna 45 minuti al giorno a spostare dati fra il foglio, il gestionale contabile e una casella condivisa, sono sette ore e mezza a settimana, ovvero circa 340 ore in un anno lavorativo di 45 settimane. A GBP 22 l’ora di costo pieno state spendendo circa GBP 7.500 l’anno per copiare numeri da uno schermo all’altro, e questo non compra nulla se non l’occasione di sbagliare a battere un tasto.

Aggiungete poi la riconciliazione, quando qualcuno confronta ogni mese il foglio con la fonte autorevole e passa mezza giornata a decidere quale versione sia giusta. Aggiungete gli errori scoperti tardi: il preventivo mandato al prezzo del mese scorso, il lavoro prenotato due volte, il rinnovo mancato. Ognuno è una cifra piccola e un cliente scontento, e nessuno compare in una voce di bilancio.

Aggiungete infine il rischio legato alla persona chiave. Una sola capisce le formule, e quando quella persona è malata, in ferie o se n’è andata, il processo scende al livello delle supposizioni.

I dati personali in un foglio di calcolo restano dati regolamentati

Se il file contiene nomi, recapiti, fascicoli del personale o informazioni sui clienti, sono dati personali, e il UK GDPR si applica esattamente come si applicherebbe a una banca dati.

L’ICO è esplicito su ciò che questo richiede. La sua guida alla sicurezza dei dati afferma che un principio chiave del UK GDPR è trattare i dati personali in modo sicuro tramite misure tecniche e organizzative adeguate, e che quelle misure devono garantire la riservatezza, l’integrità e la disponibilità dei vostri sistemi e dei dati personali che contengono. Un foglio su un portatile non ha permessi per riga, non ha regola di conservazione e non ha traccia di chi abbia letto cosa, e si duplica per intero ogni volta che qualcuno lo manda per posta elettronica.

Le conseguenze non sono teoriche. Nell’ottobre 2024 l’ICO ha sanzionato il Police Service of Northern Ireland per GBP 750.000 dopo che dati nascosti in un foglio di calcolo, diffuso in risposta a una richiesta di accesso agli atti, hanno esposto cognomi, iniziali, gradi e ruoli di tutti i 9.483 agenti e dipendenti del PSNI. Il provvedimento cita gli articoli 5(1)(f), 32(1) e 32(2). Senza l’approccio dell’ICO verso il settore pubblico la sanzione sarebbe stata di GBP 5,6 milioni.

Ogni organizzazione che regge un processo sui fogli di calcolo ha un foglio così da qualche parte.

Comprare il prodotto: quando il SaaS è chiaramente la scelta giusta

Questa è la risposta nella maggior parte dei casi, e merita di essere sostenuta per prima anziché liquidata in un paragrafo di chiusura.

Se il vostro processo è comune, il prodotto esiste e costa meno di qualsiasi cosa possiate costruire. Paghe, note spese, gestione dei ticket, prenotazione appuntamenti, firma elettronica, contabilità, selezione dei candidati. Qualcuno ha impiegato un decennio e una grande squadra di ingegneri sui casi limite che voi non avete ancora incontrato: il difetto dell’anno bisestile, il cambio di aliquota IVA, il rimborso che arriva dopo la chiusura del periodo.

State anche comprando lavoro che altrimenti pagherete. Il fornitore si assume la continuità di servizio, le correzioni di sicurezza, il ricambio dei browser, il lavoro sull’accessibilità e le prove di conformità che i vostri clienti chiedono. Niente di tutto questo compare come funzionalità, e tutto questo è denaro vero.

Il test onesto non è se il prodotto faccia tutto. È se faccia l'80 per cento che conta senza costringervi a cambiare qualcosa a cui tenete. Se l’unica differenza è che la vostra squadra dice lavoro e il software dice ticket, comprate il software e cambiate la parola.

Le tre condizioni che giustificano lo sviluppo di una web app su misura

Uno sviluppo su misura si giustifica con la strategia, non con il fastidio. Ci sono tre condizioni che davvero lo sostengono, e la regola utile è che ve ne servono almeno due. Una condizione da sola si risolve quasi sempre a costo minore con un prodotto più configurazione. Lo stesso test vale su scala aziendale, cosa che la nostra guida al costruire o comprare per CRM ed ERP affronta a un ordine di grandezza diverso.

Il processo è un fattore di differenziazione, non un costo di struttura

Chiedetevi che cosa noterebbe un cliente se il processo diventasse due volte migliore. Se la risposta è niente, è un costo di struttura e dovreste comprare, perché avere paghe eccellenti non vi porta clienti. Ma un installatore specializzato la cui logica di pianificazione strappa un lavoro in più alla giornata di ogni furgone, o un finanziatore le cui regole di istruttoria sono il prodotto vero e proprio, fa passare il proprio vantaggio competitivo attraverso quel software. Non potete comprare un vantaggio che i vostri concorrenti possono comprare allo stesso prezzo mensile.

Nessun prodotto si adatta senza distorcere il processo

Ogni prodotto codifica ipotesi su come scorre il lavoro, e il segnale che per voi sono sbagliate è che adottarlo vi imporrebbe di smettere di fare qualcosa di redditizio. Se la vostra azienda quota su una base che il prodotto non sa esprimere, e quotare così è il motivo per cui i clienti vi scelgono, il prodotto vi sta chiedendo di diventare più ordinari in cambio di un canone di licenza.

La superficie di integrazione è il lavoro vero

A volte la parte interessante non sta affatto nelle schermate. Sta nel prendere le giacenze da un sistema, i prezzi da un secondo, la disponibilità dei tecnici da un terzo e scrivere il risultato in un quarto. Quando la maggior parte dello sforzo è integrazione, l’interfaccia è uno strato sottile sopra le vostre tubature, e le schermate incluse in un prodotto sono la parte di cui avete meno bisogno. È la condizione più spesso sottovalutata, ed è dove abita la trappola di mezzo.

La trappola di mezzo: comprare e poi costruire lo stesso

L’esito più costoso non è nessuna delle due vie percorsa in modo pulito. È comprare un prodotto perché sembrava più economico, poi spendere per piegarlo al vostro processo più di quanto sarebbe costato uno sviluppo su misura, e pagare comunque la licenza.

Succede per gradi e ogni singolo passo è difendibile. Il prodotto non si adatta, quindi ingaggiate un partner di implementazione. Il partner scrive configurazione nel linguaggio di scripting proprietario del fornitore, che è codice, ma non sembra codice perché vive dentro il prodotto. Poi serve che dialoghi con altri due sistemi, quindi comprate una piattaforma di integrazione. Poi il fornitore rilascia una versione maggiore e le vostre personalizzazioni richiedono test di regressione.

A quel punto avete tutti i costi del software su misura e nessuna delle sue proprietà: una base di codice che non sapete leggere, ospitata dove non avete controllo, scritta in un linguaggio che esiste in un solo prodotto, mantenuta da un partner la cui tariffa giornaliera è ormai una riga del vostro bilancio. La nostra guida al costo dello sviluppo software su misura mostra come si accumulano quei numeri.

Segnali che siete finiti nella trappola

La trappola è più facile da riconoscere che da abbandonare, e i segnali sono inequivocabili appena li si cerca.

• La parcella del partner di implementazione supera il canone di licenza del primo anno.
• Qualcuno di fatto occupa un posto a tempo pieno per amministrare un solo prodotto.
• Avete scritto logica nel linguaggio di scripting proprietario del fornitore, e nessuno fuori dalla vostra azienda sa leggerla.
• Ogni aggiornamento del fornitore fa scattare un test di regressione sulle vostre personalizzazioni, quindi rimandate gli aggiornamenti.
• Pagate una piattaforma di integrazione che esiste solo per alimentare di dati quell’unico prodotto.
• Tenete un foglio di calcolo ombra accanto al prodotto, perché il prodotto non sa esprimere qualcosa che vi serve.

L’ultimo è il più chiaro. Se il foglio di calcolo è sopravvissuto all’acquisto del software, il software non ha risolto il problema.

No-code e low-code come terza via seria

La domanda su no-code o su misura merita più di una nota a piè di pagina, perché per lo sviluppo di strumenti interni le piattaforme low-code sono spesso la risposta giusta e non sono un giocattolo.

Piattaforme come Airtable, Retool e Microsoft Power Apps vi lasciano costruire una vera applicazione multiutente con banca dati, moduli, permessi e automazioni, in giorni anziché mesi, senza assumere nessuno. Gestiscono hosting, backup, autenticazione e disposizione per il telefono. Per il compito preciso di portare un foglio di calcolo portante dentro qualcosa con un controllo degli accessi vero e un registro delle modifiche, sono spesso la via più rapida a una grande riduzione del rischio.

Sono anche vendute a postazione, ed è il fatto che decide se restino la risposta giusta mentre crescete.

Dove il no-code vince davvero

Vince quando la forma del problema sta in record, moduli, viste e regole semplici: un registro dei beni, una coda di approvazioni, una lista di controllo per l’ingresso di un cliente, la prenotazione delle sale. Vince soprattutto quando la persona che capisce il processo può costruirlo da sé, perché i requisiti non devono mai sopravvivere alla traduzione in un capitolato e ritorno.

Vince anche sul tempo per arrivare al valore. Uno strumento funzionante in due settimane e usato ogni giorno batte uno perfetto in sei mesi ancora in fase di disegno, e la versione costruita vi insegna quali fossero davvero i requisiti.

Dove il no-code sbatte contro un muro

Il muro di solito è una di cinque cose. Le prestazioni sul numero di righe reale, quando una vista deve filtrare centinaia di migliaia di record. I permessi con una complessità vera, per esempio regole per riga che dipendono dallo stato del record e dalla squadra di chi guarda. L’integrità transazionale, dove due cose devono accadere entrambe o nessuna. Test e controllo di versione, perché spesso non c’è modo di rivedere una modifica prima che vada in linea. E qualunque cosa abbia una macchina a stati vera, dove regole stabiliscono quali transizioni siano lecite.

Non arrivate al muro per gradi. Ci arrivate quando una modifica che dovrebbe richiedere un’ora si rivela impossibile.

Che cosa produce su larga scala il prezzo a postazione

Il prezzo a postazione è conveniente con dieci utenti e può diventare indifendibile con quattrocento, e le tariffe pubblicate lo dimostrano facilmente.

La pagina prezzi di Retool indica il piano Business per il cloud britannico a GBP 40 al mese per sviluppatore e GBP 12 per utente interno, con il piano Team a GBP 8 e GBP 4. Microsoft indica Power Apps Premium a GBP 16,90 per utente al mese con pagamento annuale, IVA esclusa, che scende a GBP 10,80 con un minimo di 2.000 postazioni. Airtable pubblica Team a USD 20 e Business a USD 45 per utente al mese, entrambi fatturati annualmente in dollari statunitensi.

Proiettate quei numeri. Quaranta utenti su Retool Business, tre dei quali sviluppatori, fanno circa GBP 6.800 l’anno. La stessa configurazione con quattrocento utenti sta intorno a GBP 59.600 l’anno, e risale appena aggiungete persone. Su Power Apps Premium quattrocento postazioni costano circa GBP 81.000 l’anno prima dell’IVA.

Nessuna di queste tariffe è irragionevole. Il punto è che il conto segue il numero di persone e non il valore consegnato, e il numero di persone cresce.

Il problema dell’uscita quando la logica vive in uno strumento proprietario

Ogni piattaforma esporta i vostri dati. Nessuna esporta la vostra applicazione.

Le righe escono in CSV o tramite un’interfaccia di programmazione, ed è la parte che tutti controllano prima di firmare. Quello che non esce è la cosa che avete costruito: le automazioni, le colonne calcolate, le regole sui permessi, i moduli condizionali, il flusso che trasforma una richiesta in tre notifiche e un cambio di stato. Quella logica è il bene di valore, è costata mesi di decisioni e solo il motore di un fornitore sa eseguirla.

La conseguenza pratica è che lasciare una piattaforma low-code non è una migrazione, è una ricostruzione. Riprendete i vostri dati e riscrivete l’applicazione altrove, a partire da una specifica che non è mai stata scritta perché la specifica era la piattaforma.

Non è un argomento contro l’uso di queste piattaforme, ma solo a favore di una descrizione scritta delle regole tenuta fuori dallo strumento.

Costo totale su cinque anni per le tre vie

Il confronto che si fa di solito è disonesto in un modo preciso: mette la versione interamente costificata di una via contro il prezzo di listino dell’altra. Prendete quaranta utenti e un’applicazione operativa che sostituisce un foglio di calcolo e due piccoli abbonamenti. Le cifre sono valori di pianificazione illustrativi, non preventivi, e il prezzo di costruzione è la variabile che si muove di più.

Letto in prosa: con quaranta utenti vince la piattaforma no-code, a circa GBP 75.800 su cinque anni. Lo sviluppo su misura arriva secondo a circa GBP 94.500, perché una costruzione da GBP 45.000 più GBP 1.800 di hosting e GBP 8.100 di manutenzione annua batte comunque licenza, middleware e amministrazione sommati della via SaaS. Comprare il prodotto arriva ultimo a circa GBP 135.000, e ci arriva per la trappola di mezzo più che per la licenza.

Perché la stessa tabella si rovescia con quattrocento utenti

Cambiate un solo dato, il numero di persone, e l’ordine cambia del tutto. È il motivo singolo più comune per cui costruire diventa razionale.

Con quattrocento utenti la licenza SaaS a GBP 30 per postazione al mese vale da sola GBP 144.000 l’anno, e con lo stesso middleware e un carico amministrativo maggiore il totale su cinque anni supera GBP 800.000. La via no-code si ferma vicino a GBP 375.000. Lo sviluppo su misura si muove appena: più utenti significa una bolletta di hosting e un budget di manutenzione un po’ più grandi, quindi anche raddoppiando il prezzo di costruzione a GBP 70.000 il totale su cinque anni resta vicino a GBP 153.000.

Il motivo è strutturale. Il prezzo a postazione è un costo variabile che cresce con la vostra organizzazione, mentre un sistema su misura è un costo fisso più una piccola parte variabile, e quella parte è infrastruttura, che costa poco. Se il rovesciamento vi riguardi è una previsione aziendale, non un giudizio tecnico.

Il pavimento di costo ricorrente di uno sviluppo su misura

La riga che si lascia fuori da un preventivo su misura è quella che non finisce mai. Un’applicazione su misura ha un pavimento di costo, e non scende a zero in un anno tranquillo in cui nessuno chiede funzionalità.

Il pavimento è fatto di hosting, monitoraggio, backup di cui avete provato il ripristino, certificati TLS, correzioni di sicurezza, aggiornamenti delle dipendenze e qualcuno che risponde al telefono quando si rompe alle nove di lunedì. Mettete a piano circa il 15 o 20 per cento del costo di costruzione iniziale all’anno. È un’ipotesi di pianificazione ricavata da come si comportano questi progetti e non una statistica pubblicata, ma è la cifra su cui facciamo il nostro bilancio, e un preventivo che non la contiene non è un preventivo completo. Il nostro articolo sul costo di manutenzione del software lo analizza più a fondo.

Ogni totale su cinque anni del su misura qui sopra presume che quella riga sia finanziata. I progetti che la saltano non risparmiano quei soldi, li rimandano e li pagano più tardi come riscrittura, che è esattamente ciò che descrive il debito tecnico.

Il software non mantenuto si degrada

Un’applicazione che gira intatta da due anni non è stabile. È senza patch, e la differenza conta.

Nel vostro codice non è cambiato nulla, ma intorno è cambiato tutto. Gli ambienti di esecuzione arrivano a fine vita secondo un calendario pubblicato: Node.js al momento sostiene la versione 26 come Current, con le versioni 24 e 22 come linee LTS attive, il che significa che qualunque cosa poggi sulla versione 20 o precedente è fuori supporto e non riceve correzioni di sicurezza. Le dipendenze accumulano vulnerabilità pubblicate. I browser cambiano il trattamento dei cookie e della memoria locale. I fornitori di pagamenti dismettono versioni di interfaccia e vi danno una scadenza.

Nessuna di queste cose è colpa vostra e tutte sono un vostro problema, perché in un sistema su misura non c’è un fornitore che le assorba al posto vostro. È questo il vantaggio autentico e strutturale del comprare: la squadra di ingegneri di qualcun altro passa ogni settimana a impedire che il pavimento marcisca, e il canone di licenza è quanto costa. Il vostro budget di manutenzione compra esattamente lo stesso lavoro, e lo pagate o di proposito o in emergenza.

Trovare il vostro punto di pareggio per postazione

Il punto di pareggio si calcola in una decina di minuti, ed è più convincente per una direzione finanziaria di qualsiasi discorso sulla proprietà.

Prendete il costo mensile della via prodotto, tutto compreso: licenza, middleware e la frazione di stipendio spesa ad amministrarlo. Sottraete il costo mensile di esercizio di un sistema su misura, cioè hosting più un dodicesimo del budget annuo di manutenzione. Dividete il prezzo di costruzione per quel che resta. Il risultato è il numero di mesi prima che la costruzione si sia ripagata.

Svolto con quaranta utenti: la via SaaS gira a circa GBP 2.150 al mese e il sistema su misura a circa GBP 825, quindi il risparmio mensile è di circa GBP 1.325. Una costruzione da GBP 45.000 ci sta dentro circa 34 volte, quindi il rientro cade vicino a due anni e dieci mesi. Con quattrocento utenti il rientro scende sotto l’anno.

Due avvertenze. Il prezzo di costruzione è qui il numero meno certo, quindi fate il conto con il vostro preventivo e poi di nuovo con il 50 per cento in più. E un rientro superiore a tre anni circa è un caso debole, perché il vostro processo potrebbe non sopravvivere immutato tanto a lungo.

Dati e vincolo tagliano da entrambi i lati

Il vincolo al fornitore è l’argomento classico a favore del costruire, ed è reale. È anche solo metà del quadro, perché un sistema su misura che nessuno ha documentato è vincolato a sua volta.

Sul lato prodotto, verificate prima di firmare che cosa esce davvero. I record di solito si esportano puliti. Allegati, registri storici delle modifiche, discussioni nei commenti, strutture di permessi e relazioni fra i record spesso no. La misura pratica non è se esista un pulsante di esportazione, ma se riuscireste a mettere in piedi un sostituto funzionante partendo solo da quell’esportazione.

Sul lato su misura, il rischio uguale e contrario è un sistema costruito da un solo consulente senza README, senza test, senza manuale operativo, con le credenziali in un file di configurazione su un portatile e un repository nell’account personale di qualcuno. È peggio del vincolo SaaS, perché almeno il fornitore è ancora sul mercato.

I rimedi sono contrattuali ed economici da pretendere all’inizio. Tenete voi la proprietà del repository, chiedete documentazione e manuale operativo come consegne esplicite, e chiedete che un secondo ingegnere sappia installarlo partendo solo da quella documentazione. Verificatelo prima del saldo. La nostra guida completa per chi compra tratta le clausole contrattuali in modo più esteso.

Sicurezza e conformità nei diversi modelli

La divisione delle responsabilità cambia a seconda della via, ma una cosa non si sposta affatto, e sbagliarla è comune.

Sotto il UK GDPR il titolare del trattamento siete voi. L’ICO definisce il titolare come il soggetto che, da solo o insieme ad altri, determina le finalità e i mezzi del trattamento dei dati personali, e il responsabile come chi tratta dati personali per conto del titolare. Il vostro fornitore SaaS è quasi sempre il responsabile. Resta a voi dimostrare la conformità, e l’ICO dice esplicitamente che un titolare risponde dei propri responsabili e deve avere un contratto vincolante con le clausole richieste dall’articolo 28(3).

Quello che il fornitore porta davvero è lo strato infrastrutturale: sicurezza fisica, patch della piattaforma, controlli di rete e spesso certificazioni. Il modello di responsabilità condivisa dell’NCSC è chiaro sul fatto che anche con il SaaS a voi restano tre cose: valutare che il servizio soddisfi le vostre esigenze di sicurezza, configurarlo in modo sicuro e decidere quali dati mettervi dentro.

In uno sviluppo su misura ereditate anche l’intero strato tecnico: patch, controllo degli accessi, cifratura, registrazione, backup e ripristino. Il nostro articolo sulla conformità tecnica al GDPR mostra come si traduce nel codice. La posizione giuridica non cambia da una via all’altra.

L’accessibilità vale anche per gli strumenti interni

Gli strumenti interni vengono costruiti abitualmente come se nessuno fra chi li usa potesse avere una disabilità, il che è sbagliato e, per alcune organizzazioni, anche illegittimo.

Ai sensi della sezione 20 dell’Equality Act 2010 il datore di lavoro ha il dovere di adottare accomodamenti ragionevoli, compresi i passi che è ragionevole compiere per evitare uno svantaggio sostanziale causato da una disposizione, un criterio o una prassi, e di fornire ausili. Un sistema di turni che non si può usare con la tastiera mette una persona con disabilità in uno svantaggio sostanziale, e non esiste esenzione per il software che i vostri clienti non vedono mai.

Per gli enti del settore pubblico la posizione è esplicita. La guida di GOV.UK sui requisiti di accessibilità afferma che i siti intranet ed extranet rientrano nel regolamento sull’accessibilità, che devono soddisfare le WCAG 2.2 AA e che i vecchi siti interni pubblicati prima del 23 settembre 2019 vanno resi accessibili quando vengono aggiornati.

I criteri su cui gli strumenti interni cadono più spesso sono i più banali: 2.1.1 Tastiera e 3.3.2 Etichette o istruzioni al livello A, 1.4.3 Contrasto (minimo) al livello AA, e fra le aggiunte delle WCAG 2.2 i criteri 2.4.11 Focus non oscurato (minimo) e 2.5.8 Dimensione del bersaglio (minimo), entrambi al livello AA.

Nel no-code l’accessibilità è un soffitto che non controllate

È il punto sull’accessibilità che cambia una decisione fra costruire e comprare invece di limitarsi ad aggiungerle lavoro.

Su una piattaforma no-code il markup non lo scrivete voi. Lo genera la piattaforma, quindi l’accessibilità della vostra applicazione è limitata da quella della sua libreria di componenti. Se il suo selettore di date non si usa con la tastiera, o la sua finestra modale trattiene male il focus, non potete rimediare. Potete aprire un ticket di assistenza e aspettare.

Va bene finché il soffitto è abbastanza alto, e diverse piattaforme prendono il problema sul serio. Non va bene quando avete un obbligo preciso, una persona precisa da tutelare o un dovere di ente pubblico, perché il rimedio sta fuori dal vostro controllo e fuori dai vostri tempi.

In uno sviluppo su misura il lavoro sull’accessibilità tocca a voi, il che costa di più all’inizio e toglie la dipendenza. Chiedete a ogni possibile fornitore una dichiarazione di conformità sull’accessibilità prima di disegnare un processo attorno ai suoi componenti, e considerate la sua assenza come una risposta.

Ridurre il rischio di uno sviluppo su misura con una prima fetta sottile

Il modo in cui i progetti su misura falliscono di solito non è tecnico. È impegnare tutto il budget su un capitolato scritto prima che qualcuno avesse usato qualcosa.

L’alternativa è una fetta sottile: un flusso di lavoro, dall’inizio alla fine, in produzione, usato da una persona vera che fa un lavoro vero, in sei o otto settimane. Non un prototipo e non una dimostrazione, ma il percorso più stretto attraverso il sistema che produca un esito autentico, con dati veri, autenticazione vera e rilascio vero. Se il processo è il preventivo, la fetta crea un preventivo, lo quota e lo manda.

Quella fetta fa quattro cose che un capitolato non può fare. Prova le integrazioni, che è dove abitano le sorprese. Misura la velocità reale di consegna della squadra invece di stimarla. Mette software funzionante davanti alla persona di cui è il processo, cosa che ne cambia i requisiti in modo affidabile. E vi dà un’uscita: avete speso una cifra definita e possedete qualcosa che funziona.

Poi mettete lì un punto di decisione, per iscritto, prima di liberare la spesa maggiore. La nostra guida su come costruire una web app tratta la forma tecnica di una prima fetta, e la nostra pagina dei servizi di sviluppo software spiega come ne definiamo una.

Uno schema di decisione che potete percorrere in un pomeriggio

Niente di tutto questo richiede un incarico di consulenza. Richiede qualche ora e onestà sui numeri.

Primo, scrivete il processo come si svolge davvero, per passi, comprese le eccezioni che le persone gestiscono a mano. Questo da solo spesso chiude il dibattito, perché fa emergere che i processi sono tre e non uno.

Secondo, contate le postazioni di oggi e proiettatele su tre anni. Terzo, mettete in lista esattamente tre prodotti e valutateli contro il vostro processo scritto anziché contro i loro elenchi di funzionalità, segnando ogni punto in cui adottarli cambierebbe il vostro modo di lavorare e se quel cambiamento vi costa qualcosa.

Quarto, quantificate la trappola di mezzo in modo esplicito: parcelle di implementazione, middleware e la frazione di stipendio che lo amministrerà. Quinto, applicate il test delle due condizioni su tre. Sesto, calcolate il pareggio in mesi con entrambi i conteggi di postazioni. Settimo, se la risposta è il su misura, commissionate una fetta sottile invece di un sistema.

Chi dovrebbe chiudere questa scheda e andare a comprare qualcosa

Alcuni lettori dovrebbero fermarsi qui, e dirlo chiaramente è più utile di una conclusione equilibrata.

Se il vostro processo è comune e migliaia di aziende lo eseguono più o meno allo stesso modo, comprate il prodotto. Se avete meno di una ventina di utenti e nessuna previsione che lo cambi, comprate il prodotto o costruitelo su una piattaforma no-code, perché il conto a postazione non girerà a vostro favore in nessun orizzonte pianificabile. Se nessuno si prenderà carico del software dopo la consegna, comprate il prodotto, perché un sistema su misura senza padrone decade in fretta in una passività.

Se non sapete descrivere il vostro processo per iscritto, non commissionate ancora nulla. Scrivetelo prima. Molti progetti falliti sono stati commissionati su una descrizione che tre persone nella stessa stanza intendevano in modo diverso, e nessuna quantità di ingegneria ripara quella cosa.

Se vale una sola delle tre condizioni, comprate il prodotto e riguardatela fra un anno. Le condizioni cambiano, di solito perché il numero di persone è cresciuto. E se quello che vi serve davvero è un sito rivolto al pubblico anziché uno strumento interno, quello è un altro progetto, coperto dal nostro lavoro di sviluppo di siti web.

Chiedere un secondo parere prima di impegnarvi

L’errore costoso, in entrambe le direzioni, si commette prima che esista una riga di codice, quindi la cosa meno cara che potete comprare adesso è una valutazione onesta.

Mecanik costruisce applicazioni web operative per aziende britanniche, e gran parte di quel lavoro consiste nel dire alle persone che non ne hanno bisogno. Portate il foglio di calcolo, il numero di postazioni e i tre prodotti che avete selezionato, e la nostra squadra di sviluppo software su misura quoterà una prima fetta sottile oppure vi dirà quale prodotto comprare al suo posto. Se l’applicazione è rivolta ai clienti anziché all’interno, partite dallo sviluppo di siti web e leggete il confronto sviluppo web su misura contro piattaforme SaaS, che copre quel versante della domanda.

Domande frequenti

Quanto costa una web app su misura nel Regno Unito? Un’applicazione interna mirata che sostituisce un foglio di calcolo e uno o due abbonamenti costa di solito fra GBP 25.000 e GBP 60.000 da costruire, di cui una prima fetta sottile assorbe fra GBP 8.000 e GBP 15.000. Mettete a piano ogni anno un ulteriore 15 o 20 per cento del prezzo di costruzione per hosting, patch e aggiornamenti delle dipendenze, perché quel pavimento di costo non arriva mai a zero.

Il no-code è una vera alternativa allo sviluppo di una web app su misura? Sì. Per record, moduli, viste e regole semplici è spesso la risposta giusta ed è molto più rapido. Sbatte contro un muro sui grandi numeri di righe, sui permessi complessi, sull’integrità transazionale, sul controllo di versione e sulle vere macchine a stati. È anche venduto a postazione: Retool indica il piano Business a GBP 40 per sviluppatore e GBP 12 per utente interno al mese, cifra conveniente con dieci postazioni e rilevante con quattrocento.

Con quanti utenti costruire diventa più conveniente che comprare? Dividete il prezzo di costruzione per il risparmio mensile, cioè il costo del prodotto tutto compreso meno hosting più un dodicesimo del budget annuo di manutenzione. Con quaranta utenti una costruzione da GBP 45.000 contro un costo di prodotto mensile di GBP 2.150 rientra in circa 34 mesi. Con quattrocento utenti rientra in meno di un anno, perché le tariffe a postazione crescono con il personale mentre il costo di esercizio di un sistema su misura si muove appena.

Chi risponde della protezione dei dati se compriamo un SaaS invece di costruire? Voi. L’ICO definisce il titolare come il soggetto che determina finalità e mezzi del trattamento, e il vostro fornitore SaaS è quasi sempre il responsabile che agisce su vostra istruzione. Resta a voi dimostrare la conformità, rispondere di quella dei vostri responsabili e avere un contratto ai sensi dell’articolo 28(3). Comprare software sposta il lavoro infrastrutturale, non la responsabilità giuridica.

Le regole di accessibilità valgono anche per strumenti interni che nessuno vede da fuori? Sì. La sezione 20 dell’Equality Act 2010 impone ai datori di lavoro accomodamenti ragionevoli, e uno strumento che non si può usare con la tastiera mette una persona con disabilità in uno svantaggio sostanziale. Le intranet e le extranet del settore pubblico rientrano inoltre nel regolamento sull’accessibilità e devono soddisfare le WCAG 2.2 AA. Su una piattaforma no-code il soffitto dell’accessibilità è fissato dai componenti del fornitore.