Terms of Service | Mobile App Devs

Last updated: September 2026

These terms apply to development work carried out by Mobile App Devs and to the use of this website. Every project also has its own written proposal or engagement agreement covering scope, price and dates. Where a signed agreement and these terms disagree, the signed agreement wins. Nothing here overrides rights you have under the law that applies to you.

1. What we provide

We are a mobile-only studio. Our work is the design, development, testing, store submission and ongoing maintenance of applications that run on phones, tablets, wearables and connected TV devices — native iOS and Android, and cross-platform builds in React Native or Flutter — together with the backend services and APIs those apps need in order to function. We do not take on standalone web applications, desktop software or general IT work. If a project needs one of those alongside the app, we will build the mobile part and say plainly that the rest belongs to someone else.

2. Estimates, proposals and quotes are three different things

The words get used interchangeably and they should not be.

An estimate — including anything produced by the cost estimator on this site, and any range given on a first call — is an informed guess based on partial information. It is free, it is not binding on either of us, and it will move once the scope is properly understood.
A proposal sets out a defined scope, a timeline and a price, and is valid for thirty days from the date on it. It is an offer, and it becomes binding only once you accept it in writing.
A signed engagement agreement is the contract. The deliverables listed in it are what we owe you. Anything discussed in a call, an email or a chat message but not written into it is not part of the scope.

3. Fixed-price projects and support retainers

Fixed-price projects. Most builds work this way. We agree a defined scope for a release, we quote a single figure and a delivery window, and if the work takes us longer than we estimated that is our problem rather than yours. The trade is that the scope is fixed: additions go through the change process in section 7 instead of being absorbed silently until the date slips.

Support retainers. Post-launch work runs monthly against a fixed fee that reserves a stated capacity, described on the support plans page. A retainer is a standing commitment of availability rather than a block of hours you own: unused capacity may carry forward one month and no further, and the retainer does not accumulate into a bank that can be spent as a large project later.

Advisory work. Code reviews, technical due diligence and second opinions are quoted as fixed-price pieces with a written output, and you are free to act on that output however you wish, including by hiring somebody else.

4. Fees, currency and payment milestones

All fees are quoted and payable in United States dollars unless a signed agreement says otherwise. Prices exclude any tax, duty, withholding or bank charge that applies where you are; if your jurisdiction requires you to withhold an amount, the sum payable to us is grossed up so that we receive the quoted figure.

Fixed-price work is invoiced against milestones rather than against the calendar. The usual shape is:

On signature — a deposit that reserves the team and starts discovery and design.
On design sign-off — payable when the screens and the clickable prototype are approved.
At agreed build milestones — one or two payments tied to named, demonstrable stages rather than to a percentage of time elapsed.
On store submission — the final payment, due when the build is submitted to the stores and the deliverables are handed over. This is the payment that transfers intellectual property under section 9.

Retainers are invoiced monthly in advance. Invoices are payable within fourteen days unless the agreement states otherwise. We may pause work on an account more than fourteen days overdue, having told you first in writing; where that happens, the delivery dates move by at least the length of the pause, because a paused team does not stay reserved for free.

5. What the price does not include

These sit outside every quote we give, because they are billed to you by someone else and we will not mark them up:

Apple and Google developer account fees. Each store charges its own membership or registration fee on its own renewal cycle, billed directly to you because the accounts are in your company name.
Paid third-party APIs and services. Maps, SMS and one-time passcodes, push infrastructure beyond a free tier, payment processing fees, error reporting at scale, email delivery, identity verification, and anything else the app calls out to.
Hosting and infrastructure. Servers, managed databases, object storage, bandwidth, content delivery and backups for any backend, whether we built it or not.
Stock assets and licences. Photography, illustration, icon sets, fonts and any commercial library that requires a licence in your name.
Domains and certificates beyond what we set up as part of the work.
Content you supply — copy, translation, legal text such as your own privacy policy and terms, and the material for your store listing.
Marketing. Paid user acquisition, app install campaigns, influencer work and press.
Ongoing maintenance after the defect-fix window in section 12, which is a separate retainer.

We will tell you which of these your app will actually need, with realistic figures, before you commit to any of them.

6. What we need from you

Our dates assume these, and they are the most common reason a project slips:

One person who can decide. A single point of contact with the authority to approve designs and settle disagreements. Design by committee is fine as a process, but one person has to sign.
Feedback within a reasonable window. We work in two-week cycles; approvals that take longer than a cycle push everything behind them.
Access. Accounts, credentials, API keys, test data and any existing code or design files, provided through a secure channel when we ask rather than three weeks later.
Content and the right to use it. Anything you supply for the app or the store listing must be yours to supply, and you confirm to us that it is.
Compliance information. Any regulatory, contractual or industry requirement the app has to meet, told to us at the start. Retrofitting a compliance requirement into a finished app is expensive and occasionally impossible.

7. Change requests

Projects change, and a process that pretends otherwise just produces arguments. Small adjustments — copy, spacing, the order of a flow, an extra field — are absorbed as part of normal work. Anything that adds a screen, an integration, a platform or a piece of infrastructure is written up as a short change note with its cost and its effect on the delivery date, and no work on it begins until you approve that note in writing. We will not silently absorb a stream of additions and then explain a missed date afterwards, and equally we will not treat a reworded button as a billable event.

8. Timelines

Dates in a proposal are our honest working plan, dependent on the assumptions written alongside them. Two categories of delay are outside our control and move the date without being a breach: delays caused by your approvals, access or content, and delays caused by third parties — store review queues, a platform outage, an API provider changing something, a payment provider’s onboarding checks. We will tell you as soon as we see one coming rather than at the deadline.

9. Intellectual property

Transfer on final payment. When the final invoice for a piece of work is paid, all rights in what we made specifically for you — source code, designs, assets, configuration and documentation — pass to you outright. Before that point we hold those rights, which is the only security an unpaid supplier has; in practice it is a formality, because the repository has been in your organisation from the first commit.

What does not transfer. Three carve-outs, all of them ordinary:

Open-source components. Every serious mobile app is built on top of open-source libraries. Those remain the property of their authors and reach you under their own licences — typically permissive ones such as MIT, Apache 2.0 or BSD, which impose little more than an attribution notice. We avoid strong copyleft licences in distributed app binaries unless you have asked for them and understand the consequence, and we will give you a list of every component and its licence on request.
Our pre-existing know-how and internal tooling. Generic scaffolding, build scripts, internal utilities and the general skill and experience we brought to the project stay ours. You get a perpetual, irrevocable licence to use any of it that is embedded in your app, for the life of the app. What you do not get is exclusivity over general programming technique, and no client could.
Third-party commercial licences that are issued in your name, which are governed by their own terms.

Your material stays yours. Your brand, content, data and anything you supply remain yours throughout, and we claim no rights over them.

Portfolio reference. Unless you ask us not to, we may describe the work in general terms — the type of app and the problem it solved. We will not publish your name, your screenshots, your metrics or anything confidential without your written agreement, and an NDA overrides this paragraph entirely.

10. Store accounts, repositories and keys

The Apple Developer and Google Play accounts are created in your company name, with your organisation as the legal account holder, and we are added as a member with the access the work requires. The source repository sits in your organisation from the first commit. Android signing keys and iOS signing assets belong to you; we will keep a working copy for as long as we are doing your releases, and we will make sure you hold your own copy in a place you control, because a lost Android signing key cannot be reissued and means a new listing.

This arrangement is deliberate and it is not negotiable downward. We will not hold your store accounts on your behalf, because doing so would make your app an asset on our balance sheet rather than yours.

11. Confidentiality

Each side keeps the other’s confidential information confidential, uses it only for the project, and does not disclose it except to people who need it to do the work and are under equivalent obligations. That holds during the engagement and for three years afterwards, and indefinitely for anything that is a trade secret. It does not apply to information that is already public, was already known without an obligation of confidence, or must be disclosed by law — in which case we will tell you first if we are permitted to. A separate signed NDA sits above this clause where one exists.

12. Warranty and the defect-fix window

We warrant that the work will be performed with reasonable skill and care and will substantially conform to the agreed scope. For ninety days after the app is approved by the stores, we will fix at no charge any defect where the app does not do what the agreed scope says it does, on the OS versions and devices we agreed to support. That covers crashes, broken flows and functional errors in what we built.

It does not cover new features or changes of mind; problems caused by changes made by you or a third party; failures in third-party services; or the ordinary platform drift described on the support plans page — a new OS release, a new device size, an expired certificate, a store policy change. Those are maintenance rather than defects, and they are what the retainer is for. Beyond this warranty, and to the extent the law allows, everything else is provided as is.

13. What we cannot guarantee

This section exists because the opposite is routinely promised in our industry and none of it is deliverable by anyone.

App store approval. Apple and Google decide what goes into their stores, under guidelines they change at will and apply through human reviewers. We will build to those guidelines, prepare a clean submission, respond to every review comment and resubmit until the app is live. But nobody outside those companies can promise that a given app will be accepted, or that an app accepted today will not fall foul of a rule written next year. Anyone guaranteeing approval is guaranteeing something they do not control.
Store rankings and search position. App store optimisation improves how well a listing describes and presents your app, which is the only part anyone can influence. Ranking is decided by the stores’ own algorithms using signals — install velocity, retention, ratings, competitor behaviour — that are neither published nor stable. No specific position for any keyword is promised, here or in any proposal.
Download numbers, revenue or user growth. We build the app well and instrument it so you can see what is happening. Whether people install it, keep it and pay for it depends on your market, your pricing, your marketing and your product idea. We are not going to pretend engineering quality alone decides that, and we will not put a number in a contract that we cannot control.
Third-party behaviour. Platforms deprecate APIs, providers sunset endpoints and services have outages. We build defensively and we will fix the consequences as maintenance work, but we cannot warrant somebody else’s product.
Uninterrupted operation or absolute security. We follow sound practice — least privilege, encrypted transport, secrets kept out of the repository, dependencies patched — and no honest engineer describes any system as unbreachable.

14. Limitation of liability

Neither side is liable to the other for indirect or consequential loss, or for lost profits, lost revenue, lost data, lost goodwill or lost business opportunity, however it arises. Our total liability in connection with a project is limited to the fees you have actually paid us for that project in the twelve months before the claim. Nothing in these terms limits liability for death or personal injury caused by negligence, for fraud, or for anything else that cannot lawfully be limited.

15. Ending an engagement, and what happens on exit

Either side may end a project on thirty days’ written notice, and either may end it immediately if the other commits a material breach that is not put right within fourteen days of being told about it. On termination you pay for the work completed up to that point, including work in progress, and on receipt of that payment the intellectual property in everything delivered transfers to you under section 9.

Exit is a handover, not a standoff. You already hold the accounts, the repository and the keys, so there is nothing for us to release; what we do is provide a written state-of-the-app note, the build and release documentation, confirmation of where the signing assets live, a list of every third-party service the app depends on and what it costs, and then remove our own access once you confirm you are ready. There is no exit fee and no charge for the handover note.

16. Using this website

The content of this site is ours and is provided for information. Prices, ranges and timeframes shown here — including any figure produced by the cost estimator — are indicative and are not offers. Do not submit anything through the forms that is unlawful, that infringes someone else’s rights, or that you do not have the right to send us, and do not attempt to disrupt or probe the site. We may change or withdraw any part of the site at any time.

17. General

Independent contractor. We work as an independent supplier. Nothing here creates an employment relationship, partnership or joint venture.
Subcontracting. We may use vetted subcontractors, who are bound by equivalent confidentiality and IP-assignment obligations. We remain responsible to you for their work.
Non-solicitation. During an engagement and for twelve months afterwards, neither side will directly solicit the other’s staff or contractors who worked on the project. A general public job advertisement is not solicitation.
Force majeure. Neither side is liable for a delay caused by something genuinely outside its reasonable control.
Assignment. Neither side may assign an agreement without the other’s written consent, except to a successor of substantially the whole business.
Severability and waiver. If a provision is unenforceable, the rest stands. Not enforcing a term once does not waive it.
Entire agreement. The signed agreement, the proposal it refers to and these terms are the whole of what is agreed, and supersede earlier discussions.
Notices. Formal notices are given in writing by email to the addresses named in the agreement, and are treated as received on the next business day.
Disputes. If something goes wrong, both sides agree to raise it in writing and to talk it through with the decision-makers on each side before starting any formal process. The governing law and the forum for disputes are stated in the signed agreement for each engagement.

Contact

Questions about any clause on this page, before or after signing: info@mobileappdevs.net or +1 341 208 1344, Monday to Friday, 10:00–19:00 IST.