In Montreal, French is a delivery requirement rather than a translation task
Most buying guides treat language as something you add at the end, by exporting a spreadsheet of strings and sending it away. That approach produces a product that is technically bilingual and obviously an afterthought, and in this market users notice immediately. Quebec's language legislation also gives the question a legal edge for anything customer facing, which means the decision belongs at the start of design, not in the final sprint.
The design consequences are concrete. French text runs longer than English, so buttons, tab bars and form labels that were laid out in one language break in the other. Dates, currency and address formats differ. Push messages and error states need writing twice, by someone who writes rather than someone who translates. Ask every mobile app studio you shortlist how they handle string length in layout, whether their designers work in both languages from the first screen, and who writes the French copy. A studio that answers with the name of a translation vendor has told you where language sits in their process.
The store listing is localized separately from the mobile app itself
This catches buyers out constantly. Even when the product inside is fully bilingual, the title, subtitle, description, keywords and screenshots on each platform are managed as a distinct set of assets, and a listing that exists only in English will underperform for exactly the audience you built the French version for.
Put listing localization in the scope explicitly: both languages, both stores, screenshots regenerated per language rather than the same images with an English interface visible. Ask who maintains those assets after launch, because they change with every significant release and they are the first thing that quietly goes stale. It is a small line item that has a measurable effect on how many people install a mobile app after finding it.
Your supplier is recruiting against the games and effects studios
The local talent market has an unusual shape. A deep pool of interactive, graphics and animation specialists sits alongside application development firms, and both compete for the same engineers and designers. That gives this city genuine strength in mobile app products where motion, interaction and visual craft matter, and it also creates a specific risk for you: the person assigned to your project may be recruited away mid engagement by a larger studio with a more glamorous brief.
Handle it in the contract rather than by hoping. Name the individuals in the statement of work, agree a notice period for substitution, and require that any replacement overlaps with the person leaving rather than reading the code after they have gone. Ask each firm what their retention has looked like over the past two years and how many people have worked on their longest running client. The answer is more informative than any portfolio.
Consent and data handling shape the first screens users see
Privacy obligations under both federal and Quebec rules mean that what you collect, why, and how you ask must be decided before the onboarding flow is drawn. Tracking permission prompts, analytics identifiers, location access and the ability to withdraw consent later are all design work, not configuration. A product that requests everything on first launch trains people to refuse, and once a user has declined a permission, getting it back requires sending them into system settings.
Ask candidates to show you an onboarding sequence they have built where a permission is requested in context, after the user has seen why it matters. Ask what data their proposed analytics and crash reporting tools transmit, and where it is stored. Third party components are the usual source of unpleasant surprises here, because each one arrives with its own collection behaviour and your privacy disclosure has to account for all of them.
What a bilingual test pass actually involves
Testing a bilingual mobile app is not testing it twice. It is testing the places where language interacts with everything else: text that overflows a fixed control, a sorting order that changes with accented characters, a search that should match with or without diacritics, a date picker that starts the week on a different day, notifications that arrive in the language the phone is set to rather than the one chosen inside the product.
Ask each supplier for their device and language test matrix, and check that switching the system language mid session is included. This is also where an honest conversation about accessibility belongs, since screen reader behaviour has to be verified in both languages and the label written for a visual user is rarely the label a screen reader needs.
Comparing Montreal proposals without being misled by the total
Local rates are competitive enough that buyers from elsewhere sometimes treat this market as a discount option and brief it accordingly, which produces the outcome they expected. Brief it properly instead and the value is real. Send three mobile app firms the same document: what the product does, who uses it, in which languages, what it connects to, and what the first release must achieve. Then compare their assumptions, exclusions and questions before any figures.
Confirm the essentials in writing. The store accounts and signing keys registered to your organisation. The repository under your control. A separately priced maintenance arrangement that covers annual platform releases and store rejections. If your scope also reaches a public website or motion work, engage those specialists on their own terms, whether web development firms in the same city or local animation studios, rather than asking one team to be strong everywhere. The wider supplier picture, including the national market, sits in the mobile application development directory. Once the brief is written in both languages you intend to ship, put it in front of several verified studios at once.