Explore how delivery works

Who this is for

Businesses with a defined mobile use case or founders ready to test a focused app with real users.

What is included

A written plan defining users, screens, core journey and acceptance checks.
A working app built to the agreed platform and feature scope.
An early version for feedback and an agreed device test plan.
Source-code handover, setup instructions and a walkthrough.
App-store submission support where included in your proposal.

How it works

Start with a fit call. We establish whether a mobile website, existing platform or native app best suits the job. Your proposal sets the price, milestones, revision allowance and delivery dates. Store review times are outside Labs' control.

What you take away

The app and documentation specified in your proposal, built in accounts you control where practical. Bespoke source code transfers after payment, subject to third-party licences.

Price

Fixed quote after scoping. Payment milestones are set out before work starts.

When you need a different scope

Payments, notifications, offline use, location features and integrations materially affect scope and are priced explicitly. Developer-account fees, hosting and third-party services are separate.

Ownership, costs and next step

Start with a short fit call. We confirm the scope, total price, access needed and delivery dates in writing before work begins. Prices are in GBP, excluding VAT where applicable. Software subscriptions, hosting and AI usage are separate and disclosed before you commit. A Hub subscription is only needed if it is the platform you choose. Ongoing support is optional.

You keep the agreed deliverables and editable documentation. Bespoke code transfers after payment, subject to third-party licences; existing platforms remain licensed. We explain any limitations on export or moving providers. Results depend on the process and how the tools are used; no particular savings are guaranteed.

Builds include 30 days of fixes for defects against the agreed scope from handover. New features, third-party outages and platform changes are separate from that cover.

Putting it into practice

Before we begin

Describe the person who would use the app and one job they need to complete. Explain where that job happens and what makes a mobile experience useful. A focused first release starts with a clear journey, rather than every feature that could eventually belong in the product.

Bring any existing process, sketches or examples that help explain the idea. Highlight requirements such as offline use, payments, notifications, location or integrations early, because they materially affect scope. You do not need to assume a native app is the answer; the fit discussion considers a mobile website and existing platforms too.

An illustrative walkthrough

Imagine a colleague visiting a job and needing to record a short update. In this illustrative journey, they open the relevant item, add the agreed information and see that it has been saved. Whether it must work offline, include photographs or connect to another system changes the design and must be explicit in the proposal.

The early version helps you discuss the core journey with realistic use in mind. The agreed device test plan and acceptance checks make feedback more specific than “make it feel better”. A first release can focus on the essential job while keeping later ideas visible as separate decisions, rather than silently growing the contracted scope.

Using the result

Keep the setup instructions, account ownership and source-code handover clear as the project reaches delivery. The proposal specifies which app, documentation and submission support are included. Third-party licences, developer accounts and hosting remain distinct from ownership of bespoke code after payment.

Plan for the people who will operate the app as well as the people who use it. Someone needs to understand the release accounts and the agreed support arrangements. Store review timing remains outside Labs' control, so a desired launch date should be discussed alongside that dependency rather than treated as a guaranteed approval date.

Scope and pricing

Custom Mobile Apps

Design and build a mobile app around one useful customer journey, with a clear scope, testing and handover agreed before development.

Price on request

FAQs about this service

Do I definitely need a native app?

Not necessarily. The fit call considers whether a mobile website, an existing platform or a native app best suits the job before the proposal is agreed.

How is the project priced?

It receives a fixed quote after scoping. The proposal sets users, screens, platforms, milestones, revision allowance, payment terms and delivery dates before work starts.

Are offline use and notifications included?

These features materially affect scope, as do payments, location and integrations. They are priced explicitly rather than assumed to be part of every app.

Will you submit it to the app stores?

App-store submission support is included where specified in the proposal. Developer-account fees are separate and store review times are outside Labs’ control.

Who owns the finished source code?

Bespoke source code transfers after payment, subject to third-party licences. The app is built in accounts you control where practical, with setup instructions and a walkthrough.

What ongoing costs should I expect?

Hosting, developer-account fees and third-party services are separate. The scope discussion explains relevant ongoing costs before you commit; ongoing support is optional.