De ce un studio ar trebui să-și țină propriile produse în viață

Majoritatea studiourilor livrează și pleacă. Noi rămânem.

KodeKind construiește software pentru clienți. Construim și ținem în viață și produse proprii: Scisso, ScrumSheets, SRLeads. Partea a doua pare o notă de subsol. E, de fapt, tot.

"Gata" înseamnă altceva când îl ții tu în viață

Când construiești doar pentru alții, gata e ziua în care a intrat factura. Bug-ul care apare peste trei săptămâni e dimineața altcuiva.

Când ții tu produsul, dimineața aia e a ta. Simți alerta de la 2 noaptea. Plătești hosting-ul. Răspunzi la mailul de support de la un om real care nu poate să-și facă o programare.

Așa că construiești altfel. Scrii migrarea care nu te trezește noaptea. Alegi biblioteca plictisitoare și de încredere. Faci produsul observabil, fiindcă tu-cel-de-mâine are nevoie să vadă înăuntru.

Standardul se mută cu tine

Partea care contează pentru un client: obiceiurile nu se opresc.

O echipă care își ține propriile produse în viață aduce instinctul de operator la proiectul tău: întrebările pe care le pun doar oamenii care au fost de gardă. Ce se întâmplă când pică la 3 noaptea? Cine deține datele dacă dispărem? De unde știm că merge, de fapt?

Nu sunt întrebări dintr-un deck. Sunt cicatrici.

Nu poți să te prefaci că ai lansat

Multe sfaturi despre software sunt teorie îmbrăcată frumos. Diferența dintre o echipă care a lansat și operat un produs și una care doar l-a livrat se vede în deciziile mici, alea pe care nicio ofertă nu le pomenește.

Mai bine îți arătăm un lucru pe care îl ținem în viață decât să-ți povestim despre unul pe care l-am construi.

Ăsta e argumentul liniștit pentru un studio care mănâncă din propria bucătărie: când construim pentru tine, primești o echipă care a trăit deja consecințele, și a ales să construiască bine oricum.