4MM / Studiu de caz • AI audit • MVP real
Cum arată un audit complet de aplicație făcut de AI
Studiu de caz real pe un MVP de contabilitate PFA: ce a verificat AI-ul, ce a confirmat, ce a găsit, ce merită fixat înainte de lansare.
🧪 proces, nu marketing
✅ concluzii aplicabile
De ce merită un audit cu AI
În ultimii ani, „AI” s-a transformat într-un cuvânt folosit prea ușor. În practică, AI-ul devine util abia când îl pui să facă muncă grea:
să verifice logică, să caute puncte slabe, să propună priorități și să-ți arate unde „merge la mine” nu înseamnă neapărat „merge pentru toți”.
Aici am documentat un experiment real: am pus o aplicație funcțională de contabilitate PFA sub lupa unui AI (Claude) și am analizat rezultatul cap-coadă:
tehnic (conceptual), logic, UX și produs. Fără cod publicat. Fără detalii exploatabile. Doar lecțiile care contează.
Context rapid: ce fel de aplicație a fost analizată
- PWA (Progressive Web App), instalabilă ca aplicație
- Offline-first (funcționează și fără internet)
- Focus: contabilitate PFA (facturi, cheltuieli, casa/banca, documente)
- Stocare locală (fără backend clasic în MVP)
- Exporturi și documente fiscale (ex: declarații/registre)
Notă: articolul nu include cod sau fișiere. Ne concentrăm pe proces și concluzii.
Ce NU a făcut AI-ul (important pentru credibilitate)
- Nu a rulat aplicația local și nu a „apasat butoane” în browser.
- Nu a executat Playwright sau un test automat real.
- Nu a avut acces la date private ale utilizatorilor.
AI-ul a fost folosit ca auditor de logică și produs (review conceptual), nu ca emulator.
Ce i-am cerut concret AI-ului
Nu i-am cerut „laude”. I-am cerut să fie critic, specific și util. Pe scurt, checklist-ul a fost:
- Analiză funcțională (ce există și ce lipsește)
- Verificarea logicii fiscale (CAS/CASS) la nivel de reguli și praguri
- UX: flow-ul real al unui PFA (ce face zilnic/ lunar)
- Arhitectură (concept): stocare locală, risc, limite
- Securitate: riscuri evidente și priorități de remediere
- Prioritizare: MUST / SHOULD / NICE-TO-HAVE
Ce a ieșit bine (și chiar contează)
1) Logica fiscală (CAS/CASS) – punctul critic
AI-ul a verificat regulile și pragurile pentru 2025 și a concluzionat că matematica și structura de calcul sunt corecte.
În produse de contabilitate, asta e genul de lucru care îți construiește (sau îți distruge) încrederea.
2) Offline-first – avantaj real, nu moft
Pentru PFA-uri, faptul că aplicația merge fără internet și că datele nu „stau undeva în cloud” poate fi un avantaj psihologic serios.
E o diferențiere pe care competiția o ignoră sau o complică inutil.
3) UX simplu, fără bloat
Navigarea și structura au fost evaluate ca „intuitive și familiare”. Pentru un MVP, e un semnal bun:
utilizatorul trebuie să își facă treaba, nu să învețe interfața.
4) Fără buguri critice (pentru MVP)
În raport nu au apărut probleme „blocker”. Asta nu înseamnă perfecțiune, ci că baza e stabilă.
Într-o aplicație cu date financiare, stabilitatea e prima condiție.
Ce a ieșit prost (și e bine că a ieșit acum)
1) Parole în clar (acceptabil la MVP, nu la producție)
Pentru un MVP e un compromis frecvent. Pentru produs plătit – nu mai este asa, e rezolvat.
Nu intrăm în detalii de implementare aici, dar concluzia e simplă: înainte de monetizare, parolele trebuie tratate corect.
2) Backup / restore – obligatoriu
Dacă utilizatorul își șterge cache-ul sau schimbă dispozitivul, datele locale pot dispărea. În contabilitate, asta e „game over”. O soluție minimă (export/import complet) e una dintre cele mai importante funcții înainte de public. Dar varianta Full salveaza pe server cat esti online, local in DB cand esti offline.
3) Performanță la volum mare
La 500+ înregistrări (facturi/cheltuieli), listele pot încetini dacă nu există paginare sau randare eficientă.
Nu e un „stopper” azi, dar e un semnal bun pentru roadmap.
4) Validări & feedback vizual
Formulare care permit sume 0 / negative, lipsa mesajelor de succes/eroare sau lipsa unor confirmări mai clare pot crea probleme în utilizare reală. Nu e glamour, dar e UX-ul care reduce suportul.
A.C.R.E.D. aplicat pe produs (pe scurt)
A – Atracție: PWA instalabilă + demo fără fricțiune. Ar ajuta o pagină scurtă de „de ce” înainte de login.
C – Clarificare: Dashboard simplu, cifrele cheie la vedere. Asta reduce întrebările.
R – Retenție: Offline + instalare = revenire ușoară. Următorul pas logic: reminders / scadențe (nu neapărat acum).
E – Engagement: Aici nu „gamification” e cheia, ci insight-uri simple: evoluție, alerte, comparații.
D – Diferențiere: CAS/CASS clar + offline-first + exporturi. Diferențiere reală, ușor de explicat în 1 frază.
Checklist „MUST înainte de lansare” (fără să intrăm în cod)
- Protecția credentialelor (minim: nu în clar)
- Export / Import complet (backup manual)
- Validări de bază (sume, câmpuri obligatorii, date)
- Mesaje clare la salvare/eroare (feedback vizual)
- Update flow PWA (utilizatorul să știe când s-a schimbat versiunea)
Observație: multe lucruri „nice-to-have” pot aștepta. MUST-ul este despre încredere și siguranța datelor.
Ce nu poate face AI-ul (și e bine să fie spus)
AI-ul poate fi auditor excelent de logică și structură, dar nu simte frustrarea utilizatorului după o zi lungă și nici nu poate înlocui testarea reală în browser.
Când vine vorba de produs, AI-ul e un copilot, nu un manager.
Cel mai bun rezultat apare când combini:
audit AI (logică + priorități) + testare reală (Playwright/QA) + feedback uman (utilizatori PFA).
Concluzie (fără hype)
Experimentul a fost simplu: un MVP real, pus sub lupă de AI, cu obiectivul de a scoate la iveală ce e solid și ce trebuie reparat înainte de lansare.
Rezultatul a confirmat un lucru important: AI-ul poate fi extrem de util ca auditor, dacă îi ceri lucruri concrete și îl folosești ca instrument de validare, nu ca generator de povestiri.
Dacă vrei mai multe studii de tipul „cum construim și testăm produse reale”, găsești astfel de materiale pe 4MM.