Flutter App Backend Setup: Does Your Template Need One?

You bought one of our Flutter templates, it runs on your phone, and now you're looking up Flutter app backend setup because a client asked where the data is stored, or because you assumed every app needs a server. For Stacklyn's Flutter templates there is nothing to set up. This article explains why, how to tell whether you need a backend at all, and what changes if you add one.

What the templates use instead of a server

Every Stacklyn Flutter template is offline-first. Records live in a local database on the device: Hive CE in most of them, Isar Community in Rent Folio. There is no backend, no account system and no server API key to configure. AutoLog's setup guide puts it plainly: no backend, API key or database server to set up.

Three details worth knowing:

• Zenith keeps its content in JSON files bundled in assets/data/ (atmosphere.json, moods.json, radio.json) and loads them locally. The sounds and radio streams are audio URLs you host. That's file hosting, not a backend: no database, no API.
• AdMob ships in StyleBook, CleanSync, MemberKeep, TutorTrack, SubZero and Zenith. The IDs you add there are ad unit IDs, not backend credentials.
• Vet Vault and Agri Ops don't need Android's INTERNET permission (for Agri Ops, the release build), and their guides list the App Store privacy label as "Data Not Collected".

A quick test: do you need a backend?

Answer these for the app you plan to ship:

1. Does each person use the app on one device, such as one salon tablet or one farm manager's phone?
2. Is the data seen only by the people using that device?
3. Is moving to a new phone rare enough that a backup file is acceptable?
4. Can reminders be scheduled on the device instead of sent from a server?

If all four are yes, skip the backend. The templates already cover the last two. Rent Folio, Vet Vault, CleanSync, TutorTrack, Agri Ops and AutoLog have backup and restore in Settings; AutoLog's backups work across Android and iOS. AutoLog and Agri Ops schedule reminders as local notifications, with no server involved.

When you do need one, and what it costs you

A backend earns its keep when the app needs one of these:

• Cross-device sync: the same records on a phone and a tablet, kept current without manual backups.
• User accounts: sign-in, password reset, data tied to a person instead of a device.
• Push notifications triggered by something that happened elsewhere, like a booking made by another user.
• Shared data between users: a front desk and a vet, a landlord and a property manager.
• A web admin panel for viewing or editing data from a browser.

Each one brings costs the offline version doesn't have.

Running cost and upkeep. Someone pays for hosting every month and handles outages, security updates and backups of the server itself. We can't give you a figure; it depends on the provider, your user count and your data volume.

Store privacy declarations change. Google Play defines "collect" as transmitting data off a user's device, and Apple says data processed only on device isn't collected. Once records sync to a server, update the Google Play Data safety form, the App Store privacy label and your privacy policy to say what you collect and why. On Android, a release build also needs the INTERNET permission in android/app/src/main/AndroidManifest.xml. Flutter's standard template doesn't include it.

Offline gets harder. With sync you have to decide what happens when two devices edit the same record while offline. That conflict handling is where most of the work goes.

Where sync code plugs into each template

You don't rewrite the screens. Each template routes its writes through one layer, and that's where a sync call belongs. From the product setup guides:

For StockPilot, SubZero and Zenith, check the project structure section of your setup guide. The guides describe adding sync as custom work outside the template's scope.

Firebase, Supabase or your own API

Firebase supports Flutter through the FlutterFire plugins and covers sign-in (Authentication), a database (Cloud Firestore) and push messages (Cloud Messaging). Supabase is built around a Postgres database with Auth, Storage and Realtime, and has a Flutter client library. Your own API gives you full control over the data and where it's hosted, and you maintain all of it. Which fits depends on your data, your team and any rules about where data must be stored. Check each provider's current pricing page yourself before you commit.

Troubleshooting

Sync works in debug but not in the release build. The release manifest is missing <uses-permission android:name="android.permission.INTERNET"/>. Add it to android/app/src/main/AndroidManifest.xml.

Screens don't refresh after a remote change arrives. The change bypassed the write layer. In Vet Vault, route it through PetProvider, not DatabaseService directly. In CleanSync, new DatabaseService methods must call notifyListeners().

A restore wipes data that was already synced. Restoring a backup replaces the data on the device (Rent Folio's guide says so explicitly). Decide whether restore should push to the server, pause sync, or be removed once sync exists.

Your store listing still says "Data Not Collected". Update the privacy label and Data safety form before submitting the version with sync.

When to ask for help

Turning a single-device app into a synced, multi-user one means new data models, a server, moving existing local data, and updated store forms. Get conflict handling wrong and customers lose records. That's custom development, not a reskin. Our Flutter app reskinning service covers branding, the package name, signing and store-ready builds; backend and sync work we scope and quote separately through a custom development brief.

If you're still deciding how the local side should store data, Hive vs Isar vs SQLite for a Flutter local database compares the options our templates are built on. Setup guides for each template are in the Stacklyn Labs Help Center.