Ani de zile am crezut că portofoliul de dev înseamnă o listă kilometrică de linkuri către GitHub și screenshot-uri arătoase. Realitatea m-a lovit când am realizat că un client cu buget nu dă doi bani pe un repository curat cu un ToDo app în React. Dacă vrei contracte plătite decent ca freelancer, ai nevoie de fix trei proiecte prezentate ca studii de caz, axate pe cifre.
De ce 10+ proiecte pe site îți omoară conversia
Când aplicam la clienți străini prin 2018, le trimiteam link către un site personal plin cu vreo 12 proiecte. Aveam de toate: teme de WordPress, mici aplicații de chat, dashboard-uri copiate din tutoriale. Rata mea de răspuns era jenantă, undeva sub 5%.
Problema? Paradoxul alegerii și lipsa de context. Un om de afaceri nu are timp să dea click prin 6 demo-uri ca să ghicească ce știi tu să faci. Când vede o listă uriașă de mini-aplicații fără trafic, presupune instant că ești junior care bifează tehnologii. În momentul în care am șters tot și am lăsat doar 3 proiecte reale explicate în detaliu, rata de răspuns la cold pitches a sărit la aproape 28%.
Cele 3 tipare de proiecte care vând
Nu ai nevoie de proiecte gigant. Ai nevoie de proiecte care acoperă trei dureri fundamentale de business:
- Optimizarea de performanță (bani direct în buzunar): La un magazin online de piese auto, timpul de încărcare era de 4.2 secunde pe mobil. Am rescris frontend-ul, am scăzut TTFB-ul și am redus bundle-ul JS cu 65%. Rezultatul măsurabil? Timp de încărcare sub 1.2 secunde și o scădere a ratei de abandon în coș cu 14% în prima lună.
- Automatizarea unui proces intern (economie de timp): Un client pierdea zilnic câte 3 ore sincronizând manual stocurile din e-Factura într-un CRM obscur. I-am făcut un script simplu pe un cron job cu validări de erori pe Slack. În studiu de caz n-am vorbit despre arhitectură, ci despre cum echipa lui a salvat 60 de ore de muncă manuală pe lună.
- Proiectul cap-coadă livrat la termen (încredere): O aplicație MVP pentru un startup local. Trade-off-ul sincer pe care l-am menționat în case study: am ales intenționat un monolit clasic în detrimentul microserviciilor ca să putem lansa în 5 săptămâni, nu în 6 luni. Clienții apreciază pragmatismul, nu supra-ingineria.
Structura pe care o folosesc la fiecare case study
Fiecare pagină de proiect are maxim 500 de cuvinte și respectă o schemă matematică:
- Contextul: Cine era clientul și ce problemă îl costa bani (fără detalii tehnice aici).
- Blocajul: De ce nu a funcționat ce încercaseră înainte sau ce barieră tehnică exista.
- Soluția tehnică și compromisul: Ce am implementat și de ce am refuzat alte opțiuni mai complexe.
- Rezultatul măsurabil: Cifra finală. Procente, secunde scăzute sau ore economisite.
Trade-off-ul acestei abordări e că necesită efort serios de documentare. Îți ia lejer două weekenduri să scoți datele, să iei testimonialul de la client și să comprimi textul până devine ușor de parcurs. Dar diferența e masivă: nu mai ești văzut ca un simplu executant care scrie cod cu ora, ci ca un consultant care rezolvă probleme.
Voi cum vă prezentați munca pe site acum — listă de repository-uri sau povești centrate pe client?