Gestionali e software su misura
Un software su misura ha senso quando il processo che vi distingue non entra nel gestionale standard e oggi vive in un foglio Excel che conosce una persona sola. Nella maggior parte dei casi non sostituisce il gestionale: gli si affianca, ne legge e ne scrive i dati, e copre il pezzo che manca. Il primo modulo utilizzabile arriva in 2–3 settimane, non a fine progetto.
Aggiornato: 29 ottobre 2026
I segnali che il gestionale standard non basta più
Sono quasi sempre questi, e di solito ce n'è più di uno:
- C'è un Excel parallelo che regge un processo importante, lo aggiorna una persona sola e nessuno sa bene cosa succede se quella persona è in ferie.
- Lo stesso dato viene inserito due volte in due sistemi diversi, e prima o poi i due numeri non coincidono.
- Avete comprato un modulo che nessuno usa, perché non assomiglia a come lavorate davvero.
- La personalizzazione la chiedete da mesi al fornitore del gestionale, oppure vi è stata quotata come un progetto a sé.
- Il processo in questione è il vostro vantaggio competitivo. È il caso più importante: adattarsi a come lo fanno tutti significa buttare via proprio la cosa per cui i clienti vi scelgono.
Cosa costruisco
- Applicazioni di reparto — produzione, qualità, spedizioni, manutenzione: lo strumento che serve a chi lavora in quel reparto, non un modulo generico.
- Portali interni e cruscotti — i dati che oggi stanno in quattro sistemi, in una schermata sola e aggiornata.
- Portali per clienti e fornitori — stato degli ordini, documenti, listini, conferme: tolgono dal centralino e dalle email una quantità di richieste sorprendente.
- ERP leggeri — quando un gestionale non c'è, o copre solo contabilità e fatturazione e tutto il resto è fuori.
- Estensioni del gestionale che usate già — quando conviene aggiungere invece di affiancare.
.NET / C# · SQL Server · PostgreSQL · Web app · API · Docker
Su misura o pacchetto?
Il su misura non è sempre la risposta giusta, e lo dico anche quando mi converrebbe il contrario: se il processo è standard, un prodotto maturo costa meno, ci mette meno e lo mantiene qualcun altro.
| Meglio un pacchetto | Meglio su misura |
|---|---|
| Processo standard: contabilità, paghe, fatturazione | Processo che vi distingue dai concorrenti |
| Esiste un prodotto maturo per il vostro settore | Nessun prodotto lo copre senza stravolgere come lavorate |
| Serve partire subito con un investimento contenuto | Il costo vero di oggi è il lavoro manuale che fate per aggirare il software |
| Nessuno internamente può seguire il progetto | C'è una persona che conosce il processo e può decidere |
| Il processo cambierà poco | Il processo evolve e dovete poterlo seguire |
Spesso la risposta giusta è mista: il pacchetto per la parte amministrativa, il su misura per il pezzo che vi rende diversi. Quello che non funziona quasi mai è il contrario — comprare un prodotto e poi personalizzarlo tanto da riscriverlo.
Come si affianca a quello che avete già
Nella maggior parte dei progetti non si sostituisce niente. Il gestionale resta la fonte dei dati che hanno valore fiscale, il su misura copre il pezzo scoperto, e i due si parlano attraverso le interfacce che il gestionale espone già.
Il gestionale resta la fonte dei dati anagrafici, dei documenti e di tutto ciò che ha valore fiscale. Il software su misura legge e scrive attraverso le interfacce che il gestionale espone — API, basi dati, scambi di file — e restituisce i risultati lì dove servono.
È una scelta precisa: nessun sistema parallelo che accumula dati suoi e diverge, e nessun bisogno di sostituire ciò che già funziona per aggiungere un pezzo nuovo.
Come si lavora
| Fase | Durata | Cosa succede |
|---|---|---|
| Analisi | 2–3 giorni | Si guarda il processo vero, non quello del manuale; si definisce il primo modulo |
| Primo rilascio | 2–3 settimane | Qualcosa di utilizzabile nelle mani di chi lavora, non una demo |
| Sprint | 1–2 settimane l'uno | Si aggiunge, si corregge, si decide insieme cosa viene dopo |
| Consegna | — | Codice, documentazione e accessi passano a voi; poi manutenzione ed evoluzione |
Il motivo per rilasciare presto non è la velocità: è che le correzioni emergono solo quando qualcuno usa il software per davvero, e a quel punto costano poco. Un progetto consegnato tutto alla fine scopre gli stessi problemi quando sistemarli costa dieci volte tanto.
Le domande che fate sempre
Di chi è il codice?
Vostro. Ve lo consegno documentato e sta in un repository che controllate voi, non io. È la condizione che rende credibile tutto il resto: se il codice non è vostro, ogni evoluzione futura deve per forza passare da chi lo ha scritto.
E se un domani non ci sei più?
È la domanda giusta da fare a un libero professionista, e la risposta sta nelle scelte tecniche, non nelle rassicurazioni. Uso tecnologie diffuse e non esotiche, scrivo codice pensato per essere letto da altri e lo consegno con la documentazione. Un altro sviluppatore deve poterlo riprendere in pochi giorni. Non costruisco niente che possa essere mantenuto solo da me: è una tutela vostra, e francamente anche mia.
Quanto costa mantenerlo?
Un software su misura non è un acquisto una tantum. Cambiano le normative, i fornitori, i formati, il modo di lavorare: il software va dietro. Il budget di manutenzione ed evoluzione va previsto dall'inizio — altrimenti dopo due anni vi ritrovate con lo stesso Excel parallelo da cui eravate partiti, solo con un software in più.
Dove restano i dati?
Dove decidete voi: server in azienda, vostro spazio cloud, o una combinazione. È una scelta da fare all'inizio insieme a quelle su backup e accessi, non da rimandare al rilascio.
Si può partire piccoli?
È il modo che consiglio: un reparto, un processo, un modulo. Se funziona si estende, e si estende su un'esperienza vera invece che su una previsione.
In quale zona lavori?
Analisi e incontri in presenza a Scandiano, Reggio Emilia, Modena, Sassuolo, Carpi, Correggio, Formigine e nella provincia di Mantova; sviluppo e revisioni anche da remoto.
Raccontami quale processo non entra nel gestionale — oppure scrivimi a info@stefanoroteglia.it.
Custom software and business applications
Custom software makes sense when the process that sets you apart does not fit your off-the-shelf system and today lives in a spreadsheet only one person understands. In most cases it does not replace that system: it sits alongside it, reads and writes its data, and covers the missing piece. The first usable module lands in 2–3 weeks, not at the end of the project.
Updated: 29 October 2026
Signs the standard system is no longer enough
It is almost always these, and usually more than one:
- There is a parallel spreadsheet holding up an important process, maintained by one person, and nobody is quite sure what happens when they are on holiday.
- The same data gets entered twice into two different systems, and sooner or later the two numbers disagree.
- You bought a module nobody uses, because it looks nothing like the way you actually work.
- You have been waiting months for a customisation from your software vendor, or it was quoted as a project in its own right.
- The process in question is your competitive advantage. This is the one that matters most: adapting to how everyone else does it throws away exactly what customers choose you for.
What I build
- Departmental applications — production, quality, shipping, maintenance: the tool the people in that department need, not a generic module.
- Internal portals and dashboards — data that today sits in four systems, on one screen and up to date.
- Customer and supplier portals — order status, documents, price lists, confirmations: they take a surprising volume of requests off the phone and out of the inbox.
- Lightweight ERPs — when there is no core system, or it only covers accounting and invoicing and everything else sits outside.
- Extensions to the system you already run — when adding beats sitting alongside.
.NET / C# · SQL Server · PostgreSQL · Web app · API · Docker
Custom or off-the-shelf?
Custom is not always the right answer, and I say so even when the opposite would suit me: if the process is standard, a mature product costs less, takes less time, and someone else maintains it.
| Off-the-shelf wins | Custom wins |
|---|---|
| Standard process: accounting, payroll, invoicing | A process that sets you apart from competitors |
| A mature product exists for your sector | No product covers it without upending how you work |
| You need to start now with a contained budget | Today's real cost is the manual work you do to get around the software |
| Nobody internally can follow the project | Someone knows the process and can make decisions |
| The process will barely change | The process evolves and you need to keep up |
Often the right answer is a mix: off-the-shelf for the administrative side, custom for the part that makes you different. What almost never works is the reverse — buying a product and then customising it so heavily that you have effectively rewritten it.
How it sits alongside what you have
In most projects nothing gets replaced. The standard system remains the source of anything with fiscal weight, the custom part covers what is missing, and the two talk through interfaces the system already exposes.
Your existing system stays the source of master data, documents and anything with fiscal weight. The custom software reads and writes through the interfaces that system exposes — APIs, databases, file exchanges — and returns results where they are needed.
That is a deliberate choice: no parallel system accumulating its own data and drifting apart, and no need to replace something that works in order to add something new.
How the work runs
| Phase | Duration | What happens |
|---|---|---|
| Analysis | 2–3 days | We look at the real process, not the one in the manual; the first module is defined |
| First release | 2–3 weeks | Something usable in the hands of the people doing the work, not a demo |
| Sprints | 1–2 weeks each | Add, correct, and decide together what comes next |
| Handover | — | Code, documentation and access pass to you; then maintenance and evolution |
The reason to release early is not speed: it is that corrections only surface when someone really uses the software, and at that point they are cheap. A project delivered all at the end discovers the same problems when fixing them costs ten times as much.
The questions you always ask
Who owns the code?
You do. It is handed over documented and lives in a repository you control, not I. That is the condition that makes everything else credible: if the code is not yours, every future change has to go through whoever wrote it.
What if one day you are not around?
That is the right question to ask a freelancer, and the answer lies in technical choices, not reassurances. I use widespread, unexotic technologies, write code meant to be read by others, and hand it over documented. Another developer should be able to pick it up in days. I do not build anything only I can maintain: that protects you, and frankly me too.
What does it cost to maintain?
Custom software is not a one-off purchase. Regulations, suppliers, formats and ways of working change, and the software follows. Budget for maintenance and evolution from the start — otherwise in two years you are back to the same parallel spreadsheet, only with an extra piece of software.
Where does the data live?
Wherever you decide: a server on your premises, your own cloud space, or a combination. It is a decision to make at the start alongside backups and access, not one to leave until release.
Can we start small?
That is what I recommend: one department, one process, one module. If it works you extend, and you extend on real experience rather than a forecast.
Which area do you cover?
Analysis and meetings on site in Scandiano, Reggio Emilia, Modena, Sassuolo, Carpi, Correggio, Formigine and the province of Mantua; development and reviews also remotely.
Tell me which process does not fit your system — or email me at info@stefanoroteglia.it.