QuickBase, the defacto standard for developing Business applications for the Web.

QuickBase is being used at a federal agency that I worked at, for their core business activity. It helps the management and the staff alike be able to track their cases across all the 5 major departments within the organization. It also helps the public file their legal cases with the agency electronically thus reducing the time and improving the accuracy of the filing.

Like I mentioned in the pros of using QuickBase, this product can shred the amount of time one needs to design, build and deploy web applications, with as little infrastructure as you can. At the federal agency I worked, we migrated from an Oracle Forms based case tracking application to QuickBase. As a result, the cost to hire and maintain Oracle DBAs, Unix System Administrators was totally eliminated. QuickBase takes care of it all!
So as application developers, we could move quickly from requirements gathering to systems design to development, testing and deployment in weeks as opposed to months and years for each component. We didn't have to worry about load balancing, maintaining our servers or maintaining our platform etc.

QuickBase would like to think or have customers think that this is a citizen developers' tool. But I beg to disagree with that because, one needs to have knowledge of relational databases, the concepts of normalization, the need to normalize, how relationships work, how the summary fields, lookup fields work, etc to be able to develop a meaningful and useful application that can be maintained in the future.
I have first-hand experience developing applications for some DC Govt agencies where they had "citizen developers" such as administrative assistants, finance managers, and human resource managers develop applications only to have me come in and redo them "correctly." As an example, when you had to modify the name of a person, the systems developed by the citizen developers were such that one would have to modify the name of the person in 8 different tables, all in the same application! But I designed the systems so they can change the name in just one Employees table and the lookup fields would take care of effecting the change across the applications.
Thus, I would strongly recommend that businesses should consider having experienced professional programmers who have experience and education in developing applications do the job.

I have maintained several QuickBase applications, across several of my client organizations. The best way to make changes to an existing QuickBase application is to use the Sandbox feature. If you are creating new reports, you SHOULD do it in the existing production application. But if you have to make changes to the table structures, relationships, forms etc, you should create a Sandbox from the production application, migrate some data from the production version or otherwise, make the changes necessary, test it and rollover the Sandbox to production.

There are pitfalls just like in any other application development environments. They can be aggravated in QuickBase, because of how quick it is to do something with QuickBase. Just as you can do several productive things quickly, you can even make mistakes very quickly (probably why it is called Quick Base.) So the best way to handle deployments is to have a plan.

I always have had a living document for the deployment plan, that I would start right after I create the Sandbox. Through out the development/maintenance phase, I keep documenting everything that needs to be done at the time of deployment. Otherwise, it is very easy to lose track of the tasks you need to do, leading to grave errors. At the end, it is extremely easy to review the deployment plan document and quickly estimate how long it is going to take to deploy and deploy it without errors and in a timely manner.

One note of caution to QuickBase administrators: NEVER delete the connection between the production application and your sandbox. You WILL lose all the changes made in the sandbox.

App Tokens and User Tokens from QuickBase are pretty powerful in combination with roles and permissions. Using these within the UiPath bots, I was able to make sure the data is inserted in a controlled and secure manner. In other places where I designed and developed QuickBase applications, we used SSO. In a Federal organization, I had used the "Everyone on the Internet" role that allows the large customer base to be able to add/modify their own data in a controlled manner. I had even implemented a custom user management and password management module within QuickBase that has all the regular provisions such as Registration, Login, Forgot Password, Auto-signoff after 8 hours of usage if the user has not signed off, etc. These measures not only saved the client money for user licenses across the world but also made sure they are in compliance with Federal security standards.

The trend is going toward low-code. While QuickBase is already a low code product, there are other features QuickBase can incorporate such as drag and drop coding like in UiPath, diagram coding like in Appian/Pega and so forth. Personally I feel it is a bit too much to do all that. But since that is the trend the world is going toward, I think QuickBase (and me too) need to think on those lines.

When I lost some data and I raised a support case for restoring the data, QuickBase support did a phenomenal job of restoring the previous day's copy on a very short notice.