Contents
If you are commissioning an app, start by asking what a useful first release needs to do and what the quote actually includes. A business app connected to existing systems and a founder’s new customer product can have similar screens but very different delivery work. This guide helps you brief a mobile app development company, compare proposals and separate the initial build from the cost of running it.
Start with a first release your customers can use
Write one complete journey: who opens the app, what they need to achieve and how they know the task is finished. A membership app might need a customer to join, access a pass and find an offer. A field tool might need someone to record a visit and send it to the office. Include the people who manage the service behind that journey.
Keep later ambitions separate from the first commitment. A founder might test one customer problem before adding a wider catalogue. An established business might begin with one team before replacing its whole process. Describe what remains manual and who handles it; removing a feature does not remove the work if staff must do it elsewhere.
Use the first conversation to resolve what you need to learn before committing to a build. GOV.UK discovery guidance supports understanding users, the problem and constraints first. It is useful planning guidance, rather than evidence of a commercial app price.
Compare app quotes using the same scope
Ask every supplier to separate the mobile app, backend services, administration, integrations, testing, launch and ongoing support. A quote for the app screens alone cannot be compared directly with one that includes member accounts, payments and an administrative system.
Consider this fictional membership-app brief. Offer A includes joining and viewing a digital pass, but assumes that your team already has a working member database and account service. Offer B includes those same app journeys plus the account service and an administration screen. Neither is automatically better value: first check what you already have and which work you actually need to buy.
Ask both suppliers to state their assumptions, exclusions, your responsibilities and what would change the estimate. Record the quoted amount only once they provide it; this example supplies no prices and describes no customer proposal. The useful comparison is what your business receives for each commitment.
Decide whether the first release needs iOS, Android or both
Find out which phones or tablets your customers or staff use. For a company-device rollout, a known Android device range may define the first scope. For a customer service, covering both iOS and Android may matter. Make that decision from your audience rather than assuming every first release needs every platform.
Agree supported devices, accessibility and any camera, location, notifications or offline tasks. Ask which requirements need a short trial before they can be estimated confidently. Native and cross-platform delivery still need platform-specific checks and release work; a shared codebase does not mean one store submission or one device test.
Include the business behind the app
List accounts, records, payments, notifications and systems the app must connect to. Identify which already exist, who can grant access and whether documentation and a test environment are available. An existing website is not evidence that a usable connection exists for the proposed mobile journey.
The published Infinity Club case study shows a membership product spanning members, partners, offers, subscriptions and administration, with a connected web and mobile experience. That makes a useful question for your own brief: which responsibilities sit in the app, and which belong in the shared service behind it? It does not establish a price, framework or store approval for your project.
Budget for launch, ownership and support
Include distribution preparation, product information, privacy declarations, device testing and the business decisions needed for launch. Apple publishes review guidelines for App Store submissions; ask the supplier and product owner to agree who prepares each part. Store approval and review timing remain the store’s decision.
Ask what you will control at handover: repositories, store accounts, signing arrangements, hosting and documentation. Separate ongoing hosting and third-party services from maintenance and new features. Confirm who responds when an operating-system update or a changed external service affects the app, and what the proposed support arrangement covers.
What to send an app development company
Bring a short description of your users, their main task, target devices, existing systems, launch constraints and budget position. Include any app, design or research you already have. A founder can begin with a customer problem and a clear first journey; an established business should also explain the current process and who will make decisions.
Ask for a proposal that shows what the first release delivers, what is excluded and what needs investigating. Agree how you will try the result with representative users before launch. You should leave the discussion able to explain the next purchase and the responsibility your business keeps.
An illustrative iOS and Android app budget
Assume a fictional membership app covering sign-in, a member pass and offers on iOS and Android, with a shared backend and a small administration interface. Allow 10 person-days for discovery and design, 40 for mobile and backend implementation, 12 for testing and release preparation, and 4 for handover: 66 days. At an invented blended £650 per day, delivery is £42,900. A separately held 20% contingency adds £8,580, giving £51,480 before VAT.
These are illustrative inputs, not a Veda quotation, a market average or a promised release date. Exclude store-account fees, recurring infrastructure, payment transaction fees, customer service, future features and ongoing maintenance, then request those separately. The assumption includes both platforms and the service behind the app; a screens-only proposal is a different scope.
If the first brief adds disconnected pass verification, specialist hardware or a second payment route, investigate the actual operating rules and platform constraints before increasing the total by a guessed percentage. Treat store submission and review as dependencies, with named account and content owners. Apple’s review guidelines inform the submission discussion; they do not set the duration or approval outcome for this hypothetical app.
How this relates to Veda Software’s work
Infinity Club’s published member, partner, offer and subscription ecosystem demonstrates the scope behind an app. It supplies no budget, framework choice or store-review result for this illustration.