Awesome, I appreciate the clarification. Any ideas on the second part of my post by chance? I just wanna make sure I’m making the right move.
I didn’t user Zapier or Make, so I’m not really sure. I would think it’s using the API underneath, but I’m not sure if this has different rules for what you can do through Zapier/Make compared to directly using the API.
1 Like
That’s where I’m at too… I don’t see how you’d even be able to use Zapier or Make without access to the Glide API, so I’m not sure what benefit adding it to the Maker plan does.
Can anyone else provide some clarity on this? 
I would like to know about this too…
2 Likes
Thanks for the perspective … and I don’t go to Starbucks either. Who can afford that sh*t?? 
My situation isn’t that different - I built the app in 3 different platforms initially to see which was best and most cost effective. I’ll omit the names to protect the innocent (and the guilty).
In the end, for me, it was Glide by a country mile … but I also have subscriptions to Make and Databox to do things Glide doesn’t do yet. So I hear you on the cost climbing …
One thing I can say from my limited time with the Glide folks … yes, the pricing does change … but each time they’ve done it - they haven’t forced users to move plans. Only if we wanted to and only if we saw value in the new plan (or the existing plan didn’t have the feature we wanted - also known as, the new plan had a value I wanted).
They tend to be extremely transparent and fair - especially as it relates to other software companies I’ve worked with (and for).
The Glide roadmap is killer … the stuff I’ve seen blows me away and it’s gonna make it way way more powerful by the end of this year (I’d expect that timeframe).
Anyway - best of luck … hopefully you’ll remain a Glider!
3 Likes
Are you comparing Legacy Pro with the new Team plan, or Legacy Pro with the new Maker plan? I ask because the Team plan is $99 and there is no Maker plan at $99.
If you are comparing Legacy Pro to Team, then the comparison is valid and worth making. You cannot compare however Legacy Pro to Maker, the use cases are entirely different: Maker is aimed at a community application (large number of users expected), Legacy Pro and Team are aimed at B2B internal business software (limited number of users expected).
1 Like
I misspoke earlier, I meant the $60 Maker Plan. Yes, I’m comparing the current legacy Pro plan to the new Maker plan, wondering if it’s worth the switch. I’m only using about 1,000 updates outside of the Glide Tables platform, around 22,000 with it… so moving to that plan would actually cost less due to the update count being ignored for the new plans on Glide Tables. All of my users are “personal users”, so that wouldn’t be an issue at all.
My main concern is the loss of the Glide API though… I don’t understand how something like Zapier or Make would even work without the API, so I wanted to make sure that I’m not screwing myself by switching to that plan. 
1 Like
It’s still the Glide API under the hood. 
Only difference with the Maker plan is that you’re working through Zapier or Make, rather than connecting to the Glide API directly.
5 Likes
Having the Glide API would allow me to tntegeate with my own program; written by me. No chance then for Maker to have that capability?
The issue with Teams is the user limits. Legacy Pro allows 5,000 public users, while Team is 20. Maker is a problem because you’d need to exclude all customers that use a work e-mail or non-consumer e-mails.
For me, the whole personal vs. private e-mail is such a pain in the ass. I really don’t want to be dealing with which client uses which e-mail, and having to go back and forth with customer service every time there is a false positive, or a client uses an e-mail that triggers an alert in the validator.
At $3 per user I’d also have to keep tabs on who logs in which something I really don’t want to have on my plate. I also have a genuine concern on log-in abuse and the budget spiraling out of control. I have clients that log-in with e-mail A, only to realize they used e-mail B for their order and now have to log-out and log back in. I’d like to know how these scenarios are billed.
I’m a “simple business model” type of person so I’d much rather get a constant bill every month, and not have to worry about the choice of e-mails of my users, or having a completely unpredictable overhead costs.
3 Likes
This alone seems like Maker is not what you need. Maker really is made for communities, schools, projects, hobbies, prototypes and MVPs. It’s not meant to be used in the setting of an established business.
So you would be comparing Legacy Pro (you seem to have a team on that plan) and Team. All other considerations aside, the number of monthly active users expected might be key here. Do you have an idea?
2 Likes
It’s around 10 staff members that actually use the portal day to day and around 300 monthly customers that log in to check on their order status, maybe open a ticket. Legacy Pro covers me without any issues, but the user limit in Teams takes me from $99 to $900/mo. Even with a generous discount it’s well beyond what my budget permits.
Furthermore, there’s this element that worries me:
I also have a genuine concern on log-in abuse and the budget spiraling out of control. I have clients that log-in with e-mail A, only to realize they used e-mail B for their order and now have to log-out and log back in. I’d like to know how these scenarios are billed.
I’ll never say “no chance”, but it’s not something we’re looking at right now.
The Maker plan caters to no-code creators. We’re covering that with Zapier and Make.
1 Like
Silly question perhaps and surely I missed something in the conversation, but why are you considering a change then?
I’m not, at the moment. I really do appreciate Glide’s commitment to maintain the legacy plans indefinitely. The change in the Team plans is also very welcomed, particularly on storage limits and updates. But I would like to see a plan that meets my needs for future projects and the user limit/cost is a major hurdle unless you’re dealing with just internal users or a subscription business model. I envy you developers that can jump ship and start from scratch without a skipping a beat, but for me it’s about investing time learning a system that I have a future with.
3 Likes
I think most creators / builders / developers who have been using Glide for a while mostly understand and adhere to Glide’s original ethos: B2B internal business apps. This has been Glide’s positioning since I first joined in April 2020 and Glide hasn’t wavered. The terminology has changed a little – dark apps, internal apps, business apps, now it’s custom software for your business – but the ethos is the same.
I think those who don’t stick around or complain are mostly those who are using Glide for something it’s not meant for. And Glide remains accommodating.
Then it’s true, some features come and go, the pricing changes a little. I think everyone adapts, just like with any other service provider changes its features and prices. Really, if a Glide app provides great value to a business, Glide’s price points are competitive in economies that can afford this type of custom software.
3 Likes
Glide’s price point is actually very competitive when you do some digging.
To build consumer apps you have:
- Developers which is why we are all here in the first place, but can be in hundreds of thousands
- Then you have Glide Enterprise which is $1k+ per month but you can do it all yourself and don’t need developers
- Then there are tools like Webflow/Wized which is probably around $200-300 month but scales as you grow. This requires you do to a lot of the designing, building and setting up automations yourself.
- Bubble - complicated and again scales up fast in pricing
- Softr - just isn’t there in terms of product imo.
You just always have trade-offs with these things. You either go down the cheaper and more time-consuming route or the faster / more expensive route.
I still think this path is best to getting to 5 - 10k MRR with the Team/Business plan and then deciding where a custom build or Glide Enterprise makes more sense.
3 Likes
And yeah, people just found workaround for the Private/Public Users distinction and companies that would have been otherwise been using Private Users just ended up using Public Users with some visibility hacks.
This is kind of how I was introduced to Glide, and I didn’t realize that this wasn’t how it was intended to be used, but I do agree that from day 1 they were pretty clear on building internal apps rather than consumer apps.
2 Likes
At the end of the day, Glide is in the business of bringing valuable software to the world. And building software is a costly endeavour: project management, development, UI, UX, security, storage, maintenance, solution architecture for integrations, etc. Glide creators are partners in this effort. It doesn’t matter if it’s code or nocode, it’s expensive. Glide just isn’t in the business of bringing low value software to the world. So when Glide creators realize that Glide is too expensive, actually it’s just that the app is probably not valuable enough to cover the basic costs of building software (with Glide). No biggy, but the Glide team isn’t interested in going out of its way to bringing that type of software to the world.
Also it’s not just about “low” or “high” value of applications. It’s also that Glide cannot cover all use cases and they’ve had to make choices when building the platform. It’s all a question of perspective, I’m not saying that some apps have high or low value in absolute terms.
1 Like