I am so confused about this too. retool, tooljet, budibase - why is everyone doing this? Best I can figure out is that no one has found a pricing structure that works otherwise, which would be rather sad if true.
I assumed this was because it’s internal devs that are actively looking for platforms to build on, while external devs might already have stacks they prefer to work on due to how it interacts with their security postures. Pure speculation, but it’s been my anecdotal experience.
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!
It's because every small business has this problem and need, and there are a lot of small businesses. But selling technology to small businesses is extremely hard.
Because it lets them establish a beach-head in a less-demanding market, but one with deep pockets. It also lets them create corporate relationships. With all this revenue they keep adding features until the product is more general purpose and can be used to build anything. If they try to boil the ocean to begin with, they'll fail. This is a more pragmatic, staged approach.
It's just how we try to narrow down the uses cases that the product would be better suited for. I'd love to come up with a better name for it. At the end of the day, I think we're all just different approaches to a similar problem/use case
