The demo dies when you toggle airplane mode, and the tool is a personal checklist. You built it to track your packing list for work trips, half of which involve 3-hour regional train rides with zero cell service. If you can’t tick off items while you stuff your backpack in the station tunnel, the entire tool is useless for your core use case. This is the exact line where local-first design beats forcing an always-online architecture for small side tools, and the choice doesn’t have to be permanent or all-or-nothing.
Build Next Stack editors
Tools that must work on a train with no signal
The first filter for your side tool architecture is whether your core use case ever occurs when internet access is unreliable or entirely unavailable. Most personal use cases for small side tools fall into this category: habit trackers you update first thing in the morning before your home Wi-Fi kicks in, recipe managers you use at campsites with no cell service, project time trackers you use at co-working spaces with spotty internet, or study flashcards you review on long international flights. Always-online tools fail all of these use cases entirely, no matter how polished their UI is. To help you make the call for your specific tool, use this offline-ok vs sync-needed decision grid:
| Use Case | Requires Offline Access? | Sync Needed? | Ideal Architecture |
|---|---|---|---|
| Personal packing checklist for frequent work travel | Yes | Only if you want to edit on both phone and laptop | Local-first with optional sync |
| Client project tracker you only update on your dedicated work desktop | No (stable wired internet on that device 100% of use time) | No (single device, single user) | Local single file with manual backup |
| Shared family grocery list for household use | Yes (you edit it in the store parking lot with no service) | Yes (multiple household members edit) | Local-first with auto-sync when online |
| Public web calculator for converting commercial recipe units | No (users only access it while browsing online for recipe ideas) | No (no saved user data) | Static hosted always-online tool |
| Study flashcard app for med school exam prep on long flights | Yes | Only if you want to sync decks across your laptop and tablet | Local-first with optional manual export/import |
| Freelance invoice generator you use to send bills to clients | No (you only generate invoices when you have internet to send them) | Only if you want to access past invoices on multiple devices | Local-first with cloud backup option |
If your use case falls into any of the rows marked as requiring offline access, building an always-online tool first guarantees you’ll break your own core use case before you even finish building the first version. You don’t have to support every possible use case on day one, but prioritizing the use case that made you build the tool in the first place will save you from scrapping a fully polished but useless version later.
Sync you do not need until a second device appears
A common mistake for side tool builders is adding sync functionality as a day one requirement, even when they are the only user and only plan to use the tool on one device for the foreseeable future. Sync is a nice-to-have feature, not a core requirement for most solo use cases, and delaying it cuts down your initial development time drastically. Example measurement: Building a basic encrypted sync backend for a small checklist tool takes 12+ hours of development time, plus ongoing monthly server costs, vs 2 hours to build a local-only version that saves all data to your browser’s local storage. You can easily add sync 6 or 12 months down the line, when you actually find yourself wanting to edit the same checklist on your phone and your laptop, instead of wasting time building a feature you might never even use. This approach also lets you validate that the tool is actually useful for you before you invest extra time in expanding its functionality, which is a core priority for side projects that have limited development time available.
Conflict cases a solo file never hits
One of the most complex parts of building sync functionality is handling merge conflicts, which occur when the same piece of data is edited on two separate devices while both are offline. For a solo user working on a single local file, these conflicts never happen, because there is only one source of truth being edited at any time. That means you can skip building all of the complex conflict resolution logic entirely if you stick to a local-first architecture until you actually need sync. Illustrative example: A solo user editing a local habit tracker file will never encounter a conflict, so you don’t need to build logic to prioritize one edit over another, or show users a conflict resolution interface, until you add sync for multiple devices or multiple users. Many side tools never reach the point where multiple users or devices are involved, so skipping this work entirely lets you launch a usable version of your tool weeks earlier than if you tried to build all sync functionality first.
Account wall that blocks the Tuesday use case
Always-online tools almost always require user accounts to save data, because all data is stored on a remote server instead of on the user’s device. This creates an account wall that blocks casual use, even for your own personal use of the tool. If you’re trying to use your own checklist tool on a random Tuesday to track your errands for the day, you don’t want to have to log in, reset a forgotten password, or verify your email just to add a few items to a list. For public users who test your tool, this account wall can cause 80% or more of visitors to leave before ever using the core functionality, even if the tool itself is exactly what they need. Local-first tools eliminate this barrier entirely: users can start using the tool immediately, no account, no email verification, no password required, and only need to create an account if they decide they want to add sync functionality later. This makes the tool far more usable for both you as the builder testing it, and any future users you might share it with.
Local default plus a later export button
The sweet spot for almost all small side tools is a local-first default, with an export button that lets users save their data to a file whenever they want. This architecture gives users full control over their data, no lock-in, no account requirements, and no reliance on internet access to use the core functionality. Adding an export button is extremely low effort, and lets users back up their data, move it to another device, or import it into another tool without you having to build any sync or server functionality. Example measurement: Adding a CSV export button to a local checklist tool takes less than 30 minutes of development time, vs 10+ hours to build a secure user account and sync system. If you later decide you want to add sync as a premium feature for users who want it, you can do that without breaking the core local functionality for existing users who don’t need sync. This approach also eliminates ongoing server costs for the core version of the tool, which is a huge benefit for side projects that don’t generate any revenue.
Open your side tool project right now, test it in airplane mode, and use the decision grid above to mark if you can cut 10+ hours of unnecessary sync and account work from your roadmap this month.