Emitera: aplicație SaaS pentru facturare electronică și RO e-Factura
Un site de prezentare se judecă după câte telefoane produce. O aplicație se judecă după cât de mult din munca unui om preia. Sunt două meserii diferite, iar asta e a doua.
Aplicație SaaS — produs propriu
01 /Contextul proiectului
Ce e Emitera și de ce am construit-o
Emitera e produsul meu, nu o lucrare plătită de un client. O scriu de la început, ca să nu existe confuzie: tot ce urmează e despre ce am construit pentru mine, nu despre un rezultat livrat altcuiva.
E o platformă de facturare pentru firme din România, cu facturi, clienți, cheltuieli și rapoarte financiare într-un singur produs, plus comunicare OAuth cu sistemul RO e-Factura al ANAF. Nișa e dictată de lege, nu de gust: firmele nu aleg dacă trimit facturile electronic, ci doar cu ce unealtă o fac. Asta schimbă complet regulile — o eroare de integrare nu e un bug de UI, e o factură care nu ajunge la ANAF.
02 /Constrângeri
Ce dicta, de fapt, forma site-ului
Fiecare decizie de mai jos vine dintr-una din constrângerile astea. Fără ele, ar fi rămas doar preferințe de design.
Integrarea cu ANAF nu iartă aproximări
RO e-Factura are format impus, autentificare OAuth și un sistem care răspunde cu erori pe care utilizatorul final nu are cum să le descifreze. Aplicația trebuie să gestioneze token-uri, retrimiteri și stări intermediare — o factură poate fi trimisă, în așteptare sau respinsă, iar utilizatorul trebuie să înțeleagă în ce stare e fără să citească documentație tehnică.
Datele financiare cer alt nivel de securitate
Într-un site de prezentare, cel mai rău lucru care se poate întâmpla e un formular de spam. Aici vorbim de facturi, coduri fiscale și date de firmă. Nivelul de protecție nu e opțional, iar decizia asta se ia la început, în arhitectură, nu la final, cu un plugin.
Un produs cu abonament are nevoie de infrastructură de produs
Nu doar aplicația: pagini legale, politică de anulare și rambursare, termeni, cookies, contact. Fără ele nu poți încasa abonamente și nu treci de verificările procesatorilor de plăți. E partea de care nimeni nu vorbește, dar fără care produsul nu există comercial.
03 /Abordarea
Deciziile luate și motivul din spatele fiecăreia
Un site nu e o listă de secțiuni. E o serie de decizii care fie duc vizitatorul la contact, fie îl pierd pe drum.
- 01
Aplicație, nu site — și asumat ca atare
Frontend-ul e o aplicație pe o singură pagină, servită de nginx: browserul primește un schelet HTML de 4,5 KB și construiește interfața din JavaScript. E alegerea corectă pentru o unealtă în care omul stă și lucrează, cu ecrane de facturi și tabele care se actualizează fără reîncărcare. Costul e real și îl scriu pe față: pagina publică nu are conținut pentru motoarele de căutare, așa că Emitera nu se promovează prin SEO organic pe pagina principală. Pentru un produs care se vinde prin campanii și recomandări, e un compromis acceptat, nu o scăpare.
- 02
API-ul e separat și închis by default
Interfața și API-ul sunt două lucruri distincte. Orice cerere către rutele de date primește 401 fără sesiune validă — se poate verifica din exterior, oricine poate încerca. Separarea asta e ce permite ca mâine să existe o aplicație de mobil peste același API, fără să rescriu logica de business.
- 03
Politici de securitate scrise, nu presupuse
Content-Security-Policy cu surse enumerate una câte una și hash-uri pentru scripturile inline, HSTS pe un an cu subdomenii, Cross-Origin-Opener-Policy, Referrer-Policy „no-referrer”, permisiuni de cameră și microfon revocate explicit. Aplicația refuză să fie încărcată în iframe de pe alt domeniu. Sunt lucruri care nu se văd în interfață și pe care nu ți le cere niciun client, dar care fac diferența într-un produs care ține date financiare.
- 04
Autentificare cu Google, pe lângă cea clasică
Politica de securitate a paginii permite explicit doar biblioteca de sign-in Google, nimic altceva. Un cont nou se face în câteva secunde, fără încă o parolă de ținut minte — la un produs cu abonament, frecarea de la înregistrare e primul loc unde pierzi utilizatori.
- 05
Shell-ul nu se cache-uiește niciodată
Scheletul aplicației e servit cu „no-store”, în timp ce fișierele de JavaScript și CSS au hash în nume. Efectul: la fiecare versiune nouă utilizatorii primesc imediat codul nou, fără să rămână blocați pe o versiune veche din cache-ul browserului — problema clasică a aplicațiilor pe o singură pagină, care produce erori imposibil de reprodus.
- 06
Partea comercială, tratată ca parte din produs
Sitemap-ul public are 6 rute și patru dintre ele sunt legale: termeni, confidențialitate, cookies, anulare și rambursare. Plus contact. Un SaaS pe abonament fără paginile astea nu e un SaaS, e un demo.
04 /Ce s-a livrat
Inventarul paginii live, nu o listă de promisiuni
Tot ce urmează există acum pe emitera.ro și se poate verifica deschizând site-ul sau sursa paginii.
Aplicația
- Rute de aplicație pentru autentificare, înregistrare, panou, facturi, clienți, cheltuieli, rapoarte și setări
- Frontend construit pe Angular, livrat ca aplicație pe o singură pagină
- API separat, care răspunde 401 la cereri neautentificate
- Conexiune WebSocket permisă în politica de securitate, pentru actualizări în timp real
Integrări
- Comunicare OAuth cu RO e-Factura (ANAF)
- Autentificare cu Google, singura sursă externă de script permisă
- Fără servicii terțe de analiză: politica de securitate nu permite conexiuni de date în afara domeniului propriu
Securitate și livrare
- Content-Security-Policy cu surse enumerate și hash-uri pentru scripturi inline
- HSTS 1 an cu includeSubDomains, HTTP/2 cu HTTP/3 anunțat
- Cross-Origin-Opener-Policy, Referrer-Policy „no-referrer”, X-Content-Type-Options
- Permissions-Policy: microfon, geolocație, plăți și USB revocate explicit
Partea publică
- Date structurate SoftwareApplication cu categoria BusinessApplication și prețul afișat
- Meta description, canonical și 9 tag-uri Open Graph
- Manifest PWA, set complet de favicon-uri și temă de culoare
- sitemap.xml cu 6 rute și robots.txt, ambele răspund 200
05 /Fapte măsurate
Cifre de pe site-ul live, cu metoda alături
Nu scriu creșteri de trafic sau număr de lead-uri: nu sunt date publice, deci nu le poți verifica. Astea se pot verifica, iar dacă între timp s-au schimbat, măsoară din nou.
Schelet HTML livrat
1,6 KB
4,5 KB necomprimat
Cod de aplicație la prima vizită
≈202 KB
comprimat; 733 KB necomprimat
Răspuns API fără sesiune
401
pe /invoices, /clients, /reports
Rute publice în sitemap
6
Mod de livrare
no-store
shell-ul nu rămâne blocat în cache
Timp până la primul byte
nemăsurabil corect
vezi nota de mai jos
Cum am măsurat · 6 august 2026
Aici lipsește intenționat cifra pe care ai găsi-o pe celelalte case study-uri: timpul de răspuns. Emitera e găzduită pe același server de pe care rulez măsurătorile, așa că orice valoare aș scrie ar fi între 13 și 27 ms — un număr care arată spectaculos și care nu înseamnă nimic, fiindcă pachetele nu ies în internet. L-aș fi putut publica fără să observe nimeni; nu se potrivea cu regula restului paginii. Ce vezi mai sus sunt mărimi și coduri de răspuns, identice indiferent de unde măsori. Pentru timpi reali, deschide raportul PageSpeed de mai jos: rulează de pe infrastructura Google.
Proiectul de mai sus e o singură formă de a rezolva problema. Dacă ai nevoie de un site de prezentare pentru firma ta, de un magazin online din care chiar se cumpără sau de o aplicație web care să preia o parte din munca zilnică, pe fiecare pagină scrie ce include, cum se lucrează și de la ce buget pornește.
Următorul pas
Ai nevoie de o aplicație, nu de un site de prezentare?
Dacă lucrezi acum în fișiere Excel sau într-un program care nu mai ține pasul, spune-mi ce proces vrei automatizat. Îți răspund cu o direcție tehnică și cu un interval de preț, fără obligații.
- Răspuns în aceeași zi lucrătoare, direct de la cel care construiește
- O direcție concretă + interval de preț, nu un „vă contactăm noi”
- Fără obligații și fără insistențe după