Two languages is not a translation problem
We built a bilingual product for a regulated exam and assumed the second language was an interface concern. It was the product, and the mistake cost a rebuild.
Algodyne
The first owned product was a study platform for a professional licensing exam in a market where the exam is set in one language and a meaningful share of the candidates think in another. Bilingual, on the feature list, sitting between search and progress tracking.
Treating it as a feature is the error, and it is an easy one because every framework encourages it. You install the internationalisation library, extract your strings, and the tooling tells you the job is now data entry. The tooling is describing a different problem from the one you have.
What the second language actually is
Interface strings are the trivial part and they are perhaps two percent of the words. The rest is the domain content: explanations of statutory concepts, worked calculations, the reasoning behind a correct answer on a question that is itself a legal artifact.
Those cannot be translated in the ordinary sense, because a term of art in a regulatory system does not have a counterpart in another legal tradition — it has an approximation with different edges. Render it loosely and you have not produced a second language version of the explanation. You have produced a subtly wrong explanation, in a product whose entire purpose is being right about the exam.
So the artifact is not one body of content with a translation layer. It is two bodies of content that have to agree, and agreement has to be maintained as either side changes. That is a data-modelling problem and an editorial problem long before it is a rendering problem.
Why this is worth doing anyway
The cost is the reason it is defensible. Anyone can build the platform: courses, progress, a question bank, an analytics page. The tooling for that is commoditised and the build is measured in weeks.
What is not commoditised is a coherent bilingual treatment of a specific regulatory syllabus, produced to a standard where a candidate can rely on it. That takes domain access, sustained editorial work, and a willingness to do something boring for a long time. A competitor with more engineers does not catch up faster, because engineering was never the constraint.
This was the first time the shape of a moat was obvious to us from the inside rather than as a concept from a book. It is not the technology. It is the part of the work that does not compress.
The general lesson, learned late
Whenever a requirement gets classified as a feature and the classification feels obvious, it is worth asking what happens if it is actually the product. The answer changes the architecture, and it changes it in ways that are cheap at the start and expensive to retrofit once the content model is set.
The version of this we now apply during selection: ask which part of the candidate venture cannot be compressed by better tooling, and check whether that part is the thing we would be building. If the incompressible part belongs to someone else, we are building the commodity half.