Preventivi da Freelance Developer: Template e Strategie di Pricing
Perché il preventivo è il tuo strumento di vendita più potente nel 2026
La maggior parte dei developer freelance tratta il preventivo come una formalità: qualche voce in una email, un totale in fondo, e via. Poi si chiede perché il cliente risponde con “ci penso” oppure contratta ogni singola riga. Il problema non è il prezzo — è la struttura. Un preventivo professionale non è solo un documento contabile, è il primo segnale concreto di come lavori. Se è vago, trasmette incertezza. Se è dettagliato e ben organizzato, trasmette competenza e rassicura il cliente prima ancora che il progetto inizi.
Nel 2026 il mercato freelance è più competitivo che mai: ci sono developer che lavorano in outsourcing a tariffe bassissime, agenzie che propongono pacchetti all-inclusive, e strumenti AI che fanno credere ai clienti che certe cose “si possano fare in cinque minuti”. In questo contesto, il modo in cui presenti il tuo lavoro diventa determinante. Se hai già letto come alzare le tariffe senza perdere clienti, sai che il problema raramente è il prezzo assoluto — è la percezione del valore. Un buon preventivo costruisce quella percezione prima ancora della prima call.
In questa guida ti mostro una struttura testata, template reali con esempi di codice per automatizzare la generazione dei documenti, e le strategie di pricing che usano i developer più pagati sul mercato. Niente teoria astratta: solo strumenti che puoi implementare subito.
La struttura del preventivo professionale
Un preventivo efficace ha una struttura precisa che guida il cliente verso il sì senza forzarlo. Ecco le sezioni essenziali, nell’ordine corretto:
- Executive summary — 3-5 righe che sintetizzano il problema del cliente e la tua soluzione proposta
- Scope del progetto — cosa è incluso, con dettaglio funzionale (non tecnico)
- Fuori scope — la sezione che ti salverà da infinite richieste extra
- Breakdown costi — voce per voce, con ore stimate o prezzi fissi per fase
- Timeline e milestone — quando consegni cosa, legato ai pagamenti
- Termini di pagamento — anticipo, milestone, saldo
- Validità del preventivo — solitamente 15-30 giorni
La sezione “fuori scope” è quella che i developer junior dimenticano sempre e che costa cara. Devi scrivere esplicitamente cosa non farai: contenuti, grafica, copywriting, integrazioni non specificate, SEO, formazione al cliente. Se non è scritto nero su bianco, il cliente assume che sia incluso — e hai perso la discussione prima di iniziarla. Questa logica si allinea perfettamente con quanto discusso nell’articolo sui contratti freelance e le clausole essenziali.
Template preventivo in Markdown e generazione PDF automatica
Invece di riscrivere il preventivo ogni volta da zero in Word o Google Docs, il modo più efficiente è usare un template in Markdown e generare il PDF con uno script. Questo ti permette di avere controllo sulla versione, usare variabili, e automatizzare la parte ripetitiva.
Ecco un template base in Markdown con variabili segnaposto:
# Preventivo — {{ project_name }}
**Data:** {{ date }}
**Valido fino al:** {{ expiry_date }}
**Riferimento:** {{ quote_ref }}
---
## Riepilogo
{{ client_name }}, hai bisogno di {{ problem_summary }}.
Propongo di realizzare {{ solution_summary }} entro {{ timeline }}.
---
## Scope del progetto
### Incluso
{{ scope_included }}
### Fuori scope
- Contenuti testuali e copywriting
- Grafica e illustrazioni non specificate
- Hosting e domini (salvo accordo separato)
- Formazione utenti oltre 2 ore di onboarding
- {{ custom_exclusions }}
---
## Breakdown costi
| Fase | Descrizione | Ore est. | Tariffa | Totale |
|------|-------------|----------|---------|--------|
{{ cost_rows }}
**Totale progetto: {{ total }}**
---
## Termini di pagamento
- 30% anticipo alla firma (€ {{ deposit }})
- 40% al rilascio della versione beta (€ {{ milestone }})
- 30% al collaudo finale (€ {{ final }})
---
## Timeline
{{ timeline_details }}
---
*Preventivo valido 15 giorni dalla data di emissione.*
*Per procedere, rispondere per email con conferma scritta.*Ora lo script Python che compila il template e genera il PDF tramite weasyprint o, più semplicemente, tramite pandoc:
#!/usr/bin/env python3
# Genera un preventivo PDF da template Markdown.
# Dipendenze: pip install jinja2 && brew install pandoc
import subprocess
from datetime import date, timedelta
from pathlib import Path
import jinja2
TEMPLATE_DIR = Path("./templates")
OUTPUT_DIR = Path("./preventivi")
OUTPUT_DIR.mkdir(exist_ok=True)
def render_quote(data: dict) -> str:
loader = jinja2.FileSystemLoader(str(TEMPLATE_DIR))
env = jinja2.Environment(loader=loader)
tmpl = env.get_template("preventivo.md")
return tmpl.render(**data)
def md_to_pdf(md_content: str, output_path: Path) -> None:
md_file = output_path.with_suffix(".md")
md_file.write_text(md_content, encoding="utf-8")
subprocess.run([
"pandoc", str(md_file),
"-o", str(output_path),
"--pdf-engine=wkhtmltopdf",
"--variable", "geometry:margin=2cm",
"--variable", "fontsize=11pt",
], check=True)
md_file.unlink()
print(f"PDF generato: {output_path}")
if __name__ == "__main__":
today = date.today()
data = {
"project_name": "Sito E-commerce Personalizzato",
"client_name": "Mario Rossi / Esempio SRL",
"date": today.strftime("%d/%m/%Y"),
"expiry_date": (today + timedelta(days=15)).strftime("%d/%m/%Y"),
"quote_ref": f"QT-{today.strftime('%Y%m%d')}-001",
"problem_summary": "un e-commerce moderno con gestione ordini integrata",
"solution_summary": "una web app Next.js + Stripe con pannello admin custom",
"timeline": "6 settimane",
"scope_included": (
"- Frontend Next.js con design responsivo
"
"- Integrazione Stripe (pagamenti one-time e abbonamenti)
"
"- Pannello admin per gestione prodotti e ordini
"
"- Deploy su Vercel + database Supabase
"
"- 2 ore di onboarding e documentazione"
),
"custom_exclusions": "Gestione magazzino fisica e integrazioni ERP",
"cost_rows": (
"| Design UI/UX | Wireframe + mockup | 12 | €90/h | €1.080 |
"
"| Frontend | Sviluppo Next.js | 30 | €90/h | €2.700 |
"
"| Backend | API + DB Supabase | 20 | €90/h | €1.800 |
"
"| Integrazione Stripe | Pagamenti + webhook | 10 | €90/h | €900 |
"
"| Testing + Deploy | QA, CI/CD, Vercel | 8 | €90/h | €720 |"
),
"total": "€7.200",
"deposit": "2.160",
"milestone": "2.880",
"final": "2.160",
"timeline_details": (
"- Settimana 1-2: Design e approvazione mockup
"
"- Settimana 3-4: Sviluppo frontend e backend
"
"- Settimana 5: Integrazione Stripe e test
"
"- Settimana 6: Deploy, onboarding e collaudo finale"
),
}
md = render_quote(data)
md_to_pdf(md, OUTPUT_DIR / f"preventivo-{data['quote_ref']}.pdf")
Strategie di pricing: tariffa oraria vs prezzo fisso vs valore
La scelta del modello di pricing è probabilmente la decisione più impattante sulla tua redditività come freelance. Esistono tre approcci principali, ciascuno con pro e contro ben precisi:
Tariffa oraria: il modello più semplice e quello più usato dai developer alle prime armi. La trasparenza è il vantaggio principale: il cliente sa esattamente come viene calcolato il costo. Lo svantaggio è che ti penalizza quanto sei efficiente — se finisci prima, guadagni meno. Adatto per lavori consulenziali, bugfixing, supporto continuativo. Se non hai ancora definito la tua tariffa di riferimento, l’articolo su come fissare le tariffe da freelance developer nel 2026 è il punto di partenza giusto.
Prezzo fisso: ideale quando lo scope è ben definito e hai esperienza con progetti simili. Puoi guadagnare di più se sei veloce, ma rischi di perderci se il progetto si espande. La chiave è aggiungere un buffer del 20-30% alle stime iniziali e definire in modo chirurgico cosa è incluso.
Value-based pricing: il modello avanzato che ti permette di sganciare il prezzo dalle ore lavorate. Il principio: il prezzo è basato sul valore che il progetto genera per il cliente, non sul tempo che ci metti. Un e-commerce che genererà 500K€/anno di fatturato vale molto di più di 80 ore di sviluppo. Per applicare questo modello devi capire i KPI del cliente e quantificare il ritorno atteso. È il modello usato dai developer che fatturano oltre 100K€/anno.
// Calcolatore value-based pricing (Node.js)
// Stima il prezzo in base al valore generato per il cliente
function calculateValuePrice(params) {
const {
expectedRevenue, // fatturato atteso dal progetto (€/anno)
revenueIncrease, // % aumento ricavi atteso (es. 0.15 = 15%)
timeToROI, // mesi per raggiungere il ROI
complexityMultiplier, // 1.0 = normale, 1.5 = alta complessità
yourValueShare, // % del valore che chiedi (tipico: 0.10-0.20)
} = params;
// Valore generato nel primo anno
const yearOneValue = expectedRevenue * revenueIncrease;
// Valore ponderato per il tempo di ROI
const adjustedValue = yearOneValue * (12 / timeToROI);
// Prezzo base value-based
const basePrice = adjustedValue * yourValueShare;
// Aggiustamento per complessità tecnica
const finalPrice = basePrice * complexityMultiplier;
return {
yearOneValue: Math.round(yearOneValue),
adjustedValue: Math.round(adjustedValue),
suggestedPrice: Math.round(finalPrice / 100) * 100, // arrotonda ai 100
priceRange: {
min: Math.round(finalPrice * 0.85 / 100) * 100,
max: Math.round(finalPrice * 1.15 / 100) * 100,
},
};
}
// Esempio: e-commerce per cliente con 300K€ fatturato attuale
const result = calculateValuePrice({
expectedRevenue: 300_000,
revenueIncrease: 0.20, // +20% fatturato atteso
timeToROI: 6, // ROI in 6 mesi
complexityMultiplier: 1.2,
yourValueShare: 0.12, // chiedi il 12% del valore generato
});
console.log("Valore anno 1:", result.yearOneValue, "€");
// → 60.000 €
console.log("Prezzo suggerito:", result.suggestedPrice, "€");
// → ~8.640 €
console.log("Range:", result.priceRange);
// → { min: 7.300, max: 9.900 }
Questo approccio funziona particolarmente bene quando abbini al progetto una componente di automazione che riduce i costi operativi del cliente. Se stai integrando workflow automatizzati — ad esempio con n8n o Make per automazioni business — puoi quantificare il risparmio in ore/mese e usarlo come leva di pricing.
Gestire le revisioni e il temuto scope creep
Lo scope creep è il nemico numero uno della redditività freelance. “Aggiungiamo solo questo bottone”, “non avevamo pensato a questa funzione”, “puoi fare anche…”. Ogni richiesta non preventivata erode il tuo margine. La soluzione non è dire di no — è strutturare le revisioni nel preventivo in modo professionale.
La formula che funziona:
- Round di revisione inclusi: definisci quante revisioni sono comprese (es. 2 round per fase)
- Procedura di change request: ogni modifica fuori scope viene quotata prima di essere implementata
- Impatto sulla timeline: ogni change request approvata sposta la data di consegna
- Approvazione scritta: nessuna modifica viene implementata senza conferma scritta del cliente
Nel preventivo scrivi esplicitamente: “Sono inclusi 2 round di revisione per fase. Modifiche aggiuntive saranno quotate a €90/ora con un minimo di 2 ore. Ogni change request approvata impatterà sulla timeline di 3-5 giorni lavorativi.” Questa singola clausola, scritta in modo chiaro e professionale, riduce le discussioni del 70%.
Automatizzare il follow-up e il tracking dei preventivi
La maggior parte dei preventivi non vengono persi per il prezzo, ma per la mancanza di follow-up. Il cliente è distratto, ha altre priorità, e il tuo preventivo finisce in archivio. Un sistema automatizzato di reminder ti permette di rimanere top-of-mind senza sembrare disperato.
Ecco un mini-sistema di tracking in TypeScript con reminder automatici — un esempio di come puoi integrare questo con un database come Supabase (che abbiamo approfondito nella guida su Supabase nel 2026):
// quote-tracker.ts
// Sistema di tracking preventivi con follow-up automatici
// Stack: TypeScript + Supabase + Resend
import { createClient } from "@supabase/supabase-js";
import { Resend } from "resend";
const supabase = createClient(
process.env.SUPABASE_URL!,
process.env.SUPABASE_SERVICE_KEY!
);
const resend = new Resend(process.env.RESEND_API_KEY!);
interface Quote {
id: string;
client_name: string;
client_email: string;
amount: number;
sent_at: string;
status: "sent" | "viewed" | "accepted" | "rejected" | "expired";
follow_up_count: number;
}
// Controlla preventivi in attesa di risposta e invia follow-up
async function processFollowUps(): Promise<void> {
const threeDaysAgo = new Date();
threeDaysAgo.setDate(threeDaysAgo.getDate() - 3);
const { data: quotes, error } = await supabase
.from("quotes")
.select("*")
.eq("status", "sent")
.lt("sent_at", threeDaysAgo.toISOString())
.lt("follow_up_count", 2); // max 2 follow-up automatici
if (error || !quotes?.length) return;
for (const quote of quotes as Quote[]) {
await sendFollowUp(quote);
await supabase
.from("quotes")
.update({ follow_up_count: quote.follow_up_count + 1 })
.eq("id", quote.id);
}
}
async function sendFollowUp(quote: Quote): Promise<void> {
const followUpNumber = quote.follow_up_count + 1;
const subject =
followUpNumber === 1
? `Seguito: preventivo per ${quote.client_name}`
: `Ultima disponibilità: preventivo in scadenza`;
await resend.emails.send({
from: "Gioacchino <hello@gioacchinomazzoleni.com>",
to: quote.client_email,
subject,
html: `
<p>Ciao ${quote.client_name},</p>
<p>ti scrivo per il preventivo di ${quote.amount.toLocaleString("it-IT")}€
inviato qualche giorno fa.</p>
${
followUpNumber === 1
? "<p>Hai avuto modo di valutarlo? Sono disponibile per qualsiasi chiarimento.</p>"
: "<p>Il preventivo scade tra 5 giorni. Se vuoi procedere, fammi sapere entro venerdì.</p>"
}
<p>A presto,<br>Gioacchino</p>
`,
});
}
// Esegui ogni giorno (cron job)
processFollowUps().catch(console.error);
Questo sistema si integra perfettamente con un workflow di automazione più ampio. Se stai costruendo una pipeline commerciale automatizzata, può valere la pena leggere come automatizzare la gestione email con n8n e Claude AI — le due cose si complementano bene.
Presentare il preventivo: format e contesto
Un preventivo inviato “a freddo” via email, senza contesto, converte male. Il modo corretto è strutturare una breve call di presentazione — 20-30 minuti — in cui accompagni il cliente attraverso il documento. Questo ti permette di rispondere alle obiezioni in tempo reale e di modificare eventuali voci prima che il cliente elabori un no definitivo.
Se non riesci a organizzare una call, invia il preventivo con una email di accompagnamento strutturata così:
- Oggetto: “Preventivo [Nome Progetto] — [tuo nome]” (niente “FW:” o titoli generici)
- Prima riga: richiama il problema che hai discusso insieme
- Secondo paragrafo: 3 punti salienti dell’approccio proposto
- Terzo paragrafo: next step chiari (“Se vuoi procedere, rispondimi entro [data] e organizziamo una call di kickoff”)
- PS: indica la data di scadenza del preventivo
Il PS è importante: crea urgenza senza essere aggressivo. I clienti che ricevono preventivi senza scadenza tendono a rimandare indefinitamente la decisione.
Se vuoi approfondire come posizionarti e trovare clienti di qualità — quelli che non contrattano su ogni riga — leggi anche la guida su trovare clienti come freelance developer nel 2026. La qualità del preventivo e la qualità del cliente si influenzano a vicenda: più sei selettivo, più puoi permetterti di presentare preventivi dettagliati e ben strutturati.
FAQ e Domande Frequenti
Quante ore includo nel preventivo per buffer di sicurezza?
La regola pratica più usata è aggiungere il 25-30% alle stime iniziali per i progetti a prezzo fisso. Se stimi 40 ore, preventiva 52. Questo copre le impreviste, le riunioni non pianificate, i refactoring richiesti dal cliente, e il tempo di testing spesso sottostimato. Per i clienti nuovi, aumenta il buffer al 35-40% finché non hai calibrato bene il loro modo di lavorare. Con i clienti abituali puoi abbassarlo gradualmente. Mai togliere il buffer completamente: i progetti che sembrano più semplici sono spesso quelli che riservano le sorprese peggiori.
È meglio inviare il preventivo in PDF o in un link condivisibile?
Dipende dal contesto. Il PDF è più formale e professionale, adatto a clienti aziendali e progetti sopra i 5K€. Un link condivisibile (tramite strumenti come HoneyBook, Bonsai o un semplice Notion) ti permette di sapere quando il cliente ha aperto il documento — informazione preziosa per calibrare il timing del follow-up. Per progetti sotto i 3K€ e clienti informali, anche un’email strutturata con breakdown chiaro può bastare. L’importante è che il documento sia leggibile su mobile, perché molti clienti leggono le email dal telefono durante la pausa pranzo.
Come gestire il cliente che chiede uno sconto?
Mai abbassare il prezzo senza ridurre lo scope. Se un cliente chiede uno sconto del 20%, la risposta professionale è: “Posso arrivare a quel budget rimuovendo [funzionalità specifica]. Vuoi che rivediamo insieme le priorità?”. Questo sposta la conversazione dal prezzo al valore e mette il cliente in posizione di scegliere cosa tagliare — non tu. Nella maggior parte dei casi, il cliente preferisce pagare il prezzo pieno piuttosto che rinunciare a funzionalità che ritiene importanti. Se invece vuole davvero pagare meno e togliere scope, hai comunque mantenuto la tua tariffa oraria. Non esiste motivo valido per abbassare il prezzo mantenendo lo stesso scope: comunica che il tuo lavoro vale meno di quello che hai detto inizialmente.
Devo chiedere un anticipo? Quanto?
Sì, sempre, senza eccezioni. L’anticipo non è solo una protezione finanziaria — è un segnale di commitment reciproco. Un cliente che non vuole pagare l’anticipo è un cliente che non è sicuro di voler procedere, e quel dubbio esploderà in qualche momento del progetto. Lo standard del mercato è 30% alla firma, con il saldo diviso in milestone. Per progetti brevi (sotto 2 settimane) puoi chiedere il 50% all’inizio. Per clienti nuovi con progetti grandi, considera di chiedere il 40%. Non scendere mai sotto il 25%: stai investendo il tuo tempo e devi coprire almeno i costi delle prime settimane di lavoro.
Conclusione
Un preventivo ben strutturato è uno strumento di vendita, non un documento burocratico. La differenza tra un developer che compete sul prezzo e uno che impone le proprie tariffe sta quasi sempre nella qualità della proposta commerciale — non nelle competenze tecniche. I clienti migliori, quelli che pagano bene e rispettano il tuo lavoro, si aspettano professionalità prima ancora di vedere una riga di codice. Il preventivo è il tuo biglietto da visita operativo.
Inizia da un template solido, definisci chiaramente lo scope e il fuori scope, scegli il modello di pricing più adatto al progetto, e automatizza il follow-up. Con questi elementi in ordine, il tasso di chiusura migliora significativamente — e puoi concentrarti su ciò che ti piace davvero fare: scrivere codice di qualità.
Se vuoi portare la tua attività freelance al livello successivo — con posizionamento, tariffe e pipeline commerciale ottimizzati — visita gioacchinomazzoleni.com per scoprire come lavoro con i developer freelance che vogliono scalare il loro business.
Suggerimenti e Risorse
🔧 Tool consigliato: Bonsai (hellobonsai.com) è uno dei migliori strumenti per freelance developer: preventivi, contratti, time tracking e fatturazione in un’unica piattaforma. Ha template pre-compilati per progetti tech e ti avvisa quando il cliente apre il documento.
💡 Pro tip: Prima di inviare qualsiasi preventivo, leggi ad alta voce la sezione “fuori scope”. Se ti sembra ovvio che qualcosa non è incluso, il cliente probabilmente pensa l’opposto. Aggiungi quella voce alla lista — non può fare male.
🎯 Strategia: Crea 3 varianti del preventivo (base, standard, premium) con scope crescente e presentale insieme. La ricerca sul comportamento d’acquisto mostra che il 60-70% dei clienti sceglie l’opzione centrale quando sono presentate tre scelte — spingendoti verso il budget che ti soddisfa davvero.
