> For small, and really small companies they already have the talent to deal with the database directly because that's how they handle most of their problems be

> For small, and really small companies they already have the talent to deal with the database directly because that's how they handle most of their problems because they don't have a "console" interface. I feel like small and really small comparies are the primary market for this tool. A sort of stepping stone until they can build out a large enough engineering team to support more specialized internal tooling. A lot of small companies store most / all of their business data in spread sheets anyway, BaseDash just gives them a more robust backend (SQL) that allows them to transition more seamlessly into custom back office software. > So this would be just another product for them, and the technical staff wouldn't find it terribly useful because they already know how to interact with the database. The technical staff would find it tremendously useful because they can focus on building a solid data model on top of a SQL database without having to spend time building out clunky admin interfaces. And from the other direction they don't need to build out migrations from legacy spreadsheet data into a SQL database. > For medium to large companies it doesn't fit because those companies spend all of their time trying to limit direct access to the database, so buying a tool that makes it easier is counter productive. Maybe, but if BaseDash offers robust enough validations and permissioning, this shouldn't be as much of a concern. The flip side is that without BaseDash, if some data needs to be tweaked that isn't possible to do using the clunky ad hoc admin interfaces that were built, someone on the engineering team would need to make those changes in the database manually, or ops would need to wait for engineering to build out a feature to allow them to make those changes.