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.
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.
| 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 |
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.
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.
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.
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.
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