Trei oameni lucrează în fiecare luni în același tabel. Cineva descarcă un CSV din sistemul A, potrivește coloanele și îl încarcă în sistemul B. Un raport e refăcut de mână, lună de lună. Iar pe factură stă un abonament SaaS de sute de euro pe lună, din care folosești o singură funcție.
Nu orice problemă de software cere o construcție grea. Pentru lucrurile astea facem tiny products: software mic, în jurul unei singure probleme clare, de obicei zile până la câteva săptămâni de muncă. Automatizare de procese, ținută dinadins mică.
Niciun proiect IT mare. Niciun roadmap pe cinci ani. O bucată de software care scoate din drum ceva enervant.
Recunoști vreuna dintre astea?
- „Avem un Excel care a devenit prea important.”Are formule, înțelegeri și logică de firmă pe care doar doi oameni le înțeleg până la capăt. Merge, până când cineva șterge o coloană sau fișierul e deschis de două ori în același timp.
- „În fiecare zi copiem asta dintr-un sistem în altul.”Export. Coloanele pe loc. Import. Verificare. Un proces pe care îl poți automatiza tehnic fără probleme, dar care a părut mereu prea mic pentru un proiect de software.
- „Plătim pentru douăzeci de funcții și folosim una.”Un produs SaaS rezolvă problema, dar e scump, greoi sau plin de funcții pe care nu le deschizi niciodată.
- „Refacem raportul ăsta în fiecare săptămână.”Scoți date din surse diferite, le pui la un loc, aplici formulele și reconstruiești același PowerPoint sau Excel.
- „Sistemul nostru poate aproape orice, în afară de chestia asta.”ERP-ul, CRM-ul sau magazinul online merge bine. Lipsește tocmai fluxul care, la tine, contează.
- „Avem o idee, dar nu știm dacă merită un proiect.”Un prototip mic îți spune de multe ori mai mult decât săptămâni de analiză.
Dacă una dintre frazele astea ți se pare cunoscută, ești pe teren de tiny product.
De ce merită atenție acum
Probleme de felul ăsta există de zeci de ani. Ce s-a schimbat e cât costă să construiești software pentru ele.
AI a lovit cel mai tare capătul mic al dezvoltării de software. Un developer cu experiență pune azi la punct mult mai repede o interfață, prelucrează date, leagă un API, scrie teste și produce cod repetitiv. Asta coboară pragul de la care merită să automatizezi.
Software-ul nu mai trebuie să fie mare ca să merite. O problemă pentru care acum cinci ani trebuiau €15.000 sau €20.000 o rezolvăm azi, uneori, cu o fracțiune din suma aia. Se deschide o categorie între Excel și un proiect mare de software, care înainte aproape că nu exista. Acolo vrem să stăm.
SaaS nu e mereu mai ieftin
Pentru multe probleme obișnuite, SaaS rămâne răspunsul bun. Dacă cineva a făcut un produs care face exact ce îți trebuie, cu €50 pe lună, cumpără-l. Noi n-o să ți-l refacem mai ieftin.
Comparația se schimbă când folosești doar o fărâmă din produs sau când prețul pe utilizator, tranzacție sau conexiune tot crește. €400 pe lună înseamnă €24.000 în cinci ani. Atunci merită să întrebi cât ar costa doar bucata de care ai nevoie cu adevărat.
Nu pentru că drepturile asupra codului sunt mereu mai bune. Ci pentru că să deții software mic e uneori mai ieftin decât să închiriezi software mare.
Pornește de la ce funcționează deja
Un tiny product nu înlocuiește sistemele pe care le ai. ERP-ul rămâne ERP, CRM-ul rămâne CRM, magazinul online rămâne magazinul online.
Tiny product-ul stă între ele, deasupra sau alături și rezolvă exact ce lipsește. Un dashboard mic peste ERP. Un connector între două sisteme. O unealtă care curăță fișierele înainte să le imporți. O interfață pentru un proces care azi stă în Excel.
Pornește de la ce funcționează. Construiește ce lipsește. Aici principiul ăsta e aproape literalmente produsul.
Ce poate fi un tiny product?
Nu are o formă fixă.
- O unealtă internă.Un ecran mic cu care oamenii tăi duc la capăt mai repede o sarcină anume.
- Un connector.Software care mută singur datele dintr-un sistem în altul.
- O unealtă de import sau export.Prelucrează, validează, îmbogățește sau transformă fișiere, fără aceeași muncă de mână de fiecare dată.
- Un dashboard.Adună date din una sau mai multe surse și arată exact ce îi trebuie cuiva ca să decidă.
- Un generator.Compune singur documente, oferte, rapoarte, feed-uri sau alt output.
- Un workflow.Automatizare de workflow pentru un lanț de acțiuni care azi trece prin mail, Excel și copy-paste.
- O unealtă de AI.Interpretează documente, clasifică informație, structurează text sau date ori sprijină o sarcină de cunoaștere repetitivă.
- Un prototip.Face o idee palpabilă rapid, înainte să decizi dacă trebuie să devină un produs mai mare.
Exemple arată cum arată asta concret.
AI stă aici de multe ori mai aproape de produs
La platforme și magazine online folosim AI mai ales ca să construim mai repede. La tiny products, AI e de multe ori motivul pentru care produsul poate exista.
Ia un om care citește o sută de documente și scoate din fiecare aceleași cinci câmpuri. Înainte, automatizarea însemna OCR complicat, șabloane și reguli pe tip de document. Acum un model preia o bună parte din interpretarea aia.
Sau cineva clasifică produse în fiecare dimineață, rezumă întrebări de la clienți, transformă text liber în date structurate sau potrivește două liste. Erau sarcini care cereau prea multă judecată omenească ca să le automatizezi. Automatizarea cu AI aduce o parte din ele la îndemână.
Lucrăm cu mai multe modele, printre care Claude, OpenAI și Grok, și alegem ce e destul de bun pentru treabă. Nu orice tiny product are nevoie de AI. AI a mărit enorm numărul de probleme destul de mici cât să merite rezolvate.
Partea grea e să-l ții mic
Pericolul e ca un tiny product să se transforme încet într-o platformă. „Putem adăuga și utilizatori?” „Și drepturi diferite?” „Poate o aplicație de telefon?” „Pot intra și clienții?” „Și un modul de raportare?”
Toate sunt întrebări rezonabile. Împreună sunt alt proiect.
De aceea, la un tiny product ținem o singură întrebare ascuțită: ce problemă trebuie să dispară? Tot ce nu e necesar direct pentru asta, vedem mai târziu. Așa rămân zilele zile. Cum le construim explică cum ținem amploarea mică.
Când nu e un tiny product
Un tiny product nu e un cuvânt ieftin pentru software la comandă. Dacă sistemul devine critic pentru firmă, are nevoie de mulți utilizatori și drepturi, trebuie să țină mai multe procese și primește un roadmap al lui, atunci construim o platformă.
Nu e un eșec. Înseamnă doar că problema e mai mare decât credeam. Preferăm să numim o platformă platformă la timp, decât să-ți promitem un buget de tiny product și să-ți explicăm trei luni mai târziu de ce n-a rămas tiny. Platforme e despre categoria aia mai mare.
Al cui e?
Al tău. Construim cu tehnologie standard și cu aceleași principii privind drepturile asupra codului ca la proiectele noastre mai mari.
Codul scris anume pentru tiny product-ul tău e al tău. Punem conturile externe și infrastructura pe numele firmei tale, acolo unde se poate, și n-ai nevoie de noi ca să ții produsul în funcțiune. Drepturile asupra codului și continuitatea pune pe hârtie înțelegerile exacte.
Ce se întâmplă cu mentenanța?
Nu orice tiny product are nevoie de un SLA, și e singura muncă la care nu impunem asta. O unealtă internă mică, care face o singură treabă bine delimitată, o poți lăsa în pace ani la rând.
Dacă devine critică pentru firmă, folosește API-uri externe sau se sprijină pe tehnologie care cere mentenanță regulată, atunci facem înțelegeri. Punem povara de mentenanță în socoteală când decidem dacă merită construit: o unealtă de €3.000 care cere €5.000 de mentenanță pe an nu e un tiny product bun.
De unde vine asta
Oferta e nouă. Tipul de software, nu. Construim de ani buni unelte interne mici pentru Baldwin și în jurul produselor noastre: connectoare, importuri, unelte de date, interfețe mici și scripturi care au devenit prea importante ca să rămână scripturi.
Până de curând le vedeam ca pe ceva ce construiești, pur și simplu, când ai developeri în casă. AI a schimbat socoteala: ce era interesant intern, pentru că capacitatea era deja acolo, e acum interesant de construit și pentru alte firme.
N-o să ne prefacem că am făcut deja o sută de tiny products pentru clienți. N-am făcut. Avem însă ani de exercițiu exact pe genul de probleme pentru care sunt gândite.
De aceea Ce putem dovedi pune asta la munca nouă, nu la cea dovedită. Exemple arată cu ce pornim azi.
Cât costă
Un tiny product trebuie să fie destul de mic cât să-și merite numele. Lucrăm la €95 pe oră, deci majoritatea tiny products încap în câteva mii de euro, nu în zeci de mii.
Prețul exact depinde de problemă, de integrări și de câtă interfață îți trebuie. Dacă prima estimare merge spre un proiect mare de development, o spunem înainte să începem.
Cât durează?
Zile până la câteva săptămâni. Nu e vorbă de vânzare. Face parte din idee: trebuie să ai destul de repede ceva utilizabil, ca să decizi dacă problema a dispărut, dacă mai lipsește ceva sau dacă trebuie să ne oprim.
Pentru că e o echipă mică și un termen scurt, începem de obicei în câteva săptămâni, nu în trimestrul următor. Dacă încă nu știi dacă ideea ține tehnic sau în practică, pornim mai mic, cu un prototip. Prototipare e despre asta.
Socoteala e de obicei simplă
Aici rareori avem nevoie de un model financiar complicat. Zici că o sarcină ia 30 de minute în fiecare zi lucrătoare: asta e mai mult de 100 de ore pe an.
Dacă un tiny product scoate în mare parte sarcina aia și costă câteva mii de euro, socoteala e rapidă. La fel și pentru abonamentul ăla SaaS de sute de euro pe lună, sau pentru greșelile care apar pentru că oamenii introduc de două ori aceeași informație.
Problemă mică × repetată destul de des = uneori surprinzător de mulți bani. Asta căutăm.
Întrebări pe care le primim des
Ce e un tiny product? O bucată mică de software care rezolvă o singură problemă clară. De obicei o unealtă internă, un connector, un workflow, un dashboard, o unealtă de import sau export ori o aplicație de AI, pe care o construim în zile până la câteva săptămâni.
Cât costă un tiny product? De obicei câteva mii de euro, la €95 pe oră. Dacă amploarea merge spre zeci de mii, nu mai vorbim despre un tiny product. Prețuri
Cât durează? Zile până la câteva săptămâni. Termenul scurt face parte din idee, iar de obicei începem în câteva săptămâni, nu în trimestrul următor.
Trebuie întâi un discovery? Nu un discovery clasic, ca la o platformă. Problema trebuie totuși să fie destul de ascuțită înainte să începem. Dacă nu e, preferăm un prototip mic sau o analiză scurtă.
Trebuie să aibă AI? Nu. AI face posibile unele tiny products și ne ajută să le construim mai repede. Dacă o regulă simplă sau un script rezolvă mai bine, facem asta.
Cum știu dacă merită banii? Ne uităm la cât timp, cât cost de abonament, câte greșeli sau câtă frustrare produce procesul de azi. La procese mici și repetitive, socoteala e de multe ori surprinzător de simplă.
Software-ul e al nostru? Da, după aceleași principii privind drepturile asupra codului ca la celelalte proiecte. Drepturile asupra codului și continuitatea
Are un tiny product nevoie de SLA? Nu automat. Depinde de cât de critic e pentru firmă și de ce sisteme externe și ce tehnologie se leagă. E singura muncă la care nu impunem un SLA.
Poate un tiny product să devină mai târziu o platformă? Da. Uneori o problemă mică e începutul a ceva mai mare. Nu proiectăm din start o platformă mare pentru o creștere care s-ar putea să nu vină niciodată.
Ați făcut asta des pentru clienți? Ca serviciu separat, e nou. Construim genul ăsta de unelte mici de ani buni pentru propria noastră operare și pentru produsele noastre, și de acolo vin exemplele. Preferăm să spunem asta decât să sugerăm un portofoliu pe care nu-l avem. Ce putem dovedi
Asta e automatizare de procese? Așa i se spune de obicei, da. Noi o ținem mică: un proces, o unealtă, săptămâni în loc de luni. Nu un program de digitalizare pe toată firma.