If I make an app with all my books or all my records (easily more than 500), I wouldn’t call that a business. I don’t say an app should be free, not at all, I pay a lot for various tools, I only say: to me Glide is not per se a B2B app. Of course it’s possible that Glide makes that choice, but so far it hasn’t. Most people I know that use it do so for their holiday, their wedding, their fieldhockeyteam, etcetera.
If per-app active users in the last 30 days ≤ 5
Basic plan (Free, unlimited apps, <500 rows, limited features)
If per-app active users in the last 30 days > 5 AND ≤ 10
Standard plan ($30/month, unlimited apps, >500 rows, limited features)
If per-app active users in the last 30 days > 10
Business plan ($5 per active user, unlimited apps, all pro features)
If a business is not willing to pay 30$ per month for an app that’s going to cost them 50K up front and then support / bug fixes / upgrades / maintenance from there on,
- They are not serious about it
- They have an alternative that doesn’t have a recurring cost
- They are worried about security / non source-code app building model
- Content or areas the app automates / makes easier aren’t that critical
- They have concerns about saving their data in google - some people are cranky about saving their files (especially database) on big tech - google, MS, amazon
Again, there are different users of Glide than businesses. Glide is a really strong tool for personal use too.
I love Glide, and I want it to succeed. Your pricing model is an interesting problem, and I’m enjoying reading the different viewpoints expressed in this conversation.
I am thinking of some relevant analogs from history. In the 1800s, if you wanted a photograph, you had to go to a professional. When Kodak introduced film and the Brownie, it didn’t price them against the cost of going to a professional; they had created a whole new market – personal photography. Similarly, when cameras were added to phones, they didn’t increase the price of the phone by the cost of a camera. They introduced a whole new market – casual, instant access, social photography. In each case, there was some diminution of quality, but the new market was >10x bigger.
I know this isn’t perfectly analogous, but I hope it will encourage us to think about a wider range of potential uses and a bigger market, beyond custom app replacement and personal use.
To me, Glide’s great innovation is that it lowers the barrier for experimentation and entry. How many people have ideas for apps that just sit in their head or on a piece of paper? Probably 10x the number that actually get built. By removing the usual “too costly”, “too risky”, “I don’t have the necessary skills” barriers, Glide can potentially create a new, bigger market.
Personally, I’d be willing to pay monthly for a sandbox version of Glide that lets me experiment and pilot apps, capped or tiered by total number of rows or users across all apps. Then, if I have something that works, I can pay Glide more as it supports scaling up. A sandbox offering might be a broader and more predictable revenue stream than per-app or per-user pricing (which aren’t precluded, but are for a different use case).
Yeah, this is the story of everything internet of course, digitisation = democratisation.
Lot of opinions, lot of good reasons, thats true. What I do want is Glide going further ^^
I think what I’m reading there by your sandbox analogy is that having a ‘pay by traffic / performance’ somehow would be a nice option.
I’m looking forward to the time when people stop comparing Glide Apps to traditional app development. The availability of this platform is dramatically lowering the technical bar for people to build their own app. These ‘no code’ builders will be building small apps that fit specific unique needs… not servicing large, broad enterprise wide requirements… nor be customer facing.
Just to clarify, when you say use… do you mean admin access to the back-end? or any user that signs-in to the app?
Hi Paul, I definitely want it to be ‘customer facing’ not just for internal or small stuff
Just to say I love the engagement and contributions in this community.
@Paul working on a video atm.
Yes. I’m envisioning two types of pricing (as if I could control it, right!?):
Sandbox, fixed monthly fee: unlimited apps, all features, but capped/tiered by total rows, app users, and/or some other metric of usage “volume”. This gets revenue from people who build apps for personal use or are experimenting with potentially commercial apps. I’d push for unlimited features so the latter Glide users can build full-featured apps to pilot with potential customers.
Commercial, scale with volume: for people who build customer-facing apps. With Glide’s current limitation, I don’t think it should be per-app, but volume-based (I’m assuming that Glide’s marginal costs generally scale with data use). For example, I am working on an app that has similar functionality but can be customized by an administrator at each customer (an analog would be Facebook groups) with switches, options, etc. I don’t think there’s a way to create a single app that allows this right now (admin + user app for each customer), so I’d have to create a new app for each customer, who may have only 2-3 users. I’d be willing to pay per app user or row across all the apps, though, because that would scale with my revenue. This could be further broken into for-profit and non-profit/education/government offerings.
Some free option should still be available with more restrictions – say, <10 apps, limited volume (rows, app users), maybe with limited features. This is for people to determine whether they like Glide and want to pay for it.
Also, +1 @JackVaughan – the community is another of Glide’s great features!
Another video, wow your busy busy
For sure, I’m not discounting that productive apps will be built for large customer groups either… was just bumping up against (a little) the ‘if you don’t have $50k to spend…’ sentiment that for better or worse exists.
TBH if Glide doesn’t continue to carve out a new territory then other no code solutions coming online for traditional app building may eat their lunch… if it’s just a traditional app market setting.