About a year ago, I wrote about using low-code or no-code for application development. I want to revisit this topic and outline why after two months of working with Google AppSheet, I quickly abandoned the project and switched to a different solution.
Many insurmountable roadblocks mounted fast with Google AppSheet…
Reason #1 – No-code applications have poor integration capabilities
The first was that I needed to work with ChatGPT or other AI tools to assist with the content writing process. Google AppSheet does not do this natively. It required using Google Apps Script. I also needed to send data to web hooks to be processed and data returned back to the application.
Google Apps Script was not the major hurdle, as I have several working applications using Google Apps Script. Working with AI tools required handling authentication with different methods, including OAuth.
Reason #2 – Low-code Applications May Require External Scripts (with timeout limitations and quotas)
The second major hurdle was that the Google Apps Script would need to run longer than the timeout quota. Due to this challenge, the code could never finish or return data. Google Apps Script required a third leg using Google Cloud Functions to process the data. I can code a Google Cloud Run Function quickly using PHP. That was not the problem. The problem was that the Google Apps Script would have to be run as a web app that “listened” for the data and inputted the information into a spreadsheet.
Reason #3 – Low-code & No-code applications Have Poor Security
The second issue (and it relates to challenge #1) led to the third issue: security. The Google AppSheet, Google Apps Script, and Cloud Run would have to interact with several APIs to complete their processes. Storing individual OAuth keys, usernames, and passwords became a problem. How to store authentication credentials became a big headache.
Reason #4 Google AppSheets Poor Documentation
The fourth challenge with Google AppSheet is the inconsistent documentation. Google’s documentation is hard to understand. Believe me, it took years to learn how to decipher Google Cloud and Google API PHP SDKs (yes, I did decipher that documentation). I became confused with Google AppSheet documentation, and this quickly shattered my use of Google AppSheet.
Reason #5 – Low-Code & No-Code Lacks Extendible With Other Programming Languages
The fifth challenge was not really a challenge. I could develop a fully functional, extensible, and much more highly secure web application faster using Symfony & PHP. I had to use PHP with Google Cloud Run anyway. I already had a server and database. Migrating from Google Sheets to a database seemed much more logical. I could still automate business processes and integrate third-party APIs quicker.
Reason #6 Google AppSheets Lacks Data Privacy
The sixth challenge that quickly became apparent was data privacy concerns. It was difficult to scale Google AppSheet to external customers without exposing other clients’ data. Tighter data management controls were required for the application. It was difficult to create spreadsheets that limited user access to certain data or other peoples data.
Reason #7 No-code Use Cost: It can be expensive
The seventh reason I abandoned Google AppSheet was the cost. Once the Google AppSheet goes into production, it’s $5 per user per month. The cost would quickly escalate just for the business use case I had in mind. The cost per month would quickly become impractical.
Reason #8 -Google AppSheets Inflexible User Sign Up
Reason number eight: Google’s own sign-in process was a deal killer for our app requirements and business use case for Google AppSheet. Users are required to have a Google Account to use the application. We needed to verify users based on approved domains and user email addresses, IP addresses, and other security checks. There was no addressing this elephant in the room.
Reason #9 Portability & Scalability – Yeah…..It’s a HUGE Deal Breaker
Number nine might seem trivial to some people. We listed out several requirements for our internal application. Scalability and portability were two major concerns. It’s called vendor lock-in. Google AppSheet locks you into its platform. You cannot move the application to another server when the time comes. The development time and cost to migrate were tremendous. We needed to be able to move the code to new servers, maintain continuous integration/continuous delivery (CI/CD), version controlling (Git versioning), and a customized UI complete with branding.
Reason #10 -Low-Code Offers the Inability to Brand the App
The tenth reason I abandoned Google AppSheet is because the UI was clunky with hardly any customization. CSS, LESS, and SASS are not a problem or challenge if you have built any kind of modern web design. I demand a lot and branding is a big issue. Building user trust for a brand is critical. I needed to use custom domains. I considered using Flutter, Firebase, and AWS Amplify, which are low code applications. None of those fit the requirements required of our application. Our business use case required cross-platform capabilities. So this kind of shot Google AppSheet into the trash.
What We Decided – Low-Code & No-Code is great…..until it’s not……Know Your Business Use Case & Requirements……
After finding workaround after workaround for each issue we faced, we finally did a benefits analysis diagram to uncover the positives and negatives of using a custom-coded application versus using Google AppSheet. The benefits analysis chart uncovered the CI/CD issue, versioning control requirements, and extensive integrations with WordPress, our chosen email marketing automation platform, payment systems, and our accounting system. We needed to be able to extend the platform to a complete business application for internal teams, vendors, clients, and contractors. We even listed business use cases to integrate Google Ads API into the application.
More On Our Application Requirements
The requirements document also uncovered the need to integrate AI and workflow automation tasks into the application. Once the requirements document gave insight into our business processes, it was clear that Google AppSheet would not meet our business needs. Complete a cost-benefit analysis to discover if a no-code or low-code solution application will work for your business.
Downsides +Challenges to consider: Low-Code/No-Code Verse Custom Application
One of the downsides to switching from AppSheet to a full web app was the focus shifting from data design to full system design. I have tremendous experience with WordPress, but Symfony posed its own challenges and learning curve. But, I was able to move forward with those challenges because Symfony is based on a Model View Controller framework. Symfony uses Twig, which was another learning curve. But other open-source platforms I use also use Symfony and Twig, which were bonuses for me to learn how to work with it.
I still have challenges designing relational databases, but Symfony uses ORM and Doctrine for database design. Database design is abstracted away, and you only focus on what data needs to be present. Another concern with a full custom application is code maintenance. APIs change over time, and code has to be updated. Custom apps require a team of developers with a high cost over time.
For non-developers, low-code is still a way to build internal applications. Low-code applications are not meant for broad system usage or as a means to sell a digital product.