La bitGloss nu ne-am propus niciodată să construim un produs doar ca să avem un produs.
worklog.ro a apărut dintr-o nevoie foarte practică: să ne organizăm mai bine munca, să urmărim timpul investit în proiecte și să putem genera rapoarte fără să ne adaptăm permanent după limitările altor aplicații.
Și, ca multe produse bune, a început ca un tool intern.
Problema pe care încercam să o rezolvăm
În teorie, problema era deja rezolvată.
Existau și există multe produse mature pentru time tracking și project management. Am folosit și noi astfel de soluții. JIRA era prezent în ecosistem, iar o perioadă am folosit și YouTrack instalat pe infrastructura proprie.
Dar apăreau constant mici probleme:
- unele fluxuri de lucru nu se potriveau modului nostru de lucru;
- raportarea nu era suficient de flexibilă pentru ce aveam nevoie la acel moment;
- modelul de cost nu era întotdeauna convenabil;
- trebuia să combinăm mai multe unelte pentru ceva ce, în esență, voiam să fie un proces unitar.
Nimic dramatic.
Doar suficient de multă fricțiune încât să ne întrebăm: dacă tot adaptăm procesele după tool, de ce să nu construim exact ce ne trebuie?
Așa a apărut prima versiune worklog.
Prima versiune: strict pentru noi
Inițial nu exista intenția să devină produs.
Aveam nevoie de ceva simplu:
- logare de ore;
- organizare pe proiecte;
- generare de rapoarte;
- administrarea accesului pentru echipă.
Frontend-ul inițial a fost construit în ClojureScript.
A funcționat bine și ne-a permis să iterăm rapid. Dar pe măsură ce aplicația a crescut și utilizarea a devenit zilnică, am început să observăm un lucru important: frontend-ul era întreținut de o singură persoană.
În acel context, viteza de dezvoltare conta, dar controlul calității conta și mai mult.
Așa am decis să migrăm frontend-ul către Elm.
Motivul nu a fost „tehnologie nouă” sau dorința de rescriere. Motivul a fost unul foarte pragmatic: Elm mută foarte multe categorii de erori în etapa de compilare. În practică, asta înseamnă mai puține bug-uri care ajung în producție și mai puțin efort de validare manuală.
Pentru o aplicație întreținută eficient de o echipă mică, asta s-a dovedit o alegere foarte bună.
Câțiva ani de utilizare reală
Nu există test mai bun pentru un produs decât să depinzi de el.
Ani la rând am folosit worklog exclusiv intern.
Fiecare neajuns ieșea imediat la suprafață.
Dacă un raport dura prea mult să fie generat, îl simțeam.
Dacă lipsea o funcționalitate, apărea rapid în backlog.
Dacă ceva era greoi, nimeni nu evita problema.
În perioada aceea am trecut prin mai multe iterații și am rafinat produsul continuu.
Momentul în care am renunțat la Excel
Până în 2021, facturarea noastră se făcea încă prin Excel.
Funcționa.
Dar doar în sensul că orice proces manual „funcționează” până când devine suficient de enervant.
Generarea facturilor era repetitivă, predispusă la greșeli și consuma timp inutil.
În 2021 am generat prima factură direct din worklog.
A fost unul dintre momentele în care am realizat că produsul începe să rezolve mai mult decât problema inițială de time tracking.
Pur și simplu era mai simplu.
Legislația a schimbat direcția produsului
Între timp, cadrul fiscal din România s-a schimbat.
A apărut necesitatea integrării cu SPV și e-Factura.
În loc să tratăm asta ca pe încă un tool separat, am ales să integrăm fluxul direct în platformă.
Astfel, worklog a început să lege natural:
ore lucrate → raportare → facturare → transmitere.
Când ne-am dat seama că nu suntem singurii cu problema asta
După ani de utilizare internă, a devenit clar că modelul nostru nu era deloc unic.
Existau mulți oameni și multe firme care funcționau similar:
- freelanceri;
- PFA-uri;
- SRL-uri mici;
- agenții;
- echipe care facturează la oră;
- firme care lucrează atât cu clienți români, cât și internaționali.
Toți aveau nevoie de aceleași lucruri:
- time tracking;
- rapoarte;
- facturare;
- integrare cu cerințele fiscale;
- administrare fără complexitatea unei platforme enterprise.
Atunci am decis să deschidem worklog.ro și către exterior.
Nu ca idee de startup.
Ci ca produs validat deja prin ani de utilizare internă.
Funcționalități care au apărut din utilizare reală
Pe parcurs am adăugat funcționalități care au rezolvat probleme concrete:
Integrare GitHub
Posibilitatea de a loga ore pornind de la commit-uri extrase direct din GitHub.
Integrare JIRA
Logarea timpului pornind de la tichetele existente.
Arhitectură multi-tenant
Fiecare cont are:
- un administrator;
- unul sau mai mulți utilizatori;
- proiecte separate.
Administratorul este și el utilizator — poate loga ore ca oricine altcineva — dar are responsabilități suplimentare:
- generare facturi;
- management proiecte;
- management utilizatori;
- asocieri între utilizatori și proiecte;
- controlul accesului în diferitele module.
Modelul a fost construit după cum funcționează firme reale, nu după cum arată un demo.
De ce publicăm povestea asta
Există multe produse care promit multe.
Noi preferăm altă abordare.
worklog.ro nu a fost construit pentru a intra pe o piață.
A fost construit pentru că aveam nevoie de el.
Faptul că astăzi este disponibil și pentru alții este doar continuarea firească a unei aplicații pe care am folosit-o ani întregi înainte să o prezentăm public.