A mobile app in Paris is not a project with an end date
Buyers negotiate hard on the build and then discover that the build was the small commitment. Once a mobile app is installed on people's phones it needs releases, monitoring, store maintenance, support and a reason for anyone to open it again next week. Those costs start the day you launch and do not stop while the product exists. The useful question in a procurement conversation is therefore not what the first version costs, but what the second year costs and who is doing the work in it.
This page is about that second year, because it is where most of the money and nearly all of the disappointment live. The decisions that determine it, however, are made before a line of code exists, which is why they belong in the brief rather than in a review meeting nine months later.
Store billing decides what your revenue actually looks like
If you sell anything consumed inside the mobile app, digital content, a subscription, a premium tier, the store billing system generally has to handle it and takes a commission on every transaction. If you sell physical goods, bookings or services delivered in the real world, you can normally use your own payment flow. That single distinction changes your gross margin, your pricing, your refund process and your accounting, and it is frequently discovered after the commercial model has been agreed with a board.
Work it out first. Then follow the consequences: what a subscription looks like when it renews, what happens when a customer requests a refund through the store rather than through you, whether a purchase made on one platform is recognised on the other, how a free trial converts, and how a cancellation reaches your systems. Ask the supplier to describe that flow end to end before design begins. A team that has shipped subscription products will do it fluently.
The store listing is a conversion surface, and it is nobody's job by default
Most of the traffic your product will ever get arrives through a search inside a store, and what converts that search into an install is the title, the subtitle, the first two screenshots and the rating. This is a marketing asset that lives outside your website, changes when the interface changes, and is almost never assigned an owner in a build contract.
Ask explicitly who writes the listing copy, who produces and updates the screenshots, who chooses the keywords and who responds to reviews. Then ask how the listing is tested, because both stores allow variants to be compared and the difference between an indifferent listing and a considered one is larger than most interface improvements. A mobile app with a strong product and a neglected listing quietly loses most of its potential audience before anyone installs anything.
Instrumentation you have to ask for in the contract
You cannot manage a mobile app in its second year without evidence, and evidence has to be built in. At minimum that means crash reporting with alerting, a funnel that shows where people abandon the first session, a retention view, and release health broken down by version and platform. None of this appears by accident, and it is one of the first things removed when a fixed price is under pressure.
Name it as a deliverable. Ask how the tracking plan is documented, who owns the analytics account, and how measurement respects the tracking permission prompt, since a meaningful share of users decline it and attribution built on the assumption that they will not is attribution that lies to you. Ask for a dashboard you can read without the supplier present. A team that hands you numbers only in meetings is managing your perception of the product.
Release cadence, staged rollouts and the ability to stop
Shipping a mobile app monthly and shipping twice a year are different businesses with different cost structures. Frequent releases keep risk small and require automation, tests and a repeatable pipeline, which costs money once and saves it continuously. Infrequent releases look cheaper and concentrate risk into rare, tense events where a defect reaches everybody at the same moment.
Whichever cadence you choose, insist on staged rollouts with a halt, so a bad build reaches a fraction of users rather than all of them, and on a defined path for an urgent fix. Ask what happens when a submission is rejected during a week with a marketing campaign behind it. Then ask how quickly a crash affecting many users is noticed, and by whom, at eleven at night.
Who operates the product after the build team leaves
Three arrangements are common among Paris mobile app suppliers and they suit different situations. A maintenance retainer keeps the original team available with a response commitment, which is the simplest continuity and the easiest to over buy. A reduced ongoing team continues product work at a slower rate, which fits products that will keep evolving. A handover to an internal or new supplier is cheapest in fees and most expensive in risk, and only works if the documentation, accounts and keys were prepared for it from the beginning.
Decide which one you are aiming at before the build starts, because it changes what needs to be written down along the way. If you are handing over, the handover has to be rehearsed during the engagement rather than promised at the end, by having someone outside the team follow the instructions and produce a working build.
Comparing Paris proposals on the second year rather than the first
Ask every bidder for two numbers instead of one: the build, and a realistic annual cost of keeping the mobile app healthy afterwards, including the yearly platform compatibility work, library updates, store policy changes and a modest flow of small improvements. Suppliers who have supported products for years produce that second figure without flinching. Suppliers who mainly build will either omit it or guess, and the guess is usually low.
Then compare assumptions rather than totals, and keep the shortlist to three with an identical written brief. If the launch also needs campaign work or a promotional site, look separately at marketing teams working in the city and design studios nearby rather than expecting one supplier to be strong at everything. To survey the field first, browse the directory of mobile app developers, and when your requirement is written, request comparable proposals from verified suppliers.