I feel like I am discovering that end users in the retool teams package are not actually end users. Everyone in the org is able to edit the app.
Does the marketing team at retool actually think someone reading this could possibly think anything other than "end users will not be able to edit apps"? I really need to know what is going on here. There seems to be a bit of silence from the retool team on this issue expressed in other posts.
If you set up your organization so that people are not able to edit the apps then that isn't an issue. Remove their edit permissions, problem solved.
Check out permissions tab in Organization settings.
It is in the docs, it's just worded more clearly in a not so obvious place here which says
An external user is priced at the same rate as an end user on the Team and Business plans.
There is also Billing and usage | Retool Docs that states in the note
Organizations on the Business plan can restrict certain users from building or editing apps and workflows using permission groups. This would ensure those users are only billed at the reduced end user rate.
not too sure where you're finding silence, as there's End Users vs. External Users Pricing And Workflow, End Users Feature - Unusable! - #8 by Nicolas_Le_Jeune and How to create end user with Team plan - #5 by Kabirdas. all of which have a member of the retool team dutifully replying
Thanks @bobthebear. I had done a quick search and found an article of someone complaining about this but there was no team responses(just like this post). So it looks like we just have to hope(fingers crossed) that an end user does not stumble into edit mode and make a small change putting them into an edit user? This seems like a really impractical payment tier(teams). A company has no control over people pushing there account into a higher priced account.
Does the Team plan not allow you to toggle edit privileges by user?
Thank you for taking the time to express your frustrations and concerns, @Shawn_Crocker. We’re reviewing this feedback with the team internally.
I wanted to start by apologizing for any confusion caused by our messaging. We understand that the distinction between "standard users" and "end users" can be confusing and has been a common point of friction, so we’re working to clarify this. I've reported the feedback in this thread on an internal ticket where we're aggregating feedback and ideas regarding the current Team plan. Each of the existing threads, including this one, help us share direct customer experiences with internal stakeholders who are aware of and actively considering the feedback.
Our updates to pricing last year were aimed at providing more flexibility and affordability, particularly for startups and teams with varying needs. We want to clarify that our pricing model is decoupled from user access controls, meaning that users are only charged at the higher standard rate if they actively make edits within the billing period, regardless of their permission settings.
In situations where it’s not critical to control edit access (e.g. an org has a small, trusted team) and the customer is focused on saving money, then the Team plan might be a good fit. For customers who view access controls as critical, we recommend the Business plan.
We also strive to be flexible with mistakes (e.g. someone clicking edit by accident) and are always happy to work with users on any payment issues.
Should you or any other users have further thoughts or suggestions, we would be more than happy to hear them! Thank you again for taking the time to share this feedback with us and we will also share relevant updates here as we have them.
Hi Shawn and @victoria, the answer to your headline question is because they have.
I promised my client a $50pm solution based on the Team pricing only to find out quite late that a Team 'end user' is not actually an end user. We all know that end users are people using SaaS with 'user' privileges, not people with 'edit' privileges.
We now pay $130pm on the Business plan because I feel it is unacceptable for end users to be able to hit the edit button. I don't mind paying $130pm - if my business case can't afford that then I shouldn't be doing this work.
What I do object to is the fact that Retool think they can word the Team pricing in such a way that it sounds like they have provided actual user privilege controls.
The only hope I can offer you is that after two or three invoices you will forget all about this and things will move on.
Regards
It could def use a rewording. I think it made sense at one point, Retool seems like it was originally meant to design in-house/1st party web apps, probably exclusively but idk I wasn't around then.... basically tools you let your employees or clients use in a safe environment away from the public internet. admin tools really, imo anyway judging from the templates and stuff. with that in mind, end-user would make more sense. not so much anymore though, now it can be confusing using 1 term for 2 groups of users (public users, and registered users that don't have edit access).
Yes. That is really hard to get the end users to say - please don't click the "Edit" button.
The so called "Team" plan - with 1 standard user + 1 end user will end up as $24 per month rather than $19 per month. More importantly, there is a danger of apps getting updated by end users. That's why Retool made that as "Estimated Monthly Pricing" at the time of subscription and they actually bill at the end of the month - which is completely opposite to other SaaS providers. So, after the first month, the users will end up going to "Business" plan with RBAC.
Having said that after testing all the other Low-code dev platform in the market - I found "Retool is the best out of all".
I think Retool can just remove that "Team" plan - there is no use of this "Team" plan - especially for small business where RBAC is the most important feature. Or if they can really help small business, they can bring in a minimal RBAC feature (Minimal rights in "Team plan" - Just with Dev User and View user concept & allowing specific apps to specific users - which is the conventional standard and end user).
For me think the biggest thing was that I feel like I was miss led into advising supervisors into a plan that was only clearly not entirely our desire after starting on it. If a company was ok with any user being able to edit the apps, it seems the company would have no reason to just stay on a free plan. I do love the platform though. Such a perfect combination of simple to build yet still so flexible in being able to do exactly what you need.
Team of 1. they could rename it to 'I-Team', both to poke fun at all the i-phony stuff(android > apple) and so we can finally say there is an I in team and its ME! 
as a side note, has anyone tried using custom css to disable the edit button?
HTML:
<div class="_nNNKr">
<button data-testid="EditApp::button" type="button" class="ant-btn retool-button ant-btn-primary" style="height: 28px; padding-left: 12px; padding-right: 12px; margin-left: 8px;"><span>Edit app</span> </button>
<button data-testid="RetoolPillPresentationNavBar::ShareButton" type="button" class="ant-btn retool-button _CswDq"><span>Share</span></button>
</div>
CSS Selector:
#root > div > div.no-expiry-header > div > div > div > div > div.core-layout__viewport > div > div > div > div.presentation-container > div.presentation-canvas-padding.presentation-canvas-padding--with-pill > div._VeNAJ > div._nNNKr > button.ant-btn.retool-button.ant-btn-primary
I think you can use the data-testid in the css selector, I just can't remember how right now, which would make it simpler.
if you want to disable both buttons (share and edit), they are happily grouped in their own div which you can use instead so you don't have to use 2 nasty looking selector thingies.
#root > div > div.no-expiry-header > div > div > div > div > div.core-layout__viewport > div > div > div > div.presentation-container > div.presentation-canvas-padding.presentation-canvas-padding--with-pill > div._VeNAJ > div._nNNKr
just be careful depending on auto-generated class names like '_nNNKr' as they could change w a future Retool update
I really had never thought about that. I honestly don't know anything about CSS and have never had reason to explore it until now. Thanks. I guess this would fix getting into edit mode from the app but not from the home screen.
You could probably write a Chrome extension to hide the edit button, but that would need to be installed on all user's computers. And the cost of writing it and maintaining users would mean it's probably better to just fork out the cash to Retool.
It's still a pretty good tool though and I like it better than the Micro$oft Power Apps.
It is a really good tool. We will just continue with teams for the moment. Everyone we have using the app are trustworthy to not start tinkering needlessly. Eventually we will probably setup some work stations to track and supply manufacturing data on the manufacturing floor, at which point, the business plan will undoubtedly be required. Interesting you mentioned power apps. One of our team members was suggesting it as a potential solution awhile ago. I have never actually tried it simply because I had already become proficient in retool and it clearly is capable of getting done anything we need or will need to do.