The problem
Most SMB technical teams we talked to had the same pain: important data was scattered across ten different SaaS tools, a handful of Postgres tables, and a Google Sheet that somebody had been maintaining since 2019. Getting a useful view across all of it meant either writing a one-off internal tool per question or paying for enterprise BI that was priced for a different customer.
There was a real gap in the middle: something that understood the team's sources, gave them a flexible field model, and let them build the views they actually needed without writing a new app.
Approach
- Composable fields. Rather than a rigid schema, Basetool v1 treated fields as first-class objects: typed, filterable, reusable across views. A team could reshape the data without reshaping the database.
- Views and roles. Different people needed different slices. The view and permission model let one source of truth power many screens, without each team cloning their own version.
- Boring, fast frontend. TypeScript, React, Next.js, Tailwind. The product was meant to feel like an internal tool your own team would build, if they had had the time. No clever JS, no novel state management.
Outcome
- Shipped the v1 platform with the core primitives intact: sources, fields, filters, views and roles.
- Validated the thesis that SMB technical teams want composable internal tools, not enterprise dashboards.
- That work directly informed the current shape of basetool.ai: instead of building one generalized product, the Basetool studio builds the right custom tool for each team, faster, with AI-native leverage.
Stack notes
The codebase was deliberately boring. TypeScript for safety, React for the UI, Next.js for rendering, Redux for state (at the time), Tailwind for styling. Boring stacks age well. The interesting parts of the product were always about the data model, not the wire format.