by bootstrpppin on 11/14/24, 12:26 AM with 49 comments
I'm planning to build a SaaS product loosely in the B2B logistics space - it needs to be relatively low cost to build/maintain, look slick and be extensible.
It would be customer facing, meaning each customer would need a login/account (or perhaps many, if a whole team is using our product).
I've looked at Retool and it looks quite epic but it looks like it's designed primarily for internal apps.
Has anybody used, or attempted to use Retool for a production, user-facing app?
Would really appreciate advice, war stories or recommendations.
by reilly3000 on 11/19/24, 4:40 AM
What is your exit plan if Retool doesn’t fit your needs otherwise?
by hipadev23 on 11/19/24, 5:04 AM
Downsides? The app overhead can be bulky. It's not something users are going to quickly open, look at some stats, and close imo. If your use-case is users logging-into the platform and likely keeping the dashboard/whatever open for hours or indefinitely? That's a better fit.
Their support team needs a lot of work. They generally are slow to respond and don't understand their own products or pricing. A lot of what should be simple questions end up taking multiple back and forth emails where you find yourself explaining the nature of your problem/question to the support person. It's extremely frustrating to the point I've thought about abandoning them over how incompetent support is. That said, the CEO is really responsive to direct emails...
by antonybello on 11/19/24, 9:12 PM
Retool has a high ceiling for what you can build with it. Generally speaking, most of our external use cases are B2B use cases that focus on productivity and data, not things that require highly differentiated visuals and animations. We call this "Operations software".
To name a few examples:
- Greenly is a B2B climate tech company who built a large portion of its product using Retool. You can see their case study here: https://retool.com/customers/greenly - Ylopo is a real estate tech company that built Retool apps to drive upsell opportunities: https://www.youtube.com/watch?v=nj0_XuRh3G8 - Retool runs its Partner Portal through external-facing Retool apps: https://www.youtube.com/watch?v=Fu7FlG7SsU0
We had to make a lot of platform improvements in Retool's performance and design capabilities to claim that we have first-class support for customer-facing use (it's not as easy as it should be if you're new to Retool, but we're working on it). The bar is simply higher. Pricing and packaging needed to be there as well: we launched external user pricing that gives you a predictable rate at scale, and if you're bootstrapping, you can get up to $60k in credits through our Startup Program, which would cover your Retool bill entirely.
Happy to chat more if you're overwhelmed by all the links - you can email me at antony[at]retool[dot]com.
(Quick plug - we're actually running a webinar on how to build external-facing applications tomorrow! You can sign up on https://events.retool.com/build-external-apps.)
by jameslk on 11/19/24, 5:52 AM
* Plasmic (open source)
* Jet Admin (proprietary)
* Budibase (open source)
* Appsmith (open source)
And a few others. Most had limitations around our need of multi tenancy/team oriented backend, or were too oriented towards internal tools, and I was worried about data lock in with the proprietary ones.
Ultimately I chose to go with Rails with Bullet Train. But this was right before LLMs became kind of the norm to hack stuff together. If I were to choose today, I’d probably pick Plasmic with some LLM hacked together TypeScript backend for a good balance between low effort dev velocity and future proofing, maybe with a BaaS like Supabase+Auth0. All the LLMs seem to be trained on a TypeScript-shaped shallow stack, and static typing gives a bit more protection against LLMs chasing the dragon.
by steve_adams_86 on 11/19/24, 6:25 AM
I wouldn’t ship an actual product with heaps of users from windmill but it’s perfectly capable of proving concepts, and the workflows are excellent.
I do have one product I built entirely in windmill but you’d never be able to tell. It isn’t online right now. It was essentially a scheduled script for fetching smoke forecast data from government websites, a react front end, and a tile server which sent map tiles to the client containing the smoke forecast data. The performance was totally fine and the UI was nice, but I built that part mostly by hand rather than exclusively with their WYSIWYG editor.
by leoff on 11/19/24, 7:05 AM
The saying "it makes hard things easy, and easy things impossible" is fitting, once it feels like you're fighting against the platform, it's time to quit and start writing some code.
by puppycodes on 11/19/24, 5:33 AM
by BrandiATMuhkuh on 11/19/24, 2:20 PM
As soon as things get more complex I move things to react. But that is usually pretty easy to do as you know the users pain at this point pretty well.
by jasfi on 11/19/24, 4:56 AM
by moltar on 11/19/24, 8:43 PM
by thrw42A8N on 11/14/24, 12:38 AM
by gervwyk on 11/19/24, 8:32 PM
Happy to answer some questions and show you what we’ve built with Lowdefy - It’s very powerful and easy to get started with and maintain. gvw at lowdefy.com
by itomato on 11/19/24, 5:51 PM
The ultimate way to go in my situation was to build a library of single-use Streamlit or Gradio code with the aid of an LLM.
by android521 on 11/19/24, 4:17 AM
by kobewan on 11/19/24, 5:05 AM
It's definitely used by some non-tech companies (think exercise companies, or property management) but not sure it's the typical HN crowd so you might not get war stories
by ezekg on 11/19/24, 6:49 PM
by psadri on 11/19/24, 6:50 AM