Why I build many apps without accounts, tracking or my own cloud

When a new app is created, one question often appears very early.

Which backend should we use?

For many products, that is a perfectly reasonable question.

But not for every app.

For several of my projects, I therefore begin with a different question.

Does this function actually need a server?

Not every app needs a user account

An account can be technically useful.

It enables synchronization, server based storage and access across multiple devices.

At the same time, it creates additional complexity.

Credentials, account recovery, data deletion and server infrastructure all need to be managed.

If an application can perform its main task completely on a device, an account is therefore not automatically an advantage.

Local first does not simply mean offline

For me, local first is primarily a product decision.

The most important data and functions should remain as close to the user as reasonably possible.

That may mean information is stored directly on the iPhone. It may mean an analysis happens on the device. It may also mean that a function remains useful without relying on a developer operated cloud service.

Every app still needs to be considered individually.

Not every Tommsel project is local first. Some web applications deliberately need server components.

The architecture should fit the task.

Less infrastructure can support greater privacy

Every additional server and external service expands the technical surface of a product.

That does not mean cloud systems are inherently unsafe.

It simply means that information which is never transmitted to a developer operated server cannot be stored, managed or accidentally exposed there.

Data minimization can therefore begin before a privacy policy is written.

It can begin as an architectural decision.

SweatKey

SweatKey explores movement and more intentional screen time.

Personal progress is the focus. A public profile or global leaderboard is not necessary for that idea.

IntakeCue

IntakeCue organizes personal reminders for medications, supplements and routines.

For information this personal, a restrained data architecture can be especially valuable.

Kindlume

Kindlume focuses on personal relationships and staying in touch.

Private notes about important people do not automatically need to become part of a social network.

Local first still needs honest limits

The term should not become a marketing promise.

An operating system may provide device backups. Purchases may be handled through the App Store. Users may intentionally export or share information.

That is why I avoid statements such as:

Data can never leave the device.

A better question is:

Which information does the app itself process, why does it process it and which services are actually involved?

One architecture does not fit every product

Tommsel includes more than local apps.

Some web products need servers, APIs or databases because their function would otherwise not be possible.

The same principle still applies.

Use only the infrastructure that the product actually needs.

Software should be able to explain its architecture

Users do not need to understand every technical term.

But a product should be able to explain clearly what happens to their information.

For me, that has become as much a part of product design as navigation, typography or performance.

Local first is therefore not one isolated feature.

It is one way to build software with fewer unnecessary dependencies from the beginning.