Thanks for asking us to help. It works alongside the proposal you accepted. If anything is unclear, we will talk it through and write down what we agree before we move forward.
We build apps the way they behave in real hands, not just in screenshots. That means we agree the scope first, we test on real devices as we go, and we plan the handover from day one so you can run the app after launch.
What we will build
We will deliver mobile app development as a project, based on the screens, prototype, and integration notes we agree with you at the start. The list of deliverables for this project sits under this section.
To keep the build stable, we treat the agreed Figma screens and prototype as the source of truth once development starts. If you need changes because something is missing or a workflow breaks in testing, we will handle that through the changes process rather than squeezing it in informally. That protects performance, offline behaviour, logins, payments, and release readiness.
* Figma screens and prototype * Android app build * iOS app build * Backend API and database * Release submissions package * Handover documentation
Payment
To book mobile app development, we invoice 50% of the total price when you sign the proposal. We schedule work and reserve the team once that invoice is paid.
We invoice the remaining 50% when we hand over the finished work. Every invoice is payable within 14 days of its date.
If an invoice goes past its due date, we will pause new development and store-release steps until payment is back up to date. We will tell you what is paused and what is at risk on the timeline. We will also still protect your code and project access while things are on hold.
Changes
A revision round is a set of changes you send us together, after you have reviewed a clear checkpoint deliverable. For this project we include two revision rounds on the Figma screens and clickable prototype, and one revision round on the app builds once the main flows are implemented.
Anything beyond those rounds, or any change that alters an approved screen, a data model, an integration, or a core workflow, is a change request. We will write down what changes, give you a price or timeline impact, and get your written approval before we build it. That avoids surprise work and last-minute instability.
Who owns what
Once the final invoice is paid, you own the code we wrote specifically for your mobile app development project. At handover we give you the source code repository, final builds, API documentation, and setup notes so another team can take over if needed.
We keep ownership of our pre-existing tools, templates, internal libraries, and ways of working, even if we used them to build your project. Third-party services and libraries stay under their own licences and terms. If you want us to add a paid SDK or service, you pay that vendor directly and the account stays in your name.
Portfolio use
After launch, we may show the finished work as part of our portfolio. Usually this is a short case study and a few screenshots, and we focus on what we built: the platform, the key flows, and the technical approach.
If you do not want us to share the app, your name, or any screenshots, tell us in writing. We will follow that request, including if you want a time delay before we post anything. If the app is private to staff, in pilot, or under an NDA with a partner, we will treat it as private once you flag it and we will not post it.
Problems and limits
We stand behind our work, and we will fix bugs that are caused by our code and that are reported within a reasonable period after handover. We will agree the fix plan with you, and we will prioritise issues that affect login, payments, data loss, crashes, or store compliance.
There are also limits. We cannot be responsible for outages or failures in third-party services you use (payment providers, SMS gateways, hosting, analytics, or SDKs), or for delays and rejections controlled by Apple or Google during review. We also cannot cover losses that come from how the app is operated after handover, such as changes made by other teams or credentials shared insecurely.
Ending the project
Either of us can end the project by giving notice in writing. We will agree the notice period with you in writing, based on what is in flight and what would be risky to stop abruptly.
If the project ends, you pay for the work completed up to the end date, including any non-cancellable costs you asked us to take on (for example paid services or test devices). We will then hand over what we have completed and that you have paid for: the current source code, builds, and documentation in a usable state, plus a short handover call so your team knows what is where. If payments are behind, we will still provide a basic export of your project materials once the account is settled.
Signature
