What we believe about translation, privacy, pricing, and how a tool earns the right to be on a traveler's phone. These principles shape every TapSay product decision — and they're written down so you can hold us to them.
Principle 01
Pre-translation beats live translation for travel.
Travelers don't need infinite-vocabulary translation; they need 30 categories of phrases — reliably, instantly, repeatedly.
Pre-translated content beats real-time inference because it removes the failure modes that matter most: no signal, no battery, no patience. We don't compete with neural machine translation on its strengths. We win on the dimensions a tired traveler at 11pm actually cares about: speed, certainty, and offline reliability. The 693 phrases cover ~95% of in-trip conversations. The 5% they don't cover is what Google Translate is for. Pair the tools — don't pick one.
Principle 02
A phrasebook should behave like a phrasebook, not phrasebookware.
A printed phrasebook doesn't ask for your email or push you to upgrade. The digital one shouldn't either.
A printed phrasebook doesn't ask for your email, doesn't push you to upgrade, doesn't show you ads, doesn't track which page you turned to. The digital phrasebook should inherit those properties, not abandon them. The job of the medium is to disappear. If users notice the app, the app has failed. We optimize for invisibility.
Principle 03
Offline is not a fallback. It is the contract.
Most translators treat offline as a degraded version of online. We invert that. Offline is the default.
Online is the exception. The first launch is the only moment where we need the network. After that, the app must be indistinguishable in airplane mode from the moment you installed it. Camera OCR? Voice conversation? We don't ship them because they would re-introduce a network dependency. We'd rather do less and never break than do more and break in the field. Read more in How to Translate Without WiFi.
Principle 04
No install is a feature, not a limitation.
An app-store install is friction the user pays at the worst possible moment — after they've already failed to communicate.
A web app that opens in a browser, caches in 10 seconds, and lives on the home screen if you want it to is strictly better for the use case. Native is overkill when the only thing you do is render text and play audio. We're a Progressive Web App on purpose, not because we couldn't ship native. The receipt is in the conversion data: people who land on tapsay.me/app and use it are an order of magnitude more common than people who land on a "Download our app" page and actually install. Read the deep version in The Translator That Needs No Install.
Principle 05
Privacy is architecture, not a promise.
Promises require trust; trust requires audits nobody will run. We avoid the whole stack by not having a server to log to.
Translator privacy policies are full of promises. Promises require trust; trust requires repeated proof; proof requires audits nobody will run. We avoid the whole stack by not having a server to log to. The 693 phrases across 119 languages are pre-translated static content bundled with the app. When you tap a phrase, no API call happens. There's no log entry to leak, subpoena, breach, or sell. This is privacy as architecture, not as policy. Read the privacy positioning at The Most Private Offline Translator.
Principle 06
Price by trip, not by month.
Subscriptions assume a recurring problem. Travelers don't have one. They have a 7-day, 14-day, or 21-day problem.
A traveler has a 7-day, 14-day, or 21-day problem, then nothing for six months, then another trip. Charging $5–$10/month for software they use 4 weeks a year is a bug in the pricing model, not a feature. We charge $3.54 / $7.82 / $13.52 for trip passes that match the trip, not the calendar. After your trip ends, we leave you alone. Read the deep version in Why Translator Subscriptions Fail Travelers.
Principle 07
The founder still answers email.
TapSay is built by one person. The support email goes to the person who can fix the bug.
There is no support tier, no chatbot, no escalation queue. Email reaches support@tapsay.me and a human reads it, usually within a day. This will be true until it can't be — and we will tell you when that changes by editing this principle with a date. The size of the team is one of the trade-offs that makes the rest of the principles defensible. Read the founder's story at /story.
A note on what's not here.
You'll notice we don't claim "best translation quality" or "most languages" or "fastest growing." Those are competitor games. The principles above describe a different shape of product. If those are the wrong trade-offs for your trip, our comparison page will help you pick a better one. We don't think every traveler should use TapSay — only the ones for whom these principles match the trip.
FAQ about the principles
Why does TapSay publish a list of principles?
Because every product decision involves trade-offs, and stating the trade-offs in advance makes them inspectable. If we ever stop honoring one of these principles, you'll know exactly which line we crossed. That's the point of writing them down.
Are these principles marketing copy or actual constraints?
Both. They're marketing because we believe them and want users to choose us for them. They're constraints because we hold ourselves to them. The most common test: when a feature would make the dashboard look better but would violate one of these principles, the principle wins.
Will TapSay ever add a subscription tier?
No subscription tier is planned. Travelers have trips, not recurring rendezvous with foreign languages. Trip passes are the right shape for the demand. If we ever need recurring revenue, the answer is more trip passes from more travelers, not turning the existing ones into subscribers.
Will TapSay ever ship a native app?
Only if browser limits force it. Today the PWA does everything a native phrasebook needs: cache, render, speak, work offline, install to home screen. Going native would add app-store taxes, signup friction, and review delays without giving users anything new. If that calculus changes — say, an OS removes a critical PWA capability — we will rebuild on the new floor and keep the principles intact.
Why is privacy framed as "architecture, not a promise"?
Because promises decay and architectures don't. A privacy policy can change in 30 days; a server that doesn't exist cannot be silently turned on. By shipping pre-translated static content instead of an inference API, we made the privacy claim a structural fact rather than a contractual one. The user doesn't have to trust us — they can read the network tab and see that nothing leaves the device when they tap a phrase.
What happens to these principles when TapSay grows?
The size of the team is one of the principles, so we'll publish a revision with a date if it changes. The other six are intended to outlive any team change. Growth without abandoning the principles is the goal; abandoning the principles to chase growth is the failure mode we're explicitly trying to avoid.