Un produs SaaS („software as a service”) este o aplicație pe care clienții tăi o folosesc din browser și o plătesc lunar sau anual, fără să instaleze nimic. Cine caută „dezvoltare platformă SaaS” are de obicei o idee verificată pe jumătate: cunoaște bine o problemă dintr-un domeniu și vrea să vândă rezolvarea mai multor firme deodată.
Riscul cel mai mare nu e tehnic. E să construiești îndelung un produs pe care nu îl plătește nimeni. De aceea propunem o primă versiune mică, numită de obicei MVP (produs minim viabil, adică cel mai mic produs care poate fi vândut), cu fundația făcută corect și cu restul amânat pe față.
Dezvoltare platformă SaaS: ce intră în prima versiune
Prima versiune face bine un singur lucru: cel pentru care cineva ar scoate cardul. Să zicem că vrei un produs pentru administrarea unor săli de sport. Funcția care se vinde ar putea fi evidența abonamentelor și a intrărilor; rapoartele elaborate, aplicația de telefon și legătura cu turnicheții pot aștepta.
În jurul acestei funcții există însă o parte pe care nu o poți sări, fiindcă fără ea nu ai un produs, ci un prototip.
- Înregistrare și autentificare: cont nou, confirmare pe email, resetare de parolă.
- Spațiul clientului: fiecare firmă abonată are datele, utilizatorii și setările ei.
- Roluri: cel puțin proprietar, administrator și utilizator simplu, cu invitații pe email.
- Abonament: alegerea planului, plata, schimbarea planului, anularea.
- Ghidaj la prima folosire: câțiva pași care duc omul până la primul rezultat util, cu date de exemplu.
- Panou de administrare: pentru tine, ca să vezi conturile, plățile și problemele.
Conturi separate pe fiecare client: cum ținem datele despărțite
Arhitectura în care aceeași aplicație servește mai mulți clienți se numește multi-tenant (fiecare client e un „chiriaș”). În varianta cea mai răspândită, toți împart aceeași bază de date, iar fiecare rând poartă identificatorul firmei căreia îi aparține. În cealaltă, fiecare client are baza lui de date.
Prima e mai simplă de întreținut și potrivită pentru cele mai multe produse aflate la început. A doua izolează mai bine și ajută când vinzi unor firme mari, dar complică actualizările. Oricare ar fi alegerea, separarea se impune într-un singur loc din cod, nu în fiecare ecran, și se verifică prin teste automate care încearcă dinadins să citească datele altui client.
Abonamente și facturare printr-un procesator de plăți
Nu scriem de la zero logica de plăți recurente. Folosim un procesator (Stripe este un exemplu des întâlnit) care păstrează cardurile, face reînnoirile, reîncearcă plățile eșuate și anunță aplicația prin webhook-uri, adică mesaje automate trimise la fiecare eveniment: plată reușită, plată eșuată, abonament anulat.
Aplicația ascultă aceste mesaje și deschide sau restrânge accesul. Tu hotărăști partea comercială: perioadă de probă sau nu, planuri pe număr de utilizatori sau pe volum, ce se întâmplă cu datele celui care nu mai plătește. Tratamentul fiscal al vânzărilor, mai ales către alte țări, se lămurește cu contabilul înainte de alegerea procesatorului.
Ce lăsăm deliberat pe mai târziu
Fiecare funcție amânată e timp câștigat pentru a afla ce vor de fapt primii utilizatori. Ținem o listă scrisă cu ce nu intră în prima versiune, ca să nu se strecoare înapoi pe parcurs.
Ce nu amânăm niciodată: copiile de siguranță, separarea datelor și posibilitatea ca un abonat să își exporte datele. Acestea se repară foarte scump după ce ai utilizatori.
- Aplicația nativă de telefon: o interfață web care se vede bine pe mobil ajunge la început.
- Interfața de programare (API) pentru terți: se adaugă când o cere cineva care plătește.
- Rapoarte complexe: un export în tabel acoperă nevoile de început.
Ritmul de lucru și uneltele din spate
Pentru astfel de produse preferăm Laravel, un framework PHP care oferă, în nucleu sau prin pachete oficiale, autentificarea, cozile de sarcini și legătura cu unele procesatoare de plăți. Datele stau în PostgreSQL sau MySQL. Sarcinile lente (emailuri, importuri, rapoarte) rulează în fundal, iar fiecare modificare trece printr-un set de teste automate înainte de publicare.
Ce nu putem face: să validăm piața în locul tău. Putem construi instrumentele prin care măsori (câți se înregistrează, câți ajung la primul rezultat, câți plătesc după perioada de probă), dar discuțiile cu primii clienți îți aparțin.
- Atelierul de început: desenăm drumul utilizatorului de la înregistrare la primul rezultat și tăiem restul.
- Scheletul: conturi, spațiul fiecărui client, roluri, mediu de probă.
- Funcția centrală: construită în cicluri scurte, cu o demonstrație la capătul fiecăruia.
- Plățile și ghidajul: adăugate când funcția centrală poate fi arătată cuiva din afară.
- Primii utilizatori: un grup restrâns, din ale cărui piedici iese lista următoare.
Întrebări frecvente
Cui îi aparține codul platformei?
Se stabilește prin contract, nu de la sine. Pentru un produs propriu, cere o clauză scrisă despre drepturile asupra codului scris pentru tine și despre componentele cu sursă deschisă, care își păstrează licențele. Verific-o cu un jurist înainte de semnare.
De ce depinde costul primei versiuni?
De cât de mare e funcția centrală, de numărul de roluri și de planuri, de integrări și de cât design propriu vrei. La dezvoltare se adaugă costuri lunare de funcționare: găzduire, email, comisioanele procesatorului, monitorizare.
Ce se întâmplă când crește numărul de clienți?
O aplicație construită curat poate duce multe conturi pe o infrastructură modestă, iar locurile care se încarcă se văd de obicei din monitorizare înainte să devină probleme. Nu proiectăm de la început pentru un trafic pe care nu îl ai, fiindcă ai plăti complexitate fără folos.
Aceasta este o descriere de proiect-tip: arată cum abordăm de obicei o astfel de lucrare și nu prezintă un proiect făcut pentru un client anume. Fiecare proiect real pornește de la situația firmei tale, iar etapele, termenele și prețul se stabilesc după discuția de început.