Reading a mobile app quote: 5 clauses that cost you

Short answer

An honest mobile app quote contains five precise clauses: exhaustive scope of features with what is explicitly out of scope, source code ownership from the first commit, change management handled through written and priced change orders, tests and acceptance with written criteria, store publication under the client's developer accounts. Without these clauses, the final bill routinely runs 20 to 50% above the initial quote. On a €28k initial quote, that translates to €15k to €35k in additional unplanned spend.

A vague quote sells vague work

Many founders read a mobile quote like a plumber's quote. They look at the total at the bottom and the headline duration, then sign. But a mobile quote for €28k can run three pages or fifteen pages depending on the vendor, and the difference is often worth ten thousand euros in surprises.

A clear quote protects both sides. The vendor cannot sneak in ten features; the client cannot demand five unplanned features without a contractual discussion. Ambiguity suits everyone until the day it stops suiting one of them.

The five clauses detailed below cover 90% of the surprise change orders I see when reading second opinions on quotes. Each one represents several thousand euros of risk if missing.

Clause 1: exhaustive scope with explicit exclusions

What you want to find:

Numbered list of features, at least fifteen to twenty-five lines for a serious MVP
Each feature estimated in days or percent of the fixed fee
A section titled "explicitly out of scope", often omitted. This is where most of it plays out.
Third-party integrations named explicitly, with API version where it matters (Stripe Checkout vs Stripe Connect, Firebase Auth vs Supabase Auth, Mangopay, SendGrid, etc.)

Red flags:

Vague phrasing like "standard mobile app features"
Generic groupings "push notifications, chat, payments, etc."
"The rest will be specified at project kickoff"
Features listed without associated days

Why this clause matters. On a vague scope, every discussion becomes a negotiation. The founder asks "can we add Apple sign-in?", the vendor answers "that is not planned, it is a change order". On an explicit scope with its exclusions, the same discussion becomes "is Apple sign-in in line 7? No, it is in the exclusions list, so it is a change order". The rule is known in advance.

Average surprise cost if missing: €5k to €10k excl. VAT on a three to four month project, spread over three to eight medium change orders.

Clause 2: code ownership and access handover

What you want to find:

"The source code belongs to the client from the first commit"
"The Git repository is hosted on a client account (GitHub, GitLab, Bitbucket); the studio accesses it as a collaborator"
"Third-party service accesses (Supabase, Stripe, Sentry, EAS Build…) are created on client accounts from day one"
"The Apple Developer account ($99/year) and the Google Play account ($25) are in the client's name, not the studio's"

Red flags:

"The source code is the agency's property, licensed to the client for the duration of the contract". Full trap. The client cannot change vendor without buying everything back.
"The code will be provided at project end, after full payment". With no detail on intermediate hosting, this lets the studio hold the code in case of dispute.
"Publication happens on our developer account". The client becomes a tenant of their own application and loses it if the vendor goes under.

Why this clause matters. The source code of a mobile app is not a deliverable like a PDF report. It is a living asset. The founder must be able to reclaim it at any time, either to continue in-house or hand the next phase to another studio. The legal detail is covered in who owns mobile app source code.

Average surprise cost if missing: €3k to €7k excl. VAT to buy back rights, plus several months of delay if the original studio drags its feet. In some cases of outright breakdown, the loss is total.

Clause 3: scope-change management

What you want to find:

A clear rule: "any out-of-scope change is handled through a written and priced change order before work starts"
A precise daily rate or fixed change-order fee. In France in 2026, a senior mobile developer charges between €500 and €800 excl. VAT per working day.
A definition of what is not a change: bug fix (covered by warranty), minor visual tweak, clarification of a feature already planned but whose detail was not fully nailed down

Red flags:

"Each request will be reviewed case by case". No framework = elastic pricing in the wrong direction.
"We accept changes flexibly". Elastic pricing in the other direction, to maintain a good relationship and charge later.
Full absence of a change clause.

Why this clause matters. On any mobile project longer than four weeks, three to eight scope changes come up. That is normal; it signals the founder is learning about their product by seeing the first version take shape. What matters is not avoiding changes. It is knowing in advance what they cost.

Average surprise cost if missing: €5k to €10k excl. VAT on a three to four month project, often invoiced in one shot at the end.

Clause 4: tests, acceptance and corrective warranty

What you want to find:

Nature of planned tests: unit tests on critical functions, integration tests for main journeys, manual tests on target devices
Acceptance duration: how many days between "code frozen" and "delivery accepted", and how many client-review rounds
Written acceptance criteria: how a feature is judged shippable
Post-launch bug policy: how long fixes are covered, when an evolution becomes a paid change order

Red flags:

No mention of tests
"Acceptance: 2 days" (impossible on a serious MVP)
"Post-launch bug support: 1 week" (laughable for a production app)
Full absence of a corrective policy

2026 best practice. Acceptance of two to four weeks depending on complexity, corrective warranty of one to three months post-launch, unit tests at a minimum on critical functions (payment, authentication, offline sync). At Inyka, the fixed package includes one month of post-launch corrective support, after which the Care plan takes over at €290, €590 or €1,190 per month depending on the coverage level.

Average surprise cost if missing: €2k to €5k excl. VAT in post-launch bug tickets invoiced outside the package, during the two to three months after go-live.

Clause 5: store publication and developer accounts

What you want to find:

Who creates the Apple Developer account ($99/year) and the Google Play account ($25 one-time)
Who writes the store listing: title, description, keywords, screenshots, category, privacy policy
Who manages the first publication and subsequent updates
Who responds to Apple App Review rejections, which can extend publication by one to four weeks depending on the reason

Red flags:

"Publication is not included in the fixed fee"
"Publication included, but managing store rejections is billed separately"
No mention of who creates the developer accounts
Full omission of store-listing content

Why this clause matters. Publishing an app on the App Store and Google Play is not a magic button. Each store has its rules, recurring rejection reasons, documentation requests (privacy policy, account deletion policy, demonstration of paid features). A vendor that excludes publication leaves this mess to the founder, who typically takes three to five weeks to work through it alone.

Average surprise cost if missing: €1k to €3k excl. VAT + three to five weeks of publication delay, or more if App Review rejects multiple times.

Summary table of the 5 clauses

Clause	Red flag	Average surprise
Exhaustive scope	"etc.", "standard", "to be specified"	€5k to €10k
Code ownership	Code owned by agency, delivered at end	€3k to €7k + delays
Change management	"Case by case" or nothing	€5k to €10k
Tests and acceptance	No mention, "2 days"	€2k to €5k
Store publication	Not included, paid rejections	€1k to €3k

Cumulative probable surprises on a €28k quote without these five clauses: €15k to €35k additional. The quote "at market price" becomes a project invoiced 50 to 100% above the initial figure. That is the mechanism behind founders feeling their app "cost much more than expected".

Three questions to ask before signing

If you want to test a quote in five minutes without dissecting it all, three questions filter the essentials.

Does the quote explicitly list what is excluded from scope? An answer like "it is implicit, anything not listed is not included" = vague quote. An answer like "yes, see section X" = serious quote.
Does the code belong to me from the first commit or at final delivery? "From the first commit, on your repo" = serious. "At the end, after full payment" = door wide open to a standoff.
What is the daily rate for an out-of-scope change? A studio that refuses to answer or gives an evasive answer will invoice you with a wet finger.

A vendor that answers vaguely on all three will sell you vague for the entire project.

What an Inyka quote looks like

At Inyka, the three packages (Essential €7,500, Launch €14,000, Scale from €24,000 excl. VAT) are built around these five clauses, written out in each quote. The code is hosted on a client-owned repo from the first commit. Store publication is included, Apple rejections included. Out-of-scope change orders are billed at €650 excl. VAT per day, stated before signing.

It is not specific to Inyka, it is the minimum any founder should require from any studio. The Inyka price grid details what each package includes.

FAQ

How long should a serious mobile app quote be? Between six and fifteen pages for a simple MVP at €7-14k, between fifteen and twenty-five pages for a €24-50k project. Below five pages for a budget above €20k, the quote is too concise to cover the five clauses.

Does the source code automatically belong to me? No. Without an explicit clause, French copyright law considers the code belongs to its author, not the commissioning party. A written transfer of rights in the contract or quote is required.

How much does an out-of-scope change order cost? Between €500 and €800 excl. VAT per working day in France in 2026, depending on developer seniority. A change like "add Apple Sign-in" is often one to two days, so €500 to €1,600. Larger-scope change orders (for example adding a recurring payment module) grow to five to ten days.

Who should publish the app on the stores? Developer accounts must be in the client's name. The technical publication can be handled by the studio, but under the client's accounts, not its own. That is the only configuration that guarantees the client can recover its application in case of dispute.

Can these clauses be negotiated with a studio? Yes, and it is expected. A serious studio accepts them without difficulty because they match its normal operation. A studio that resists on several of the five clauses is sending a strong signal about the relationship ahead.

Have your quote reviewed

A €20 to €50k mobile quote deserves an hour of reading by someone with no interest in you signing. If you have a quote in hand and want it reviewed, email it to contact@inyka.app (attach the PDF), or book a 30-minute discovery call to discuss it over video. Written note within five business days, free, no obligation to sign with Inyka afterwards.

To go further on scoping, see the specification that makes quotes comparable and the Inyka 2026 price grid.