Fin dal principio la realizzazione dell'intero gestionale è stata pensata a partire da un foglio bianco perché volevamo evitare che lo sviluppo fosse influenzato dalle funzionalità del gestionale preesistente. Il cliente non era soddisfatto della soluzione precedente, quindi non aveva senso replicarne le funzionalità: PrimoUp doveva essere pensato da zero. L'obiettivo era permettere una completa personalizzazione del software che avrebbe dovuto aderire perfettamente al flusso di lavoro di Primo. Così il nostro team si è trovato a dover rispondere al fianco del cliente a tutti i problemi che si presentavano e a dover trovare e applicare di volta in volta la migliore soluzione possibile.
Il software doveva essere pensato in modo che crescesse insieme all'azienda perciò erano fondamentali fin da subito alcune caratteristiche strutturali.
Espansione incrementale
Il software doveva essere progettato perché ampliasse le funzionalità di pari passo con l'espansione dell'azienda, per cui una delle sfide iniziali è stata quella di progettarlo in modo da assecondare l'evoluzione continua della società. Evoluzione che non aveva una direzione iniziale, per cui PrimoUp avrebbe dovuto risolvere in maniera incrementale i problemi che di volta in volta si presentavano. Questo tipo di evoluzione doveva essere portata avanti facendo in modo che il software non crescesse in maniera disordinata, ogni nuova funzionalità doveva essere pensata in ottica di espansione continua.
Software blindato e su misura
Ad ogni Sprint Meeting il cliente esprimeva le sue necessità e condivideva con il nostro team di sviluppo il proprio modo di lavorare in modo che noi potessimo portare le proposte di UX e UI in modo da andare incontro alle esigenze di utilizzo di ogni utente. Primo Up, a differenza di un Saas, doveva essere un software blindato, nel senso che le funzionalità dovevano permettere a chi avrebbe utilizzato il software di eseguire solamente le operazioni previste dal flusso di lavoro e fare in modo che queste non potessero essere modificate da una volta all'altra senza una direzione.
Architettura server distribuita
Bisognava infine garantire un'architettura server tale da poter sopportare il peso del software. trattandosi di un gestionale utilizzato da molti reparti all'interno della società (medici, clinic manager, amministrazione, reparto marketing, ecc...), sarebbe stato sottoposto a frequenti picchi di utilizzo e bisognava trovare una struttura tale da permettere al software di reggere questi carichi elevati, cosa non banale per un'applicazione così complessa. La soluzione è stata quella di trovare una architettura server distribuita dove il carico sarebbe stato bilanciato su diversi server, in modo da distribuire il peso su diverse macchine. Lo stesso ragionamento avrebbe dovuto riguardare il database.