Yesterday a quiet little build showed up in r/PromptEngineering, and the interesting part isn’t the app itself. It’s the layer underneath that you never see from the login screen. Pratik Vanol, a full-stack engineer and solution architect with over 16 years in software, kept running into the same annoyance every time he opened GPT, Claude, or Gemini: why does the AI provider need to know who he is just to answer a question? Not his billing info, not his usage patterns, not a running history tied to his real identity. Just the question and the answer.
So he built PotatoAIHub to fix that.
What’s new
The idea is almost embarrassingly simple once you see it. Instead of you talking to GPT, Claude, or Gemini directly, you talk to PotatoAIHub, and PotatoAIHub talks to them. Your identity stays put. The provider on the other end gets your message and enough context to answer it, nothing about who sent it. One account, multiple models, and your name never leaves the building.
Think about what that actually changes day to day. Right now, every prompt you send to a major AI provider gets tied to an account, a login history, and often a payment method, all sitting on servers you don’t control. Switch providers and you’re creating a new identity trail with a new company. PotatoAIHub collapses that into one relationship: you trust one middleman instead of trusting every model vendor you happen to use that week.
The author is building the whole stack solo: backend, web, and Android, using Laravel, PostgreSQL, Redis, React, and React Native. That’s a full-stack proxy layer, not a wrapper someone threw together over a weekend. Laravel and PostgreSQL handle the account and routing logic, Redis is doing the heavy lifting on session and rate-limit management, and the React and React Native clients mean this isn’t a browser-only experiment either. Somebody building a mobile app for a privacy proxy is planning for daily use, not a demo.
The twist
Here’s the part that made me sit up. The creator says he cannot decrypt or read your conversations himself, even with full server and database access. That’s not a privacy policy promise, it’s an architecture claim. If it holds up, the person running the company has less access to your chats than the AI provider you’re trying to hide from.
That’s a much bigger claim than “we don’t sell your data,” which is what most privacy policies actually say when you read the fine print. This is closer to “we structurally cannot read it even if we wanted to, even under a court order, even with an angry employee poking around the database.” Claims like that live or die on the encryption design, not the marketing copy, which is exactly why the next move matters so much.
And instead of just marketing that claim, the original poster did something smarter: he posted it to a room full of people who build AI systems for a living and asked them to try to break it. That’s the opposite of the usual playbook, where founders bury architecture claims in a trust badge on the homepage and hope nobody checks. Inviting an audience of engineers to attack your privacy model in public is either supreme confidence or a smart way to find the holes before real users depend on it. Possibly both.
Try this workflow
Here’s roughly how the flow works, based on what the author laid out:
- 🥔 You log into PotatoAIHub. One identity, one place, it stays there.
- 🔁 Your prompt routes to whichever model you picked, GPT, Claude, or Gemini, stripped down to just the message and context it needs.
- 🔒 The provider answers the question. It never sees your name, your email, or your account.
- The conversation gets encrypted in a way that’s supposed to lock the author himself out of reading it back later.
That last step is the whole pitch. If a database gets subpoenaed, breached, or just browsed by a curious employee, there’s supposedly nothing readable to find. No account-linked history for a breach to expose, no plaintext logs sitting on a server waiting for the wrong person to open them.
Pro tips
If you’re the type who wants to poke holes in a privacy claim like this before trusting it, start where the money moves. Payment processors still know your name and card, so identity separation is only as strong as the billing layer sitting behind it. Ask specifically how billing records connect to conversation records internally, and whether that link could be reconstructed by anyone with database access.
Second thing worth checking: metadata. Timestamps, message length, response patterns, and call frequency can rebuild a fingerprint even when nobody attached a name to it. That’s usually where “anonymous” systems actually leak. If you send prompts at the same time every day, in a recognizable writing style, on a recognizable schedule, you’re leaving a trail even if your name is stripped off the top.
Third, check what happens at the network layer, not just the database layer. Encryption at rest means nothing if requests are logged unencrypted somewhere between your device and the model provider. Ask where those logs live and who can see them.
The author asked the community directly: what would you look at first if you were trying to break this privacy model? That’s a rare move for someone shipping a product, and it’s the kind of question worth chewing on if you care about where your prompts actually go.
Go read the original thread, poke at the site, and see if you can find the crack the author’s daring people to find. 👀💬
I built PotatoAIHub because I didn’t like giving every AI provider my identity
by u/Special_Oil_8333 in PromptEngineering