i second that. for external-facing tools, you probably want something custom, branded, and more flexible. when it comes to internal tools, you typically want something quick to get the job done.
at dropbase, our focus was on enabling developers to get stuff done efficiently. we noticed that for 90% of internal tool use cases, you only need a table and modal to get user input. so we focused on developing those. while it may not be sufficient for external apps, for internal tools, it should cover most of that you need
Are you aware how most companies external apps look like? Here's how: They don't.
What you compete with, what you have to beat, is not "something custom branded and more flexible". It's nothing at all. Cutting yourself out of that market with a tool that would easily be powerful and user friendly enough to fill this gap does not make any sense to me, if that is in fact your true reason. (And also I don't understand how that could make any sense intuitively if you just look at how often you see google forms being used by a big company as an external data collection tool).
It could be such an obvious differentiator for any of the competitors – but, like I said, I suspect the actual reason to why people are so ready to give up on this is rooted somewhere else.
This is actually quite encouraging for us as product developers (although maybe it's not a good thing if end users don't get good tools). It just means there's a lot more room to grow. I wouldn't say we've given up on external, but there's definitely a part of us that's hesitant to communicate the product as a "build anything" app so early. The fact that you think that could actually be an obvious differentiator is quite intriguing and thought provoking. I should do more research and understand the extent to which customers of big companies are exposed to google forms (and similar tools). Maybe we'll discover something interesting in the process. Thanks!
I understand. Maybe a niche for you, that might be interesting to explore,from my latest personal experience: Managing a medical business, including a combined portal for patients and providers.
For the patients, you might need submission process, you might need a place for people to see or cancel their next appointments, fill out a form or upload some pictures from other, while also making this information available internally, with doctors being able to document therapies and such.
Nothing fancy; I would hardly call it "build anything", it's all fairly CRUDy and on the face could be very effectively handled by all retool-alikes. (In fact budibase for example could have easily filled the need from a technical standpoint – but having to pay xx$ indefinitely per "customer" just does not work out, when you see most of them only once a year and maybe only once total, while having to keep records for many years.)
That's an interesting use case. Thanks for sharing. I think I understand your point better after reading this. I agree that having to pay xx$ indefinitely for presumably many end users who will only fill up the form once (or very rarely) doesn't make sense. We don't have a solution to this just yet, but I have a couple of ideas on how to tackle this.
PS. CRUDy sounds like a fun and quite literal name for an app builder!
at dropbase, our focus was on enabling developers to get stuff done efficiently. we noticed that for 90% of internal tool use cases, you only need a table and modal to get user input. so we focused on developing those. while it may not be sufficient for external apps, for internal tools, it should cover most of that you need