Problema
Majoritatea echipelor tehnice IMM cu care am vorbit aveau aceeași durere: date importante împrăștiate în zece tool-uri SaaS diferite, câteva tabele Postgres, și un Google Sheet pe care cineva îl întreținea din 2019. Un view util peste tot însemna fie un tool intern one-off per întrebare, fie BI enterprise pricing pentru alt client.
Exista un gap real în mijloc: ceva care înțelegea sursele echipei, le dădea un field model flexibil, și le lăsa să construiască view-urile de care aveau nevoie fără să scrie o aplicație nouă.
Abordare
- Fields compozabile. În loc de o schemă rigidă, Basetool v1 trata fields ca obiecte de primă clasă: tipizate, filtrabile, reutilizabile între views. O echipă putea remodela datele fără să remodeleze baza de date.
- Views și roluri. Oameni diferiți aveau nevoie de slice-uri diferite. Modelul de view și permisiuni lăsa o singură sursă de adevăr să alimenteze multe ecrane, fără ca fiecare echipă să-și clone propria versiune.
- Frontend boring, rapid. TypeScript, React, Next.js, Tailwind. Produsul era menit să se simtă ca un tool intern pe care și-l construiește propria echipă, dacă ar fi avut timp. Fără JS deștept, fără state management nou.
Rezultat
- Am livrat platforma v1 cu primitivele core intacte: surse, fields, filtre, views și roluri.
- Am validat teza că echipele tehnice IMM vor tool-uri interne compozabile, nu dashboards enterprise.
- Acea muncă a informat direct forma curentă a basetool.ai: în loc să construim un produs generalizat, studio-ul Basetool construiește tool-ul custom potrivit pentru fiecare echipă, mai repede, cu leverage AI-nativ.
Note de stack
Codebase-ul era deliberat boring. TypeScript pentru safety, React pentru UI, Next.js pentru rendering, Redux pentru state (la momentul ăla), Tailwind pentru styling. Stack-urile boring îmbătrânesc bine. Părțile interesante ale produsului au fost mereu despre modelul de date, nu despre wire format.