What does an AppSheet developer actually build?
An AppSheet developer designs the tables, screens, rules and automations that turn spreadsheet rows into a working business app. The platform is no-code, but a good build still needs someone who thinks like a database designer, a UX designer and a tester at once.
In practice the work splits into four layers. First comes the data layer: which tables exist, what the key column is, how a visit row points to a customer row, and which columns are calculated. Then the UX layer: views for each role, form layouts, which fields appear only when another field has a value, and how a rep finds the right customer among eight hundred. Third is behaviour: actions, validation expressions, security filters, and slices that show a manager only their region. Last are automations: bots that send a PDF, email a supervisor or call a webhook.
What an AppSheet developer does not do is magic away the limits of a spreadsheet. If you want customers to pay inside the app, or you expect half a million rows by next year, the honest job is to say so on the first call and point you towards custom web application development or a native app.
- Field forms with photos, signatures and location
- Stock movement with barcode or QR scanning
- Attendance and shift check-ins
- Approval flows for expenses, leave or purchase requests
- Inspection and audit checklists with PDF output
When is an AppSheet app on Google Sheets enough?
AppSheet is enough when the app is for your own staff, the data stays in the tens of thousands of rows, and the logic is forms, lookups and approvals rather than heavy calculation. Most small field teams, single-site stores and internal request systems fit that description comfortably.
A useful rule we give clients: if you could describe every screen as "fill this in, see that list, approve or reject", AppSheet will probably serve you well for years. Your team already knows Google accounts, the data sits in a sheet your accountant can open, and changes take hours rather than a release cycle. An experienced AppSheet developer can also make the app feel tidy enough that staff actually use it, which matters more than any feature list.
It is also enough when the budget is modest and the need is urgent. A distributor who wants delivery confirmations with photos by next month does not need a six-week custom build. They need a clear data model, three good views and a bot that emails the day's deliveries at 7 pm.
Green lights for AppSheet
Internal users only; under about twenty tables; Google Workspace already in place; data volumes well below the limits Google documents; no card or UPI payments inside the app.
Amber lights
Hundreds of users across many roles, heavy photo use offline, or reports that need complex joins. Still possible, but plan the data model carefully and budget for Apps Script or a dashboard alongside.
Signs you have outgrown AppSheet and need a custom app
You have outgrown AppSheet when sync takes long enough that staff stop trusting it, when customers or dealers need to log in, or when the business rules no longer fit into expressions and bots. At that point more no-code patches cost more than a proper build.
The size ceiling is documented. Google's AppSheet Help page on data size limits says the compressed data for one app is capped at 5MB or 10MB depending on the device, and advises not to exceed 100K rows or 1,000 columns in a spreadsheet. The same page warns that performance usually suffers well before those limits. Google Sheets itself holds up to 20 million cells per file, according to Google Drive Help, so the app tends to strain before the sheet does.
Other signals are softer but just as real. You want push notifications that look like your brand. You need an app listed on Google Play under your name for customers. You want offline maps, complex pricing rules, or integration with a Frappe/ERPNext system in both directions. Any AppSheet developer who waves these away is selling you the next rebuild.
- Morning sync takes minutes on ordinary phones
- Security filters are getting too complex to reason about
- Customers, dealers or patients need their own login
- Payments, OTP login or store listing are required
- The sheet has become the bottleneck for other tools
How much does an AppSheet developer cost in India?
With BtechWaleTech, an AppSheet build starts at ₹40,000 (about US$600) for a focused app, with the final figure set by scope in an itemised quote. Across the market, quotes vary widely, so compare what each quote includes rather than the headline number.
Here is what actually moves the price. Tables and relationships: a two-table visit log is a different job from a twelve-table distribution app with customers, routes, orders, returns and collections. Roles: every extra role that sees different rows adds security filters, slices and testing. Offline and media: caching photos for offline use, compressing images and testing on low-end Android phones takes time. Automations: each bot, PDF template or webhook is a small project of its own. Existing mess: cleaning a sheet with merged cells, free-text dates and duplicate customers can take longer than the app.
Licences are a separate line that you pay to Google, not to us. We explain what you need in the quote and point you to your Google Admin console for current pricing. If the scope looks likely to outgrow AppSheet, we also show the custom alternative, starting at ₹40,000 for a mobile app, so you can compare two real options.
Is AppSheet free with Google Workspace? Licensing explained
Often, partly yes. Google's Workspace documentation lists AppSheet Core as included with most Google Workspace editions, including the Business Starter, Business Standard and Business Plus plans, following a change Google announced on its Workspace Updates blog in July 2023. Check your own edition in the Admin console before assuming it.
Three licensing points save confusion later. First, AppSheet's help page on choosing a subscription says the licence needed to use an app depends on the app creator's licence, so a Core-built app needs users on Core or a User Pass. Second, AppSheet's pricing page says you can prototype and test with up to 10 users at no cost, which is how we build and demo before you commit. Third, some features sit only in AppSheet Enterprise Plus, including SQL database sources such as MySQL, PostgreSQL and SQL Server, machine learning features like OCR, and organisation-level governance policies.
For most Indian SMEs on a Business plan, Core covers Sheets-based apps, barcode scanning and security filters. An AppSheet developer who understands licensing will design within Core where possible, and flag in writing any feature that would push you into Enterprise Plus, because that decision has a recurring cost that you, not the developer, will carry every month.
How an AppSheet developer designs the data model before any screens
A careful AppSheet developer spends the first days on tables, not screens. The data model decides whether the app stays fast, whether reports make sense, and whether you can move to a custom build later without a painful clean-up.
We start by listing the nouns in your business: customer, visit, product, bin, employee, shift. Each becomes its own sheet with one header row, one unique key column and no merged cells. Relationships are made with Ref columns, so a visit points to a customer by key rather than by retyped name. Calculated values that change often live as virtual columns or in the app, not as long sheet formulas that slow every sync.
Then we decide what each role really needs on the phone. A rep in Jalgaon does not need five years of visits for the whole state; a security filter can limit their download to their own customers and the last ninety days. That single decision often matters more for speed than anything else in the build, because AppSheet sends filtered rows to the device.
- One entity per sheet, one header row, no merged cells
- A stable unique key in every table
- Ref columns instead of copied names
- Security filters that cut rows per user
- An archive sheet for closed or old records
Does AppSheet work offline for field teams?
Yes, with conditions. AppSheet's "Offline and Sync" help article explains that the app definition and data are stored on the phone, so staff can keep entering data without a network, but the app must first be launched once while online on that device.
The details decide whether offline actually works in a village with one bar of signal. Photos and documents are not cached for offline viewing by default; you turn on "Store content for offline use", which adds to storage and sync time. Delayed sync lets changes queue on the phone and go up later, which suits reps who work all day in poor coverage. When a sync is interrupted, AppSheet queues the changes and sends them once the connection returns, according to the same help article.
Our testing routine is dull but it works. We put a phone in airplane mode, add ten records with photos, kill the app, reopen it, then reconnect and check every row in the sheet. We repeat it on an inexpensive Android phone, because that is what many field staff carry, and we document exactly what a rep should do before heading out: open the app on Wi-Fi, wait for the sync to finish, then go.
Barcode, photo, signature and GPS capture in AppSheet
AppSheet can capture barcodes, photos, signatures and location from the phone, which is why it suits field and warehouse work. Each one has a documented limit that an AppSheet developer should plan around.
Barcodes and QR codes. AppSheet's barcode help page lists support for common formats including QR Code, EAN-13, EAN-8, UPC-A, Code 128 and Code 39, and says scanning works only when the app runs on a mobile device, not in a browser. So your office team cannot scan from a laptop webcam; plan a manual entry fallback. Location. The "Capture GPS location" help page notes that a LatLong column can record the device position offline, but the map view will not display while the app is offline. Photos and signatures. These save as files in Google Drive with a link in the row, which keeps the sheet small but means Drive folder permissions matter.
We also add small touches that reduce bad data: a scan that looks up the product and shows its name before the user confirms quantity, a photo field that is required only when condition equals "damaged", and a location stamp captured automatically rather than typed. These are the details that separate a demo from an app a supervisor can rely on.
Can AppSheet run an attendance app for site and field staff?
Yes, AppSheet handles check-in and check-out with time, photo and GPS stamp well for small and mid-sized teams. Payroll calculation, statutory reports and biometric hardware are better handled elsewhere, with AppSheet feeding clean data in.
A typical build has an employees table, a shifts table, an attendance log, and a leave request flow with manager approval. On check-in the app records the time from the device, the location, and optionally a selfie. A bot can email each supervisor a morning list of who has not checked in. At month end a slice or an Apps Script export produces a summary your accountant or HR tool can import.
Be realistic about what a phone app proves. Location and photo stamps discourage casual proxy attendance, but a determined person can still spoof a phone's location, and AppSheet is not a face-recognition system. If attendance drives wages for hundreds of contract workers, look at our attendance management software page, where we discuss device-based and custom options. For twenty engineers checking in at customer sites, AppSheet is usually the quicker, cheaper and entirely sensible choice.
AppSheet inventory apps: where a spreadsheet stock register strains
An AppSheet inventory app works well for one or two stores, a few thousand SKUs and simple in/out movements. It strains when you need batch-wise costing, many warehouses, or stock that must match accounting to the rupee.
The pattern we use keeps a products table, a locations table and a movements table where every scan adds a row: item, location, quantity, direction, user, time. Current stock is calculated from movements rather than typed into a cell, so you always have an audit trail. For speed, closed months move to an archive sheet and a monthly closing row carries balances forward.
Where it gets hard is valuation and accounting. If you already run Zoho Books, Tally or an ERP, the stock value of record should live there, and the AppSheet app becomes the fast front-end for counting, picking and dispatch. If you are choosing an ERP anyway, our Odoo vs ERPNext comparison explains how each handles multi-warehouse stock. An honest AppSheet developer will not try to rebuild an ERP inside a spreadsheet; they will make the counting part painless and hand clean numbers to the system that owns them.
AppSheet developer checklist for security, roles and data access
Security in AppSheet rests on three things: who can sign in, which rows each person downloads, and what each person can edit. A tidy app with no security filters is a leak waiting to happen, especially with customer phone numbers and addresses inside.
We require sign-in for every business app and restrict it to your Workspace domain or a named user list. Security filters limit rows per user, so a rep in one district never downloads another district's customers. Edit rights are set per table and, where needed, per column: a rep can add a visit but not change the customer's credit limit. The underlying Sheets and Drive folders are shared only with the accounts that need them, because anyone with direct access to the sheet can bypass the app entirely.
Under India's Digital Personal Data Protection Act, 2023, you are responsible for the personal data you collect, so we keep fields to what the job needs and avoid collecting ID numbers or sensitive details unless you have a clear reason. Final legal sign-off belongs with your own adviser; our job is to build the app so good practice is easy.
- Sign-in required; domain or allow-list only
- Security filters on every table with personal data
- Column-level edit rules for prices and limits
- Sheet and Drive sharing restricted to owners
- A named admin on your side with full access
AppSheet automation: bots, PDF reports and WhatsApp alerts
AppSheet automation uses bots that react to a data change or a schedule and then send an email, create a file, call a webhook or run an Apps Script function. Used well, bots remove the daily "please send me the report" messages.
Common bots we build: a daily PDF of deliveries emailed to the owner at 7 pm; an alert to the store manager when a product falls below its reorder level; a visit report with photos generated the moment a service engineer marks a job complete; a weekly summary of pending approvals. Each bot is tested with edge cases, such as a record edited twice in a minute, because duplicate emails erode trust fast.
WhatsApp is the most requested add-on in India, and it needs care. AppSheet does not send WhatsApp business messages by itself; a bot calls Apps Script or a webhook that talks to the WhatsApp Business Platform through an approved provider, using templates that Meta has approved. Our Google Sheets to WhatsApp page covers that route, and business process automation explains when a separate workflow tool is cleaner than stacking bots inside one app.
How do you hire and vet an AppSheet developer?
Hire an AppSheet developer who asks about your data and users before talking about screens, who can show a live app rather than screenshots, and who is willing to tell you where AppSheet is the wrong tool. Those three signals filter out most bad fits.
On the first call, describe one real workflow end to end, for example "rep visits shop, takes order, shop pays later". Listen for questions about keys, roles, offline use, how many rows you expect in a year, and who approves what. Ask how they would handle a customer with two branches, or a product that changes price mid-month. Vague answers there predict a messy app.
Then check the practical side. Will the app be built in your Workspace account, or theirs? Who holds the licences? Will you receive a written handover describing tables, slices, bots and security filters? What happens after launch if a bot misfires? On marketplaces such as Upwork and Fiverr you will find many no-code profiles; the ones worth shortlisting answer these points clearly in writing. If you also need a developer who can write code when AppSheet stops fitting, look for someone who works in both, which saves a hand-off later.
- Asks about data volume, roles and offline needs first
- Shows a working app you can tap through
- Builds in your account, not a personal one
- Gives a written handover and a support plan
- Can explain when custom code would be better
AppSheet vs Apps Script, Zoho Creator and FlutterFlow: which fits?
Choose AppSheet when your data lives in Google Sheets and your users are staff on Google accounts. Choose Apps Script when you need logic or integrations without a new app. Look at Zoho Creator if you already run Zoho, and FlutterFlow or full code when the app is for customers.
Apps Script is not a competitor so much as a partner: it runs behind Sheets, handles scheduled jobs, API calls and complex calculations, and AppSheet bots can call it. Our Google Apps Script developer page explains that side. Zoho Creator fills a similar low-code role inside the Zoho suite and connects naturally to Zoho CRM and Books, so it often wins for businesses already on Zoho. FlutterFlow produces a real Flutter app you can publish on Google Play and the App Store, which suits customer-facing products but needs more developer time than AppSheet.
The decision rule we give is simple. Staff app plus Google Workspace: AppSheet. Staff app plus Zoho: Zoho Creator. Customer app, payments or store listing: FlutterFlow or a coded Flutter app. Heavy back-office logic without new screens: Apps Script or a proper backend. Mixing two of these is common and fine, as long as one system owns each piece of data.
Moving from AppSheet to a custom app without losing data
A clean AppSheet build makes migration straightforward, because the sheets already look like database tables. A messy one makes it expensive, which is the strongest argument for getting the data model right on the first build.
Our migration path has four steps. We freeze the schema and export every table with its keys intact. We design the database for the custom app, usually PostgreSQL, keeping the same keys so old photo links and references still resolve. We rebuild screens in Flutter for phones or as web software for the office, keeping familiar layouts so retraining is minimal. Finally we run both systems in parallel for a short window, compare counts every evening, and switch off AppSheet only when the numbers match.
Photos stored in Drive can stay there, move to cloud storage, or both. Bots become scheduled jobs or queue workers in the new backend. The off-the-shelf vs custom software page helps if you are also weighing a ready-made product. Custom mobile apps start at ₹40,000 and web software at ₹60,000; the quote itemises migration separately so you can see what the data move costs on its own.
AppSheet developer support across India
We build AppSheet apps for teams anywhere in India, remotely, over WhatsApp and video calls. Field and stock apps suit every region, from textile units to distributors, service contractors and schools.
Some patterns repeat by city. Pump and motor makers in Coimbatore often want service-engineer visit logs with photos of the installed unit. Textile workshops in Solapur ask for piece-count entry that a supervisor can approve at shift end. Dairy collection centres around Anand want morning and evening entries that work on patchy networks. Hotel groups in Udaipur ask for housekeeping checklists with room photos. Construction contractors in Bhubaneswar and Ranchi need site attendance and material receipts. Distributors in Bhopal and Chandigarh want order booking by route, and jewellers in Thrissur ask for stock counts by tray.
Because nothing needs a site visit, a remote AppSheet developer serves a Tier-3 town as well as a metro. What matters is that your team can test the app on their own phones during the build, and that we can see the sheet as it fills. We work in English and Hindi, and accept UPI or bank transfer once you approve the quote in writing.
Worked example: a hypothetical 25-person service team on AppSheet
This scenario is illustrative, not a client story. Say a water-purifier service business in Nagpur has 25 technicians, around 3,000 customers and a WhatsApp group where jobs are assigned by voice note. The owner wants to know which jobs are done, which parts were used and who is late.
An AppSheet developer would propose six tables: customers, technicians, jobs, parts, part usage and payments collected. The dispatcher assigns jobs from a desktop browser; each technician sees only their own jobs for today and tomorrow through a security filter. On site, the technician captures a photo of the installed unit, scans the part barcode, records the customer's signature and marks the job complete. The GPS stamp is captured automatically. A bot emails the owner a PDF summary at 8 pm and alerts the dispatcher when a job stays open past its slot.
Data volume check: roughly 50 jobs a day adds about 15,000 job rows a year, comfortably within the limits Google documents, especially with last year's jobs moved to an archive sheet. Licences would come from the owner's existing Workspace plan if it includes AppSheet Core. Scope like this would sit near our starting price of ₹40,000, and the build would take roughly three weeks. If the owner later wanted customers to book service themselves, that part would become a small custom app or a WhatsApp Business API flow.
Checklist before you hire an AppSheet developer
Prepare five things before the first call and your AppSheet developer can quote accurately within two working days. Skip them and quotes stay vague, which usually means surprises later.
Bring the current sheet or paper form, even if it is messy; a real example beats a description. List every role that will use the app and what each one should see. Estimate records per day or month so the data volume can be checked against the documented limits. Note which phones your staff carry and where signal is poor. Confirm your Google Workspace edition from the Admin console, so licensing is settled early rather than after the build.
Finally, decide who on your side owns the app. That person gets admin access, joins the handover session and becomes the first point of contact for staff questions. Apps without an internal owner drift; apps with one improve every month, because small requests get made and fixed instead of being worked around in WhatsApp.
- A sample of the current sheet or form
- Roles and what each should see or edit
- Expected records per day, month and year
- Phone models and coverage conditions
- Your Workspace edition and admin contact
- One internal owner for the app