I’m about to go live with an app and have set up a system for users to request changes, fixes etc.
I’m keen to do this properly and release changes in a controlled way. I know I could make changes and not publish, but sometimes I want to publish to be sure that something is working (like custom code) and Preview doesn’t cut it.
How do you keep a ‘next version’ away from your users? Do you have multiple apps?
I agree. Best practice questions like these are the biggest area I am unsure of and would really appreciate guidance.
They have the Preview feature but then I guess you would have to open up the preview ability to your customers.
I have for many years used the “well known” feature flag pattern on hundreds of builds with what we call trunk based deployments so all features are on production (lots of good research about the value to this compared to a versioning approach or branching)
But the only way I can imagine doing that in Softr is using roles to hide new pages and or blocks and only users in this roles doing qa can see those features.
As for database changes those can be done this way as well but not sure if Softr has field level UI permissions but then again blocks are so easy to create you could show or hide new blocks based on the users role.
A link to the book that touches on the concept is here
I don’t think this answers it. The preview feature is great but it doesn’t really allow me to properly test major changes before deploying a new version.
I can’t be the only person facing this. How do I build the next revision of a live system without releasing it to my end users? Is copying the app the way to do it?
@Jjenglert anyone from Softr able to answer this?
I don’t understand why the preview feature does not offer you enough functionality to test before going live? In preview, you can test with users, with custom code, etc.
One suggestion to be to duplicate a page you are working on. Set visibility to user group “admin only” and then you can have a page in production to test what you need, and only you can access it.
Alas we are on a basic plan and so don’t have the user groups I would need to achieve this.
@Bitstreams interesting topic. Let me asking you this, what is a major change?
Ok, let me first say I’m not a developer - but this is a no-code, low-code utility 
On the current app I’m making a change to the UI, so that there’s a more intuitive place to find help documents and version information and a place to request enhancements. I’m moving this to an area under a navigation menu rather than the home screen. When I launch it to the users I’m going to have to update some of the training materials. This is a planned change in the development schedule and is due to go live in a couple of weeks.
Then I get a call to say that one of the action buttons, say an edit of a particular record, has a field that isn’t working - or has a field that is missing. It’s an easy 2 minute fix but it needs to be actioned immediately.
What I expected was to be able to apply the urgent fix to the live version and publish, but then also apply the fix to the ‘next release’ version. That way the users don’t see the UI changes that I’m not ready to deploy.
My answer to this is to copy the app so that the development work is happening on the copy, not the live environment, but then how do I make that copy ‘live’ when I’m ready?
Ok I tried to use ai (below) to explain the “feature flag” pattern vs the “feature branch” pattern, that you are doing, so you can see the advantage to the feature flag pattern and how you can apply it here. Let me know if you have more questions this is such a common struggle in and out of no-code frameworks!
Here’s an updated version that adds your point about feature branches (in a simple, non-tech way) without repeating and also includes a reference to DORA research for “elite teams”:
Hey — good question. What you’re describing is exactly what software folks call feature branches — meaning bits of the “next version” are developed in separate copies or branches. That pattern quickly becomes hard to manage, for a few reasons:
If something breaks in production, you have to patch it there and then apply the same fix across all your feature branches.
Over time, those branches diverge more and more, making merges painful and error-prone.
The more branches and versions you have, the more overhead — you lose agility.
The approach I’m recommending (feature flags + single production line) is just as proven — but much simpler to maintain. You accept that you will have issues in production sometimes (it’s inevitable), but you design your system so that when things break, you can fix them quickly without juggling multiple versions.
If you want something to refer others to, here’s a resource about how top (“elite”) software teams use practices like trunk-based development:
DORA’s site has a page on Capabilities: Trunk-based Development that describes how high-performing teams use small, frequent merges instead of long-lived branches. (dora.dev)
Also, LaunchDarkly has a blog post summarizing how elite teams are 2.3× more likely to use trunk-based development versus those with long-lived branching patterns. (LaunchDarkly)
If you like, I can find a PDF or academic-style DORA report you can drop in the thread (so it looks more “official”) — want me to dig that?