Feature roadmap, user voting

Sure. These come to my mind

Commercial: Productplan, productmap and canny.
Open Source: Logchimp, astuto, fider and clearflask

1 Like

I 100% agree, @JonL!

The team and the product are great, but from my point of view, Wappler is not a tool to create websites with no code tools, but a robust low-code editor to create web and mobile applications!

The feature requests are not working, even the most voted features are not being developed.
I appreciate the team effort, but a clear roadmap would be great indeed!

If Wappler is trying to be a “no-code” tool like Bubble, I think it’s the wrong way and a waste of opportunity to bring pro devs (more users) to create a real new way to create apps.

My two cents :smiley:

1 Like

Yes, the team is too secretive and sucks to not know their roadmap. Would also be interesting to know what the new hires are doing

Excellent request!
I’m finishing my current project in Wappler next month, so I’m thinking if I should start a new project in Wappler too, or should I try something else.
Open roadmap really would help to decide.

But I kinda understand why the Team maybe doesn’t want an open roadmap and open discussion about it.
Because as I see it, the Wappler community is largely diverse. From experienced coders to green nocoders. And everyone wants different things. So there is no possible way to make a solid roadmap that will satisfy everyone.
In each scenario there would be a group of users that are gonna say “hell no, I’m out of here”.
So keeping everyone in the dark maybe is a way to keep all users here. So everyone thinks “maybe next month will be an update I have been waiting for so long”.

But it’s not fair. Let people know.
Yes, someone would be disappointed, someone would leave or take a pause. There would be a lot of accusing and fighting and tears.
But it would be the honest way.

You’ve voiced what I’ve been thinking about for over a year.

Wappler versions 3 and 4 were programs filled with extremely useful features that were in demand in the daily routine of development. Also during this period, we often discussed on the forum functions that would really be useful in the future for creating even more complex and high-quality applications, as well as facilitating the development routine (this is what I consider the key value of the Wappler). But the latest version has gone in the direction of a beautiful wrapper, rather than the development of new functions that help in creating complex applications. And the inability to follow the development plan and make predictions about the time of implementation of the necessary functions creates unpredictable working conditions in the long term. Obviously this is just my opinion and other users may disagree with it.

For the above reasons, I am increasingly starting to think about the idea of switching to a new technology stack, although obviously I would like to avoid this and stay with the Wappler as long as possible.

1 Like

I’ve been thinking the same for past half year. Last major feature that Wappler’s team has made was - Tagify (not ideal product, but yet something).
There are SO MANY feature request with high numbers of votes. From other perspective - there are still bugs that been reported and wasn’t reacted by Wappler’s team or still waiting to be fixed.
So I believe there will be always dilemma for focus: new feature or bug fixing. Especially which such small team.

am not tracking version numbers.

  • the update for nested table support in query builder was pretty big for us.
  • form repeat is awesome.
  • ability to dynamically choose DB conns, etc. via env was also big help for us.
  • plus they focussed on bug fixing for sometime in between - and improved as well few tanglible things, which was good. long way to go, but good. esp. how responsive wappler app itself has gotton.

am content for now.

public roadmap would be a welcome change - strongly in favour of this.
limited votes per user to prioritise on those and other user requests would be really nice as well, given how community driven Wappler is.

and i keep an eye out for alternatives pretty regularly - nothing comes close as of yet. not feeling stuck, by no means! but just to not miss out on something better if at all it comes along.
like when we found Wappler we left Webflow (for design)+manual coding on that html for good - which felt good enough back then but now i’d never go back.

tagify, yes. recently started using and it is very good to have as well.

Like others in this thread, I think it would be helpful if more information were available about progress on new features - and perhaps also why certain requests are problematic and unlikely to be implemented.

There are different categories of feature request. I don’t think implementation should necessarily depend on the number of votes. Eg I think there are some feature requests which could be described equally as ‘missing features’ which should be implemented regardless of votes. A good example is the Switch Case/Else-If Function in Server Connect request. As it happens, this also has a large number of votes. It’s also an example of the tendency to “lose focus on delivering features”; I think this was about to be added to Wappler but it didn’t quite happen. Perhaps there was an unforseen problem with this ‘feature’. It would be helpful to know - and if it’s still in the pipeline.

Well this is actually the eternal battle. When we add many features people complain that we should stop adding new features and focus on bug fixes. When we do exactly that people start complaining that they don’t see any new features.

So it is always a balance we try to follow to keep everybody happy.

However if we even add new features, they might not appeal to everybody because people are waiting for their own specific features and when those doesn’t get implemented quickly, they also feel like no new features are being added.

So it is not always about good progress in new features it is also people perception about the progress. Everybody sees progress differently according if it fit to them or not.

So again we try to balance that, but sometimes we give a bit more priority to other things, like stability and solving bugs that we have done recently.

When adding many new features quickly we increase the technical debt, more new bugs are created and docs need to be updated / created. Eventually we do need to catch up on the technical debt and go for stability and bug fixing. That is what our focus was recently, weekly we have been resolved 20-30 issues and catching up on bugs that were even reported years ago.

Also new technologies takes time to develop next to bugs fixing. We have been working on major App Connect improvements, you saw great speed improvements there already and now it is also time for major client side flows improvements to be able to work fully client side on database in mobile and desktop apps.

So a lot is going on and many you might not see directly. Either because it is in the background or because you are waiting for your own feature X only.

As for new features and roadmaps, we do follow the feature requests list and find the voting there very useful. Weekly we implement features from there.

So we can start making other roadmap lists but they will quickly get separated and outdated and it will cost much more time to keep up. Also when the features from roadmaps doesn’t get implemented quickly, we will only get topics like: why you didn’t implement feature X - it was on your roadmap …

Wappler is also evolving on a weekly base, so you can’t just pinpoint all new features to version 5 for example (or lack of them) they are usually being in the making and released gradually weekly already from the time the previous major version was released.

I can understand that when some feature requests aren’t implemented quickly it can feel that they lost priority. But that might be because also the community lost interest as well? That is why we encourage to keep on bumping those feature requests and keep on involving the community - this also increase our priority. The more people request a feature, the quicker it will get implemented. So keep on bumping those feature requests so more people can vote on them.

We do keep a list of all weekly updates of the new features at:


And for detailed info about all the bug fixes you can also refer to the weekly change logs at:


We are continuously working on improving visibility and be more clear about upcoming implementations.


That is what I mean with features developed tears-oriented. It doesn’t matter how many votes it has or how long it has been pending. Bumping, campaigning and nagging is what works.

This strategy is similar to those that get higher salaries are the ones that make more noise. Really frustrating.

Unfortunately people get bored of requesting and bumping and that doesn’t mean that the feature isn’t important.


15 votes in 24 hours. I would say it’s trending. It’s a new feature request not like that stupid old “if-else/switch” request that nobody wants.

We are campaigning for a roadmap and a better way of taking into account votes.

So what is holding you back from giving us a roadmap and a better way of voting and taking them into account?

@wappler_pro I would really appreciate if you could vote on this request as we need to campaing to get it delivered :slight_smile:

All I want for Christmas is for Wappler Security Provider to allow me to use more options for example like, Auth0 or other authentication and authorization platform.

I feel like this is a big deal because building out one own authentication system with what Wappler currently can be a liability for you the developer and the client you are building an authentication and authorization system.

Wappler is a great product but there are a few items that can prioritize right now that will make my life and other developer life easier. One would be, allowing for us more options to choose from for building authentication and authorization system in Security Provider and the other is allowing us to deploy docker container to Kubernetes on Google Cloud, Azure, etc this way we can scale our docker app more efficiently by using tools Google Cloud and Azure offer for dockerized apps etc.

That’s my two cent and I totally see where @George and @JonL are coming from and I do too get frustrated when I have to pass on projects that I know Wappler can not handle because of those two items I find limiting to Wappler tool thus far.

I have to agree with a lot of this thread.

For me, the only feature I’m actually using that’s been added in 5.0 is Tagify, however, just like everyone else has mentioned, it’s only about 80% there. I’m using several workarounds to get it working correctly, and it just becomes insanely messy.

This is something I also don’t understand. The thread with the most upvotes currently hasn’t had a single reply on the status of it since 2019, yet features with far fewer votes are being added what seems like randomly. Same with the second, third, and fourth highest upvoted feature requests too. It would be nice to know what’s happening with these.

I guess this could be a very unpopular opinion here, but if existing subscriptions were updated to the newer pricing, I’m almost sure I would have cancelled.

I don’t think anyone is complaining about there being a lot of bug fixes recently, because they are definitely needed, but it would also be nice to know what the plan is beyond those, with a status update on those most requested features. People aren’t going to continually go back to a thread from 2019 to bump it over and over again when they’ve already voted.

I know this is going back a fair bit here, and is slightly unrelated to what’s been said here, but I vaguely remember something about the new account management portal/site not being built on Wappler, which really doesn’t install a lot of confidence when the developers of the product can’t use it for something it’s designed to do. I think (although I may be wrong here), it was said it was done for security, which raises even more questions.

Most of my projects are complex, but not as complex as others I’ve seen on here, and if I’m already using several workarounds I really wonder how many people that are building very complex sites are having to use.

Maybe post a separate topic explaining about the rest 20% which are not there, so that we can improve that?


As Patrick explained a few months ago:

So there’s nothing to really be concerned about the Wappler security scripts/options.

As a PHP developer/designer, I haven’t seen a new feature that make me go ‘Wow’ since probably Wappler 3 other than UI changes. Of course I wish for new PHP features but that just isn’t going to happen and I’ve come to accept that.

Having said that I am not leaving wappler anytime soon. I am at the age now that this will likely be the last tool I ever use/need.

Thank you to the Wappler team.

By 80% there, I mean in terms of issues that have yet to be resolved. I’ve made 3 threads on it myself in the past, and I know there’s a couple more by other people. An example of that 20% is the hide issue, where I have to use workarounds to hide the inputs:

(Still a problem, using workarounds ) Dmx-hide/dmx-show does not work on Tagify text inputs
(Still a problem, seems to be something with specific expressions, I have to use two tagify inputs as a workaround for this) Tagify: No Custom dynamic attribute disables input entirely
(I don’t get the logic behind this, again results in many workarounds) Tagify add/remove event triggers when value is set through dynamic attributes

1 Like

Communicating about the roadmap would be useful.

Voting is less needed in my opinion; I can imagine it would add an additional layer of stress to the team.

Too many. But at least Wappler is flexible enough to allow that. With something like Bubble, we could not build such complex systems.

One big sort-of-workaround we have in each project is our role-based-access-control system over Wappler security provider. As Brad has pointed, having more third-party integrations could improve this, but its very difficult to get it just right.
Even with our system being used in at least 5 different projects, evey implementation has some custom requirement layer added.

Ok there you go :slight_smile: