How do you assess relevant agency experience?
Before shortlisting suppliers, resolve the choice between a mobile and web application. Describe the main task, required device features and offline needs. Then compare references with those conditions. Sharing an industry is useful, but it does not establish experience with the same engineering problem.
For example, a field application may need to preserve work when connectivity fails. A booking product may depend more on roles, conflicting appointments and cancellation rules. These are illustrative situations. Ask whether the agency designed, built the mobile client, implemented the backend or maintained the reference; a portfolio logo does not prove responsibility for every part.
Request an authorised demonstration, an explained technical decision or an anonymised delivery example. You do not need another customer’s private information. Listen for how the team defined the difficulty, compared alternatives and checked the result. That evidence is more useful than an unsupported claim that it can develop any application.
What should a discovery phase produce?
When planning a first product release, expect questions about users, business goals, existing systems and decision owners. The supplier should explain which uncertainties prevent a dependable estimate. Discovery should produce decisions that define the following phase, rather than simply a record of meetings.
Look for the main task, necessary flows, data sources, deferred features and acceptance criteria in a shared document. Check “the API is ready” against access, sample data, error behaviour and documentation. For an uncertain payment or device integration, agree the question a small technical experiment will answer and the evidence that completes it.
An initial timetable may be preliminary; ask for its assumptions in writing. Clarify whether discovery is priced separately and whether its outputs can be used with another team. An estimate that conceals uncertainty provides less decision support than a clearly bounded phase with useful outputs.
Product boundary
Who completes which task, what the first release includes and which requirements are deferred.
Technical evidence
A small experiment for data, device or external-service assumptions, including findings and unanswered questions.
Acceptance plan
Working flows to demonstrate, the person who approves them and a record of agreed changes.
FROM READING TO A NEXT STEP
Assess the proposal against a defined scope
Share the main user task, existing systems and supplier proposals. We can clarify scope, delivery risks and handover requirements.
How should quality and team continuity be examined?
Mobile interface design should explain loading, errors, permission refusal and missing data as well as the successful screen. Ask which devices and operating-system versions are included in checks. Compare the critical workflows and test coverage alongside the screen list.
Code review, automated checks and manual task testing produce different evidence. Naming a method is insufficient: how is a defect recorded, how is its severity assessed and who verifies the correction? Performance or security claims need an agreed measurement and scope, rather than a universal assurance.
Meet the roles that will perform the work, discuss available capacity and ask how knowledge survives staffing changes. Regular demonstrations help make decisions visible, but a demo is not final acceptance. A current task list, decision record and known-issue register allow progress to be reviewed without depending entirely on verbal reports.
Who should control code, accounts and releases?
Preparing for store release includes knowing who controls each account. Request an inventory covering repositories, design sources, backend services, domains and external providers. Business-controlled accounts with appropriate individual access provide a practical basis for continuity.
Google Play distinguishes account-level and app-level permissions, while Apple defines access through user roles. Discuss invitations, suitable privileges and offboarding instead of assuming a shared personal password. Provider access and contractual source-code ownership are separate questions; clarify both.
A source archive alone does not prove a usable handover. Another authorised team should be able to follow the setup instructions, build the application, use the test environment and prepare a release candidate. Document signing arrangements, environment-variable names, backups and known issues. Secret values require controlled transfer rather than inclusion in public instructions.
How do you compare maintenance arrangements?
For mobile app maintenance, distinguish defect correction, operating-system compatibility and new features. Expand “support included” into its duration, capacity, working hours and reporting channel. A first-response target does not automatically establish a resolution deadline.
Agree who assesses an incident’s severity and who communicates with users. The agency cannot fully control a payment or notification provider’s outage, but diagnosis, escalation and alternative procedures can still have named owners. Different incidents may require different recovery approaches.
Ask how documentation and the dependency inventory remain current during maintenance. New features should have their own approval, commercial arrangement and acceptance checks. If regular specialist work is necessary to operate the product, selecting solely on the initial development fee leaves an incomplete view of cost and responsibility.
How do you make the final proposal comparison?
Send the same brief, based on the product’s platform requirements, to shortlisted teams. List the client, backend, administration tools, integrations, tests, store preparation and maintenance separately. If your own team covers an exclusion, include that capacity in the comparison.
A lower price does not by itself demonstrate poor quality, and a higher price does not establish a better outcome. Phased work can suit uncertain scope; clear deliverables support a fixed-scope comparison. Before engagement, resolve assumptions, exclusions, change approval and the handover arrangements that apply if the relationship ends.
| Area | Evidence to request | Decision question |
|---|---|---|
| Experience | Actual role and a comparable difficulty | Has this problem been addressed before? |
| Discovery | Scope, risks and acceptance document | Are uncertain items visible? |
| Quality | Test coverage and defect process | How are critical tasks verified? |
| Ownership | Account and handover inventory | Can another team continue the work? |
| Maintenance | Capacity and response terms | Who owns responsibility after release? |
BEFORE YOU DECIDE
Frequently asked questions
Should I choose a freelancer or an agency?
One specialist may suit a narrow, defined task. A product needing several disciplines, release work and continuity requires coordination capacity. Compare coverage and backup arrangements rather than the supplier’s label.
Is the cheapest proposal risky?
Price alone is not evidence of risk. Compare scope, quality, account control and maintenance together. Include the internal capacity needed to perform excluded work.
Is experience in the same industry essential?
It is helpful, but comparable offline, device or permission challenges may matter more. Examine the supplier’s actual contribution to a reference instead of its brand alone.
Can the agency own the store accounts?
Plan sustainable business control at the start. Check account type, provider requirements and user roles. Transferring an app between legal accounts can have separate conditions; it is not simply a password handover.
Is source-code delivery enough?
Setup, testing, release, infrastructure and operating instructions also matter. An authorised receiving team preparing a working candidate from the documentation is a stronger handover check than receiving files.
Are maintenance and warranty identical?
Terms vary by proposal. Define which defects, period and changes are covered. Compare response targets separately from resolution commitments, and make the treatment of new features explicit.
LET’S DEFINE THE SCOPE
Assess the proposal against a defined scope
Share the main user task, existing systems and supplier proposals. We can clarify scope, delivery risks and handover requirements.
Review my app scope