I want to nudge Thunkable to consider increasing the number of private projects that a Pro member can have. Right now, the limit is 50. That actually sounds like a lot. It’s unlikely that a user is going to create more than 50 different apps and need them all to be private.
Here’s where things get complicated. As of now, there is no version history support in Thunkable. I’d love to see that added but I imagine that’s a pretty big upgrade to the software. So as I’m working on a private project, in order to (a) keep a backup in case something goes wrong and (b) keep multiple versions to test different methods of coding something, I make multiple copies of each project. If I’m working on a project for a short while, I might have 3-4 copies by the time I’m done. If I’m working longer, it might be as many as 10 copies.
So, suddenly, that 50 private project limit looks really small. It means I can only create 5 larger apps. That’s quite limited for something that is supposed to be a Pro account.
I just checked and I have 237 private projects. Is that excessive? Yes! I can certainly go through and delete copies I no longer need but by my estimate, I’d still need at least 100 projects for my active apps and backups. Also, several bugs (reported in GitHub) in the Projects page have prevented me from being able to manage and reduce that number effectively, at least in the past.
What would it look like to increase the number of private projects to 100 for Pro users? Or to 250? I know I’m in the minority here as most users probably do okay with a limit of 50. So I’d be curious to hear from other users who are coming up against that limit. Maybe it’s just me…?
And sure, I could consider a Business membership for four times the annual cost. But as I’m not a business, just an individual, I really can’t afford $2,000 a year.
Edit: I went through and deleted a bunch of unnecessary copies of projects and you’ll be happy to know that I’m down to the new low total of 192 private projects!
i have not run up against the limit, but i have a lot of projects since sometimes you have a thought and start building to see. I have been unhappy with the fact that pro lost functionality in the new tier system. i think, at least for legacy users, we should be able to have all the features we are used to using without upgrading to business as this is way too expensive for private developers.
@tatiang We are currently exploring some ideas in regards auto versioning. It’s definitely something on our minds but it is also a big undertaking with a lot of moving parts and things we need to get settled first (e.g.the amounts and limits of this feature and a bunch of other stuff). But we are actively looking into this and that is a good thing!
@conroy33 I’m so glad to hear that! Yes, I imagine it’s not easy to move to a system like that but I think it would be a good selling point for Thunkable and would ease users’ minds about the experience.
I’m bumping this topic because it’s still a big problem with Thunkable. Not having a working version history system (yes, it works but only for one version!) means that many of us have to rely on saving multiple copies of projects while we’re working. Thunkable is not free from bugs and the safe way to use it is to make backup copies in case something goes wrong.
So we need to have more than 50 private projects available as I detailed above.
Edit: I managed to get my private project count down to 120. Yay! But I’m currently deleting my only backups of projects which is scary. Even with that, I don’t think I can get to 50 which means that every new project I create is by default public. Which is also scary.
how many backups of a single project do you really need? especially as a team of 1. 3? 5? In essence, by adding versioning, thunkable effectively doubled the number of projects we can save. only it’s a backup and not a copy. (pretty much 6 of 1, 1/2 dozen of the other)
I live on the edge and usually only have 1 backup copy and it’s almost always outdated. unpopular opinion, BUT I’d say if you need more than a few backup versions for hobby projects, you might be doing something wrong. If it’s for a business, i can see the benefit of being able to roll back a few more versions.
I just wonder how many. backups of each project you try to keep.
I’ll admit to being an amateur developer and programmer so my methods of storing projects are not as organized as they could be. But it’s typical for me to try something a bit daring with my code. There are enough instances when something doesn’t work with Thunkable that I have to switch directions and re-work a major part of my code. So instead of having a bunch of floating disconnected blocks in a project, I prefer to make a copy of the project before I start that process. That becomes a safe backup in case I really mess things up. Then, as I’m working through the new “daring” approach, I’ll want a backup of that in case I accidentally delete something (very rare) or need to revert back. So that’s already three copies of each project.
I’m taking steps to reduce the number of projects. I used to create a new project every time I helped someone on the forums with a demo. I now realize that’s not necessary so I have a single project for all of the demos I make.
This is all complicated by the fact that there used to be two bugs: (1) duplicated projects had the same name as the original and (2) duplicated projects had the same modification date as the creation date of the original. This means that I have a bunch of projects called something like “DVL layouts copy” all with the same last modified date. I have no way of knowing in what order I created those or when they were last modified. So checking and deleting the right ones is time-consuming!
So, I am giving this a bump as I think that it is very relevant. However, if an upgrade in project limit or project versioning is a problem to implement in the short term, maybe backups are a middle ground.
The ability to create local backups would allow us to save projects before we make major changes. I see that this has come up in a few threads over the years and hope that it can be given some thought by the developers.
