Building Bilingual Crew Operations: English and Spanish in the Same App

According to the Bureau of Labor Statistics, roughly 60% of the moving and storage workforce identifies as Hispanic or Latino. In major metros — Chicago, LA, Miami, Houston — that number is considerably higher.

Yet virtually every field operations tool in the commercial moving space is English-only. Daily logs, punch list items, change order descriptions, phase names — all English, regardless of who's actually submitting the report or completing the work.

The translation tax

When Spanish-speaking crew members can't interface with the software in their language, one of three things happens:

• The data doesn't get entered. Logs are skipped, photos aren't tagged, punch items aren't documented because the friction is too high.
• The data gets entered incorrectly. When you're filling out a form in a language you're not confident in, you default to vague, minimal answers.
• Someone else enters the data on their behalf. The PM writes the daily log based on a 3-minute verbal summary, which is a game of telephone with a $78,000 job at stake.

That's the translation tax. It's paid in missing documentation, disputed claims, and hours of administrative overhead.

How MoveKore handles i18n at the field level

We built bilingual support from day one — not as an afterthought. Every field-facing component in the mobile app supports full locale switching between English and Spanish. The user's preferred locale is stored in their profile and applied on login.

For phase names, we store both the English name and a Spanish translation in the database. When a Spanish-speaking crew member views their assigned phases, they see the Spanish name. When the PM reviews the same project in English, they see the English name. No data duplication — one source of truth, two views.

The same applies to the sub portal: a subcontractor who receives a tokenized portal link gets the interface in their browser's detected language, with a manual toggle if they prefer the other option.

What this changes operationally

When the friction of language goes away, the behavior changes. Daily logs get submitted by crew, not dictated through a PM. Photo tags are accurate because the crew member selecting "Before / Antes" understands what they're choosing. Change orders get created in the field because the form makes sense.

The audit trail becomes a true record of what happened, not a reconstruction by a PM who wasn't on site.

That's worth more than any specific feature we could build. Because the value of a CRM isn't the software — it's the data quality it produces under real working conditions.