DEV Community: Tejaswi Dhulipala

Local-First Software: Your Device Is the Server, Not a Viewport

Tejaswi Dhulipala — Fri, 04 Sep 2026 16:32:45 +0000

Cloud-first design assumes your phone or computer is a dumb terminal. It's a viewport into an application that lives on a company's server. Your data, your logic, your entire experience is piped through their infrastructure. The app icon on your home screen is just a doorway.

Local-first flips that model. The primary copy of your data, and the software that processes it, lives on the device in your hand. Your phone isn't a terminal; it's the mainframe. This isn't just a technical detail — it changes everything about privacy, cost, longevity, and capability.

When we built Zeroed, we tested it against subscription-based budgeting tools. The most glaring difference wasn't the price tag; it was the latency. Opening a cloud app meant waiting for a server handshake, even to see your own budget from yesterday. A local-first app loads your financial history instantly because it's not asking for permission from a data center in Oregon.

The practical test: does it work on a plane?

This is the simplest litmus test for local-first software. Can you open the app at 30,000 feet, in airplane mode, and do meaningful work?

For a budgeting app, that means reviewing your remaining grocery budget, logging a coffee you just bought at the airport, scanning a receipt with your phone's camera, adjusting next month's plan.

If the app stutters, demands a "reconnection," or shows blank screens, it's cloud-first. Its value proposition depends on a persistent, silent conversation with a server you don't control. A local-first app treats the internet as a useful optional feature — like a backup tool — not as its life support system.

The most common request we get is automatic bank syncing via services like Plaid. We say no every time. It's not a technical limitation; it's a philosophical line. Once you tether your app to a third-party API that requires cloud authentication, you've moved the locus of control. You're no longer local-first. You've built a cloud conduit into the heart of the app.

The ownership spectrum: tenant vs. owner

	Cloud-first (you are a tenant)	Local-first (you are the owner)
Data location	Company servers. You access it.	Your device. You possess it.
Primary access	Requires your password and their server's health.	Requires your device (or your own encrypted backup).
Cost model	Subscription (rent). Stops working if you stop paying.	One-time purchase (asset). Works forever after one payment.
Offline capability	Limited or none. Core features often disabled.	Full. The app is designed to operate independently.
Long-term risk	Company can change terms, raise prices, or shut down.	You retain a working copy. The company can vanish; your tool remains.

Being a tenant is convenient until the landlord changes the locks. For personal, critical data — your finances, your journals, your creative work — you shouldn't be a tenant. The five-year cost difference isn't a small discount either: it's paying $500+ to rent access to your own financial data versus one payment to own the tool outright.

A worked example

Follow a transaction through both architectures. You buy a book for $24.99.

Cloud-first: You open the app. It checks for an internet connection. It authenticates your session with a server. You enter the transaction. The data is sent to the cloud, processed, and the updated "Books" envelope balance is sent back to your phone. If the server is slow or down, you wait, or the entry fails.

Local-first: You open the app. It instantly shows your current envelope balances. You enter $24.99 as "Books." The balance updates immediately, calculated on your device's processor. The transaction is saved to your phone's encrypted storage. Later, if you choose, the app silently backs up the encrypted data file to a folder in your personal Google Drive.

The second flow isn't just faster; it's more resilient. The speed and reliability aren't optimizations; they are direct consequences of the architecture.

Why this movement is growing now

For decades, the default answer to any software problem was "add a server." It centralized control, made updates easier, and created lucrative subscription pipelines. But the downsides are now in plain sight: data breaches, vendor lock-in, feature bloat, and the quiet creep of surveillance for "product insights."

The local-first movement is a correction. It asks a simple question: does this task need a server? For an alarming number of personal productivity apps — budgeting, note-taking, photo editing, document writing — the answer is no. Your smartphone has more processing power than the computers that sent men to the moon. It doesn't need to beg a remote server to add two numbers.

This isn't about rejecting the cloud entirely. It's about demoting it from master to servant. In our case, the user's Google Drive acts as a dumb, encrypted filing cabinet they control — not as the brain of the operation. They hold the encryption keys. We just provide the wallet.

The trade-offs (because nothing is free)

Local-first isn't a magic bullet:

No real-time collaboration. You can't have a Google Docs-style live-editing session. Sync becomes a deliberate merge, not a continuous stream.
Developer responsibility. If the app's local encryption is flawed, the user's data is directly exposed. There's no server as a buffer.
Setup friction. Bring-your-own-Drive sync takes a one-time setup that "Sign in with Google" cloud apps don't.

These aren't weaknesses to hide; they're design constraints that flow from the core principle: user sovereignty over convenience.

Curious what this community thinks: which apps in your daily stack would actually get worse as local-first — and which are cloud-first purely because of the business model?

Originally published on our blog. Zeroed is a pay-once, offline envelope-budgeting app for Windows, Android and macOS (34-day free trial, no card).

Why We Don't Do Subscriptions (For Software That Runs On Your Device)

Tejaswi Dhulipala — Wed, 02 Sep 2026 05:24:20 +0000

The average person now pays for dozens of software subscriptions. Streaming, storage, productivity, notes, passwords, VPNs, budgeting. Each one is "just $5/month" — until you add them up.

Some of those are honest. Streaming pays for licenses and bandwidth. Cloud storage pays for disks someone has to keep spinning. Real ongoing cost, real ongoing service.

But for a budgeting app — software that lives on your device, stores data on your device, and depends on no remote infrastructure to function — charging you forever is a different beast entirely. You're not paying for ongoing work. You're paying so they don't take it away.

For a personal finance tool whose entire purpose is to help you spend less money, that contradiction is hard to ignore. So when we built Zeroed, we wrote a different rule: we don't charge subscriptions for software that runs on your device.

The test

The line is simple. If you stop paying, what actually stops working?

If the answer is "a tool sitting on my hard drive" — that's rent extraction. That's the model we refuse.

If the answer is "the servers, the phone numbers, the AI models, and the people running them on my behalf" — that's a service. Services have real ongoing cost, and pretending otherwise is dishonest pricing.

That's why our rule as a two-person-sized indie studio is simple:

Our apps are pay-once. They run on your device. They don't need us to keep working. No recurring fees, ever.
If we ever ship something with real ongoing cost — servers, AI inference, infrastructure we run for you — it will be an optional, monthly, cancel-anytime service with full data export. And the app you bought will always work fully without it.

We charge for what we actually do — never for software sitting on your hard drive.

What you're really paying for (when it's wrong)

When a personal-software company charges you monthly for an app that runs on your hardware, here's what your money is buying:

Server infrastructure to hold your data hostage
Growth metrics to satisfy investors
Retention tactics to make it painful to leave

Your monthly payment isn't buying features. It's buying the company permission to keep your data on their servers — data they could monetize, lose in a breach, or hold hostage if you try to cancel.

The math

A typical subscription budgeting app at $99/year versus a one-time license:

Time period	Subscription	Pay once
Year 1	$99	$19.99, once
Year 3	$297	$19.99
Year 5	$495	$19.99
Year 10	$990	$19.99

The subscription costs nearly $1,000 over a decade.

I'd genuinely like to hear where other devs draw this line — especially if you ship desktop/mobile software with a subscription and think I'm wrong. What's the honest defence of recurring pricing for local software?

Originally published on our blog. Zeroed is a pay-once, offline envelope-budgeting app for Windows and Android (34-day free trial, no card).

How We Do Bank-Grade Encryption and Cross-Device Sync Without Running a Server

Tejaswi Dhulipala — Sat, 29 Aug 2026 10:16:32 +0000

Most budgeting apps store your financial data on their servers. This means:

They can see your transactions, balances, and spending habits
A server breach exposes your financial life
If the company shuts down, your data may be lost
They can — and often do — monetize aggregate financial data

We built Zeroed to make all of these impossible. Here's the architecture.

Local-first architecture

Zeroed stores your entire financial database locally on your device in an encrypted SQLite database. The encryption key is derived from your device and never transmitted anywhere.

This means:

We cannot read your data — we don't have the key
We cannot lose your data — we don't have a copy
We cannot sell your data — we literally don't have access to it

Cross-device sync via Google Drive

The obvious question: if there's no server, how do you sync between your phone and laptop?

The answer: your own Google Drive.

When you enable sync, Zeroed creates a folder called ZeroedData in your personal Google Drive using the drive.file scope. This scope means Zeroed can only access files it created — it cannot see your photos, documents, or anything else.

Your encrypted database is uploaded to this folder. Any other device running Zeroed and signed into the same Google account will detect the folder, download the encrypted database, and decrypt it locally.

Licensing without license servers

Your Zeroed license also lives in Google Drive as a secure verification file. When you purchase a license, the key is placed in your ZeroedData folder. Any device that connects to that Drive sees the key and unlocks the full app automatically.

No license servers. No activation limits. No "you've used too many devices" errors.

AES-256 encryption

All data synced through Google Drive is encrypted with AES-256 — the same standard used by governments and financial institutions. The encryption happens on your device before the data leaves for Google Drive, and decryption happens on your device after download.

At no point does unencrypted financial data exist outside of your device's memory.

What this means for users

Switch phones freely — sign into Google Drive and you're synced
Use the app fully offline — sync when you reconnect
Your financial data is mathematically inaccessible to anyone but you

Happy to answer questions about the architecture in the comments — the trade-offs of serverless sync (conflict resolution, key management, the no-web-app constraint) are genuinely interesting problems.

Originally published on our blog. Zeroed is a pay-once, offline envelope-budgeting app for Windows and Android (34-day free trial, no card).