AppSheet or a custom Android app? I have built both for the same kind of team
Every few months someone asks whether they need a real app built, or whether one of the no-code tools will do. I have shipped both for the same kind of user — crews working outdoors, on cheap Android phones, with patchy signal — so here is the honest comparison rather than the vendor version.
Which should you choose?
Start with AppSheet unless you need the phone’s hardware. If your app is forms, lists, approvals and reports over data that lives in a spreadsheet or a database, AppSheet will be running this week and anyone on your team can change it later. The moment you need the camera, the sensors, or control over what happens offline, you need a real app. That is the deciding question, and it is not about how big the company is.
The comparison
| AppSheet | Custom Android app | |
|---|---|---|
| First working version | Days | Weeks |
| Who can change it later | Anyone who can read a spreadsheet | A developer |
| Camera and sensors | Take a photo, attach it. No control beyond that | Full control — lenses, focus, GPS, compass, what gets drawn on the frame |
| Offline | Works, on the tool’s terms | Works, on your terms |
| Cost shape | Per user, every month, forever | Build once, then hosting |
| Where the data lives | Your Google account | Wherever you put it |
| What kills it | A requirement the expression language cannot express | Nobody maintaining it after launch |
When AppSheet is the right answer
The labour tracker I built for orchard crews is AppSheet, and it should be. A manager opens it once a day, taps a number for the headcount, picks the site and the block, and is finished inside a minute. Behind it sit per-site attendance, editable day rates, advances against wages, automatic photo collages of the day’s work, and a payroll roll-up that updates itself.
None of that needed a real app. All of it needed to exist quickly, run on whatever phone the manager already had, and stay changeable when the accountant asked for one more column. It runs on Google Sheets with Apps Script behind it, in the client’s own Google account, and if I disappeared tomorrow it would keep working.
That last point matters more than people expect. A no-code app your client owns outright is a better outcome than a beautiful custom app only its author understands.
When it stops being enough
Zaproll is a camera for field crews that burns GPS coordinates, satellite time, compass bearing and the operator’s name into the photograph itself, then produces a SHA-256 manifest so a photo can be proven unedited later. It also previews fourteen film looks live in the viewfinder.
None of that is possible in a no-code tool, and the reason is specific rather than snobbish. Stamping a frame at capture time means holding the camera pipeline open and drawing on it. Reading a compass bearing means the magnetometer. Previewing a colour grade live means running a shader on the preview surface. A tool that hands you “attach a photo” cannot reach any of that, and no amount of cleverness in the expression language gets you there.
So Zaproll is Kotlin, and it took weeks rather than days, and that was the correct trade.
What it actually costs
AppSheet is priced per user per month, forever. That is cheap for five people and a real line item for fifty. A custom app is paid once and then costs hosting, which is close to nothing for the kind of load a field team generates.
The crossover is real but it arrives later than most people assume, and choosing a custom build to save subscription money is usually the wrong reason. Build custom because you need something the tool cannot do. If the only argument is cost, you are buying weeks of work to avoid a bill that has not hurt yet.
The mistake I see most
Picking the platform before writing down what the app has to do. The decision looks like a technology choice and is really a requirements question: does anything here touch the camera, the sensors, or offline rules you need to control? Write the list first, and the answer usually picks itself.
The second most common mistake is building custom and then leaving nobody to maintain it. An AppSheet app that a manager edits themselves outlives a custom app whose developer moved on.
Questions
- Can AppSheet use the phone camera?
- It can take a photo and attach it to a record. It cannot control the capture — no stamping the frame at capture time, no compass bearing, no live preview effects, no control over focus or lenses. For those you need a native app.
- Is AppSheet good enough for a real business?
- Yes. It runs daily payroll and attendance for orchard crews in production. The limit is capability, not seriousness — it stops when a requirement cannot be written in its expression language.
- Does a custom app work offline better than AppSheet?
- Both work offline. The difference is control: AppSheet syncs on its own terms, and a custom app syncs on rules you write. That matters when the network is unreliable and you need specific behaviour on reconnect.
- Which is cheaper?
- AppSheet is cheaper to start and costs per user every month. A custom app costs more upfront and almost nothing to run. For a small team AppSheet usually wins on cost; cost alone is rarely a good reason to build custom.
Sheikh Muhibul Hassan is an AI systems engineer in Srinagar, Jammu and Kashmir, and the founder of Lumivon AI Studio. He builds Android applications, WhatsApp and n8n automations, custom software and multilingual voice agents. Also known as Sheikh Hassan, Sheikh Muhib and Muhibul Hassan.
More about him · LinkedIn · X · GitHub