Commissioning web development from abroad is a different exercise from commissioning it at home, and this market has a particular set of expectations that catch out buyers who assume otherwise. The engineering talent is deep and the agency layer is well organised. What trips people up is everything around the code: which language the contract is written in, which law governs it, what the finished site is legally required to display, and how a French audience expects to be addressed.
Contracting across a border before writing any requirements
Settle four things in advance. Which language the agreement is written in, and if bilingual, which version prevails in a dispute. Which country's law applies and where disputes would be heard. How you will be invoiced, in which currency, and how value added tax is handled between businesses in different countries. And who, on your side, is authorised to accept deliverables, because acceptance here is a formal step rather than a friendly nod.
Expect web development proposals to be more structured than you may be used to, with clear phases and defined deliverables per phase. That formality is an advantage if you meet it with an equally specific brief. Send requirements as written acceptance conditions rather than aspirations, and expect them to be read closely. A supplier here will generally do what the document says, which is excellent news if the document is good and a problem if it is vague.
Building for a French speaking audience is more than translation
A site aimed at this audience has to be written in the language, not converted into it, and that reaches into the templates. Typographic conventions differ: spacing before certain punctuation marks, the correct quotation marks, capitalisation rules in headings that English style guides get wrong. Dates, decimal separators, phone formats and postal addresses follow their own patterns, and a form that validates against English assumptions will reject real customers.
Layout has to survive longer strings, since translated text commonly runs longer than the English source and breaks navigation and buttons designed to an English width. Tone matters too, with a formal register expected in most commercial contexts. If the site also serves an English speaking audience, treat both languages as first class in the content model, with stable identifiers, one path structure per language and alternate language declarations emitted on every page.
Legal pages and consent are build items with a regulator behind them
Commercial sites are expected to publish legal notices identifying the operator and the host, terms for anything sold, and a privacy statement, all reachable from every page and readable without scripting. These are template and routing decisions, so they belong in the web development scope from the start rather than arriving as extra pages at the end.
Consent handling deserves specific attention because the national regulator has been active and specific about it. Non essential tracking must not run before agreement, refusing has to be as easy as accepting, and audience measurement can be exempt from consent only under narrow conditions relating to how it is configured and what it retains. Implementing to those conditions is an engineering choice made while the measurement layer is wired, not a banner dropped on top afterwards. Ask any candidate to show a site they built with consent refused and the network activity visible.
Accessibility expectations that reach private companies too
Public sector sites have long carried a conformance obligation, the national reference framework is used for assessment, and the underlying standard is the familiar international one. The scope has been widening towards large private organisations and consumer facing digital services, so if you sell to either, treat WCAG 2.1 conformance as a requirement with an audit trail rather than an intention.
The implementation work is in the markup and the behaviour: semantic structure, keyboard operation, visible focus, properly labelled forms, meaningful error messages, contrast, and alternatives that describe rather than decorate. Ask which automated checks run in the pipeline, who performs the manual pass, and whether the team can produce the declaration of conformity that an assessment expects.
What web development in Paris usually costs you in calendar rather than money
The working rhythm is worth planning around. August is genuinely quiet, the end of year period likewise, and approval chains in larger organisations are more layered than a similarly sized company elsewhere might be. None of this makes delivery slower in absolute terms, but a launch date planned without it will slip.
Build the calendar backwards from a launch window that avoids those periods, and name the decision makers on both sides at kickoff. If your organisation sits several time zones away, fix a standing overlap slot and accept that decisions land the following morning. Agree that blocking questions go out in writing with a proposed assumption attached, so work continues while you sleep.
Payment methods and the local habits your checkout must respect
If the site sells to this market, the payment layer is not a generic component. The domestic card network is routed differently from international schemes, and acceptance rates and fees depend on whether your provider supports it properly. Instalment payment at checkout is widely expected in retail, bank transfer is normal between businesses, and invoice terms differ from what a purely domestic seller elsewhere is used to.
Decide the method mix before the order model is designed, because it is one of the web development decisions that is hardest to reverse afterwards, because each option changes the states an order can occupy and what has to reconcile at month end. Ask candidates which providers they have integrated for this market specifically, and what they had to build around each one rather than configure.
Hosting, data and the questions procurement will ask
Expect scrutiny of where the application runs, where backups are replicated, which third party services receive personal data and whether a processing agreement covers each of them. Self hosting fonts and avoiding unnecessary external requests has become standard practice rather than a precaution. A useful deliverable to request is an inventory of every outbound request the finished page makes, with the recipient named; it is the document your legal team will want and a good test of whether the build was thought through.
Ownership, handover and choosing between bids
Open the hosting, registrar and repository accounts in your own company name and add the agency as a collaborator, rather than the reverse. Ask for commit access from the first iteration, deployment instructions a stranger can follow, and a written transfer of rights in the delivered work on payment, with third party components listed under their licences. Have somebody outside the project stand the application up from the documentation before the final invoice is settled.
When comparing proposals, ask each web development firm for a single page stating assumptions, exclusions and the people who would actually be assigned. If the requirement is really about interface and brand, design studios in the city answer it better; a phone application belongs with app specialists, and ongoing visibility work with search consultants. The full supplier picture is in the web development company directory, and if you are comparing pricing across borders, teams in Belgium, Amsterdam or Budapest operate under comparable rules. With contract terms, language model, consent approach and payment mix written down, put the same document to several verified builders.