No-code platforms let a business team turn a shared spreadsheet into a working mobile or web app without writing code. AppSheet, a Google-owned platform, is one of the most established: it builds apps directly from data sources such as Google Sheets, Excel, and SQL databases. The practical appeal is speed. A team that already keeps inspection records or inventory in a spreadsheet can put that data on phones within days, not months.
The qualification matters for regulated teams. A no-code app is still an app. It collects data, grants access, and syncs records to cloud storage, so the same governance questions that apply to any business application — who can see the data, where it lives, how changes are tracked — apply here too. This article explains how the category works, using AppSheet as the reference case, and what a compliance-minded team should check before deploying. This connects to our earlier piece, App-Store Review Guidelines for Regulated Finance Features: Compliance When the Platform Is a Regulator Too.
AppSheet is a no-code development platform for building mobile, tablet, and web applications from cloud-based spreadsheets and databases. Wikipedia's entry on AppSheet records that the platform was founded in Seattle in 2014 and acquired by Google in January 2020, when it joined the Google Cloud team. The distinction between no-code and low-code is worth keeping straight: low-code tools speed up work for trained developers, while no-code tools like AppSheet are aimed at business users who know basic spreadsheet and database operations but do not write software.
What can a no-code platform actually build?
The honest answer is: internal business apps, not consumer products. According to Wikipedia, typical use cases include project management, customer relationship management, field inspections, and personalized reporting. The platform's data-capture features explain why field work is a common fit. Apps can capture images, signatures, geolocation, barcodes, and NFC input, then sync those records to the cloud — or hold them on the device and sync when connectivity returns, which matters for inspections in basements, fields, or dead zones.
Display is equally flexible. An app can present the same underlying data as a table, a form, a map, a chart, a calendar, or a dashboard, and a single app can hold multiple views across multiple data sources. Workflow rules can trigger notifications or assign work when conditions are met. None of this requires programming. The platform uses a declarative model, meaning the builder declares what the app should do and the platform handles the mechanics. The trade-off, as the model's critics and defenders both note, is less granular customization than hand-written code, in exchange for speed, scalability, and built-in security controls.
How does building an app in AppSheet actually work?
Google's own guide to creating an app describes four starting points, and each suits a different kind of team.
- Start with existing data. The builder connects a Google Sheet, Excel file, Cloud SQL database, or another supported source. Google's guidance is specific: put column headers in the first row so the platform reads the data correctly.
- Start with a blank app. Selecting Create, then App, then Blank app generates a simple app with default data in AppSheet's first-party database, which the builder then customizes.
- Start with a template. A library of pre-built apps for common use cases can be copied and modified, which shortens the path for standard jobs like inspections or inventory.
- Start with Gemini. Google's AI assistant in AppSheet lets a builder describe the app idea in natural language and receive a generated starting draft to refine.
After the starting point comes customization across four areas Google identifies: data structure, user experience, calculations and rules, and workflow automations that fire on events or schedules. Sharing and management tools follow, including versioning — the ability to revert to a previous version if a change misfires — and cross-platform delivery, so the same app runs on iOS, Android, and web browsers.
Where does the data live, and who can reach it?
This is the section compliance officers should read twice. AppSheet connects through cloud storage providers and, per Google's start-with-data page, operates on three stated access principles: the platform accesses only the files and data the builder chooses; apps are accessible only to users the builder chooses; and users can reach the data only through the apps. Those are the vendor's own statements, not an independent audit, but they define the control surface a team must manage.
Compatible data sources are broad. Beyond Google Sheets and Forms, the platform supports Microsoft Excel on Office 365, Dropbox, and Box; Smartsheet and Salesforce; and databases including Microsoft SQL Server, MySQL, PostgreSQL, and Amazon DynamoDB. Every connection is a decision about where regulated or client data flows. A spreadsheet that was once a private working file becomes the backend of a distributed application the moment it is connected, and access controls set at the spreadsheet level may not match the access rules set in the app.
Offline behavior deserves a specific note. Data storage can be localized to the device and synced when internet connectivity returns, per Wikipedia's description of the platform. That is a genuine operational benefit for field teams. It also means records exist on individual devices for a period, which bears on retention policies and device-loss procedures for teams handling sensitive information.
What should a compliance-minded team check before deploying?
The deployment decision is less about the builder's skill than about governance. Google's documentation describes both a self-service model and a corporate licensing model offering more governance, data analytics, and performance options for larger organizations. Which path a team takes shapes what oversight is possible. Practical steps, in rough sequence:
- Classify the data first. Inventory what the app will collect — signatures, location, photographs, client names — and whether any of it is regulated or confidential.
- Map the data sources. Every connected spreadsheet or database is a data location. Confirm where each one lives and who administers it.
- Set user access deliberately. Apps are visible only to chosen users, so the chosen-user list is the access-control policy. Treat it like one, and review it on a schedule.
- Use versioning. The platform's revert capability only helps if changes are made deliberately and tested before deployment to the working group.
- Plan for offline records. Decide how long captured data may sit on a device and what happens when a device is lost or a user leaves.
- Document the app itself. A no-code app built by a business team still needs an owner, a change log, and a decommissioning plan, exactly like any other system.
Teams that already manage app-related obligations will recognize the pattern. The governance questions echo those raised elsewhere in this publication's apps coverage, from update lifecycles in regulated finance to the security governance of code an app did not write. A no-code platform compresses the development timeline; it does not compress the accountability. For related coverage, see The Mobile SDK Supply Chain: Security Governance for the Code Your Finance App Didn't Write.
What this means in practice
For compliance and legal-ops teams, no-code tools like AppSheet change who builds software more than they change what software obligations exist. Three implications follow from the sourced record. First, the barrier to app creation is now low enough that business units can deploy data-collection tools without IT involvement, so governance frameworks should assume unsanctioned apps exist and provide a fast, legitimate approval path. Second, the platform's structure — chosen data sources, chosen users, declarative logic — produces a natural audit trail if the team documents its choices at build time rather than reconstructing them later. Third, the choice between self-service and corporate licensing is itself a compliance decision, because the governance options differ.
One caution belongs in every such deployment. Spreadsheets accumulate. An app built on a working file inherits that file's errors, duplicates, and stale rows, and no platform feature repairs them. Cleaning the data before connecting it is unglamorous and decisive.
This article is information, not legal advice. Teams handling regulated data should consult qualified counsel about their own facts before deploying any application that collects or stores it.
