DEV Community

Cover image for Why we build apps that don’t ask for your email
KAT | Co-founder, 123sudo
KAT | Co-founder, 123sudo

Posted on

Why we build apps that don’t ask for your email

Why we build apps that don’t ask for your email

The product decision behind UID-based licences, on-device file processing, and one honest exception: cloud AI.

A file converter asks you to create an account.

You only want to change a file’s format. But before you can do that, you’re asked for an email, a password, and permission to upload the file somewhere.

I’ve often wondered: does this task really need to know who I am?

I’m Kanchan(, co-founder of 123sudo. We’re a small team building practical apps for AI, media, and files. One decision we’ve made across parts of our portfolio is to use a UID for app licensing instead of requiring an email-and-password account.

That doesn’t make every app anonymous, or mean every feature works offline. It does make us ask a useful question:

What information does this feature actually need to do its job?

A simple task can involve more data than you expect

Imagine a student trying to convert a lecture recording before a deadline.

They find a website, upload the file, and create an account because that’s the path the site gives them. The task is simple. The data journey may not be.

Or imagine a small shop owner trying to save a product video. A misleading download button opens more tabs, and the real task gets lost in ads and redirects.

These are illustrative scenarios, not customer testimonials. They reflect the kind of friction we want our tools to avoid: making a simple job feel complicated, or asking for more than the job seems to require.

Start with the task, then ask what data it needs

A useful design question for any app is:

What does this feature need to know, and what can it do without?

A local file conversion, for example, can process a file on the user’s computer. 9xconvert’s desktop app is designed to convert files locally on supported desktop platforms. That’s different from uploading a file to a conversion server.

But it’s important not to stretch that into a claim about every feature in every app. Some tasks need an internet connection. Some services involve third-party providers. Each product and workflow has to be described accurately.

For 9xchat, if you choose a cloud model, your prompt and any attachments you include are sent to that model provider for processing. If you choose a model that runs locally, that processing happens on your device. The two paths are different, and users deserve to understand the difference.

Why use a UID instead of email and password?

For licensing in supported apps, we use a UID, a unique identifier. It can identify you in supported 123sudo apps, but it does not mean the apps or payments are anonymous. App licences are separate, and payment processing still has its own requirements.

The reason for this design is practical: using a utility app shouldn’t automatically require creating another email-and-password account.

That’s one choice we’ve made to reduce friction. It isn’t a blanket privacy guarantee. A UID is still an identifier, and the details of how it’s used matter.

Privacy is a set of product decisions

“Privacy-first” is easy to put on a landing page. It’s more useful to explain what happens in a real workflow.

For each feature, we should be able to answer:

  • Does the task run on the device or use a server?
  • What information leaves the device?
  • Which service receives it?
  • What does the app store locally?
  • Does the task need an account or identifier?
  • Where can a user read the relevant policy?

If we can’t answer those questions clearly, we shouldn’t hide behind a broad slogan.

That standard applies to our own apps too.

Offline support is about access, not nostalgia

Our team comes from Uttarakhand, where reliable internet isn’t something everyone can take for granted in every place or moment.

An app that can do some work on the device can be more useful when the connection is weak or unavailable. It can also reduce how much needs to travel over the network.

But “offline” shouldn’t be used loosely. Downloading something from the web requires a connection. A cloud AI model requires a connection. The right claim depends on the specific feature.

I’d rather say exactly what works offline than make a sweeping promise.

A small Diwali note

We’re currently running a Diwali bundle offer on 123sudo. The bundles include Lifetime Pro licences for the listed apps, with one UID per app. The page shows the current prices, bundle contents, payment options, and offer terms.

https://123sudo.com/bundle

A lifetime app licence is not the same as unlimited cloud AI usage. Please check the current bundle details before purchasing.

See the Diwali bundles at 123sudo

The question I keep coming back to

When we build a feature, I want us to ask two things:

  1. What is the simplest way to help someone finish this task?
  2. What data does that solution genuinely require?

We won’t always have the same answer. A local converter and a cloud AI model have different needs. The important thing is to be specific and transparent about those differences.

That’s the kind of software I want our small team to keep building: useful tools that respect people’s time, explain their trade-offs, and don’t ask for more than the task needs.

When an app asks you to create an account or upload a file, what do you wish it would explain first?


Disclosure: I’m a co-founder of 123sudo, the team behind these products. This article describes our design approach, not an independent review. AI helped me organise and edit my notes; the experiences and views are mine.

Top comments (0)