Why I refused to build a database for TimeSync

Here’s why I refused to build a database for my free-to-use utility app, TimeSync:

In 2025, the default move is: “Sign up with Google.”

Then we store emails we don’t need, collect data we’ll never use, and inflate risk: GDPR, CCPA, breaches, liability.

For TimeSync, I did the opposite.
I went stateless.

• The URL is the database: It stores and encodes team setup + timezones + availability into the link.

• Local persistence: Saved teams live in your browser, not my server. I don’t need to know if you’re inviting Peter at 6:00PM to a meeting, or if he’s supposed to sign-off work. That’s your problem.

• Zero backend: No database bills, no scaling worries, no user data to leak.

The deeper reason was even simpler: I did not need the data.

I was not productizing meeting availability. I was not building analytics around who schedules what. I was not trying to turn a tiny utility into a platform. The goal was to help someone answer a narrow question quickly: when can this group meet across time zones?

Adding a database would have changed the nature of the product. Suddenly I would need accounts, deletion flows, privacy language, storage decisions, abuse handling, and a reason to justify collecting information I did not actually need. That would have distracted from the thing that made the tool useful in the first place.

This is where constraints improve the build. Statelessness forced the product to stay honest.

For me: It’s cheaper + simpler + less liability.
For users: Zero friction. You click a link and it works.

This is the advice I give startups constantly:
Sometimes the best database is no database, especially if your use-case doesn’t actually need one.

Try it out!