Who this is for
Business owners, operations leaders and technical buyers comparing AppSheet developers or agencies for a production business application.
Start with the data model, not the interface
An AppSheet application is only as dependable as the records behind it. Ask how the developer will define stable keys, references, parent-child relationships, status fields, validation rules and historical records before building views.
If a workflow depends on selecting the latest row, matching text names or editing a shared spreadsheet without controlled keys, future automation and reporting can become fragile. The technical design should explain how records stay linked when the business grows.
Ask how roles and edit permissions will actually work
A production app should define which users can see, add, edit, approve or delete each kind of record. This includes row-level access, field-level edit conditions, role changes and administrative exceptions.
Do not treat a hidden view as a security boundary. The developer should understand the difference between interface visibility and data access, and should explain where access rules are enforced.
Review automation, failure handling and ownership
Bots, scheduled events, emails, PDFs and external integrations need more than a successful demo. Ask what happens when a required value is missing, a provider rejects a request, a duplicate event occurs or an employee account is removed.
Production ownership should be explicit. Client-controlled data, accounts and credentials are generally easier to maintain over time than an undocumented workflow that depends on one developer account.
Check integrations and platform limits before committing
AppSheet can work well with Google Workspace, Apps Script and approved APIs, but platform limits still matter. Volume, sync behavior, licensing, offline needs, public user journeys and complex product UX can change the recommended architecture.
A credible AppSheet developer should be willing to recommend a custom web application or another platform when AppSheet is not the right fit for the workflow.
Define testing and handover before the build starts
Agree how the developer will test permissions, status changes, automation, edge cases, duplicate records, offline or sync behavior and integrations. Testing only the standard path leaves expensive surprises for production.
The final handover should make the data model, important expressions, actions, bots, dependencies, credentials ownership and maintenance process understandable to the client or future maintainer.
FAQs
What should I ask an AppSheet developer before hiring?
Ask how they design keys and relationships, enforce access, structure automation, handle failures, test changes, document dependencies and transfer production ownership. Screens are only one part of the system.
Should an AppSheet developer work directly on my live app?
Important changes should be tested in a controlled copy or agreed test environment where practical. The exact method depends on the application and data source, but production changes should have a rollback and verification plan.
Can AppSheet connect to Google Sheets, Drive, Gmail and APIs?
Yes, depending on the workflow and platform capabilities. Google Workspace, Apps Script, webhooks and approved APIs can be combined, but permissions, quotas, credentials and failure handling must be designed clearly.
When is AppSheet not the right choice?
A custom application can be better when the product requires highly custom public UX, deep real-time behavior, unusual scale, specialized infrastructure or technical control beyond the platform model.