There was a popular computer science meme that showed how almost every problem in computer science is the same. It depicted two entities, A and B, with a messy communication channel between them. Then, you have a translator layer between them, and it just works perfectly smoothly.

I think the same goes on between humans and softwares also. That there is some translation layer in between that can make things a lot better. What Arixcel did was Excel had its data in a very convoluted way, humans wanted it in some another way. Arxcel basically translated that data.

My checklist when I’m trying to build any software is that it should be able to wow the user with just as little button clicks as possible and as quickly as possible. Another is we are supposed to build things that help winners win and avoid novel problems so that we are not spending too much time on educating people. Also, I had another constraint that we should only build small features, stand-alone features, or features for some bigger host system like Excel or After Effects.

And now I see that all these constraints are converging onto a single answer – applications that are translators of some sort. Translators between two softwares or between softwares and humans? For example, translators between a form application and CRM, translators between Excel and a human.

Sometimes the translated good itself can be the product. For example, I love PDF when it merges two PDFs. What it is doing is essentially taking multiple inputs, translating them into a single output. This analogy is very loose, but I think it is a good mental model to imagine it.

Basically, what I am saying is under the god’s green earth we don’t see many processes that are left as a green field, but I think a lot of translation work can still be done. So, one can either do SAS that does processes for you or does translations for you. I think I don’t have any bias between the two of them, but I’ll figure it out.

Even inside one project I was building, the translator literally served me so much effort.

Basically, I had one service that created data and I had another service which visualized it. The visualizer expected something different, the data creator created something different, and I was trying to put the functionality of being able to read any data that the data creator creates into the visualizer, and that was a mess. Each case broke whatever I had coded. But then I realized that, “Okay, I can use a translator.” I built a translator service in between them, and the whole app works so seamlessly. Even internally, I have seen how well that can work. So, if there is some entity out there that is about data and entity about visualization, I can be the translator between them. That is just an example, not a literal statement abou what i am building

You know doubling down on what works is really cool. Instead of creating a new product, if you’re able to brand an existing commodity, you can do really well. That is because you can sell someone who is already sold on that thing. Like you can have cheap soap. People use it. They are already sold on the idea of soaps, so if you create a premium soap, a portion of people will be interested in it. The familiarity helps.

If there exists already a software which people are sold on, if you are somehow able to make it better, or if output already exists out there and you are able to make it better, or make the process of handling it better, you’re selling someone on what they’re already sold. So it is way easier to get that done than to create something new and sell people on them. It’s like almost like working on cold leads vs warm leads.

“better X” often beats “novel Y” even when novel Y is objectively more innovative. And translators can make x into better x.

“Novel Y” has a compound adoption problem:

1. Convince users the old way is broken
2. Convince them your new way is better
3. Convince them to bear the switching cost
4. Convince them to trust you with their critical workflow

If you translate between Excel and CRM, you’re selling to people who already use both. They’re double-sold. They feel the pain daily. You don’t need to convince them the pain exists.

Translation-focused applications can “wow the user with just as little button clicks as possible” by working with what users already understand and use

You aren’t building the source of the data, and you aren’t building the final destination. You are building the Converter that makes the two ends talk to each other or makes the machine talk to the human. You are not even guessing the market because you already know that people use these two things, or people are using that one thing, and thus translation can be of help. So product-market fit risk becomes less. You are selling the Frictionless Transition without being disruptive to their workflow at all.

When you build a standalone CRM, you have a Trust Deficit of 100%. The user has to trust your database, your security, and your longevity. When you build a Translator, you inherit the trust of both platforms. Plus each software is competent enough that it deals with all the areas it is dealing with well enough. That’s why they have customers. The inconvenience arises in the gaps between two softwares, and that’s where translators come in.

Type	Example	The “Wow” Moment
Human-to-Machine	A tool that turns a voice memo into a perfectly formatted Jira ticket.	Seeing a rambling thought become a structured task in 5 seconds.
Machine-to-Human	Arixcel. It takes “Machine-readable” formulas and makes them “Human-auditable.”	A shortcut that visually maps a complex dependency.
App-to-App	A “glue” tool that moves specialized medical data into a generic ERP.	Realizing you don’t have to manually type 50 fields anymore.
Format-to-Function	iLovePDF. It takes a “Dead” format (PDF) and makes it “Malleable” (Word/Merge).	Getting a clean, editable file from a locked one instantly.

You can make better translators also. For example, when talking with a computer, we use a keyboard, but there is a software called Flow which allows me to convert speech to text. Now, that is the translator I am using to talk with a machine. You just cannot convince me the value is not easy to sell because the computer exists, people exist, we need to talk with each other, and whatever makes this convenient is sought after.

Plus you shouldn’t be afraid that the platform themselves might create a translator.

• There are so many things that need translation
• For each feature they add, they bloat their software and kill the usability

So even if brands can, most of the times they won’t. They are ok with leaving some money on the table.And many times they even promote them in the form of plugins to show developers that “Hey, we are friendly. You can build for us and increase our usability. It’s a modular approach and a symbiotic relationship.”

These huge software platforms have the duty to be generic, to serve a broad foundation of users. If they specialize, they lose it. Basically, you are providing opinionation as a service where the output from the entity is broad, but your opinionation turns it into a very specific thing that the user needs.

But there are translators that have more risk than others of being killed because let’s say currently we have an AI boom, so companies have an incentive to build AI features. At that moment, you put yourself in the crossfire. If you’re building something boring, then you would be fine. Can’t really expect much if you’re creating a browser extension that summarizes or lets you ask questions for thing that is on screen if Microsoft owns Edge and is trying to put AI features into it.

---

From claude

When This Strategy Fails

It’s worth noting when “better X via translation” doesn’t work:

❌ When X is already “good enough” and the pain is minor
❌ When the translation requires so much context that you basically have to rebuild X
❌ When X is actively hostile to translation (locks down APIs, changes formats constantly)
❌ When the gap you’re filling is actually a feature request with a committed roadmap

But when the pain is real, persistent, and structurally unlikely to be solved by X itself? That’s the sweet spot.