- Write the product decision
- Compare evidence and scope
- Review a working milestone
- Confirm ownership and support
What should you prepare before contacting developers?
Start with the user and the task. Describe who will use the app, what they are trying to accomplish and what happens today without it. A request such as build an app for our customers leaves too many decisions hidden. A more useful brief explains that existing customers need to view a job status and request a change, while staff need to review that request before anything is updated.
Add the operating constraints you already know: intended platforms, account types, existing data sources, payment needs, offline expectations and the person who will approve product decisions. Separate confirmed requirements from ideas. If you are unsure whether an app is the right format, state that uncertainty. A developer should be able to discuss whether a website, portal or smaller workflow could answer the need before estimating a full mobile product.
How do you compare relevant experience without relying on logos?
Ask the candidate to explain one piece of work relevant to the difficult part of your app. If your product depends on offline work, a polished shopping interface does not establish that experience. If it handles several user roles, ask how access was designed and tested. The useful evidence is the reasoning, the person's actual contribution and what can be demonstrated with permission.
Respect confidentiality. A candidate may be unable to show a private client system, but can still describe the problem, tradeoffs and role without revealing protected information. Do not treat an employer logo or an app-store listing as proof that the person built the whole product. Ask what they owned, who else was involved and whether the people proposed for your project have the relevant skills. Keep notes about evidence rather than turning impressions into an unsupported score.
Which questions reveal the team's delivery approach?
Ask how a requirement moves from discussion to a working release. Who resolves unclear behavior? How are design decisions recorded? When will you see working software? Who checks changes before they reach users? The answers should connect into a coherent process rather than a list of tools. A small team can have a clear process; a large team can still leave responsibilities ambiguous.
Discuss changes before they occur. If a new requirement appears after work starts, how will the team describe its effect on scope, timing and cost? A useful response separates a defect against agreed behavior from a new product decision. The objective is not to eliminate change but to make it visible. You should be able to understand what has been accepted, what remains uncertain and what decision is needed next.
What does a useful first milestone look like?
A good first milestone resolves a real uncertainty and produces something you can inspect. For some products that might be a tested prototype of a difficult interaction. For others it could be a small working path through the app and its back end. The milestone should be bounded enough that both sides know what is included and how it will be reviewed. Avoid a milestone defined only as a percentage complete.
Here is an original hypothetical example. A field-service company wants an app for technicians to update job status. The first milestone covers one technician signing in, viewing an assigned job, submitting a status change and seeing a clear result after a failed connection. An office user can see the accepted update. Payments, customer messaging and route planning are excluded from this milestone. This is a planning example, not a Dappr project or a claim that every app should start this way.
The review asks whether the specified roles and failure states work, not whether the app resembles a finished product. The company can learn whether the workflow fits operations and whether the team communicates uncertainty well. If the hardest question is different, choose a different milestone. The value comes from testing the relevant risk, not copying this example's feature set.
How should developers explain testing?
Ask for testing that matches the important behavior. A passing automated check does not prove that a person can complete the task on a supported device. React Native's official testing guidance distinguishes several levels of testing and notes that JavaScript component tests do not cover all native platform behavior. That is a useful reason to ask what is checked automatically, on devices and through complete user journeys.
Use concrete examples from your product. What happens if permission is denied, a session expires, the network fails or two people edit the same record? Which behaviors are important enough to prevent a release when they fail? You do not need to dictate every testing tool, but you should understand the coverage and its limits. A claim that the team tests everything is less useful than a clear explanation of the critical paths and known gaps.
What should you ask about security and data?
Identify what information the product needs, who may access it and which actions different roles can perform. Ask the team how those rules are enforced and reviewed. A hidden button is not the same as authorization. The back end must make the relevant access decision, and the product needs deliberate handling for accounts, secrets, logs and data retention. The exact requirements depend on the system and its risks.
OWASP's Application Security Verification Standard provides a structured basis for discussing web-application security requirements and verification. It is a reference for a scoped conversation, not a certificate that a product is secure. Ask which controls and verification activities are included, who performs them and what evidence will be available. Products with specialized regulatory or sensitive-data requirements need appropriately qualified review; a general app proposal should not silently assume that expertise.
Who should control the accounts and release assets?
Clarify ownership and access before the project becomes dependent on one person's account. Discuss the source repository, developer accounts, hosting, domains, service subscriptions, design files and build configuration. The business should understand what it owns, what is licensed and which third-party services continue to cost money. Record who can administer access and what happens when a team member leaves.
For a store-distributed app, submission is a separate responsibility from writing code. Apple provides a review process with requirements that developers must prepare for. Ask who prepares the submission materials, handles review questions and verifies the release. Do not treat a proposed launch date as a guarantee of store approval. The handover should leave a clear path for future updates, including another qualified team if the working relationship changes.
How do you compare proposals with different prices?
Normalize the scope before comparing totals. One proposal may include product discovery, design, back-end work and release support while another assumes you will provide them. Look for explicit assumptions about platforms, integrations, content, testing, data migration and maintenance. A lower total can be appropriate for a smaller scope, but it is not comparable until those differences are visible.
Ask how uncertain work is handled and what evidence would allow the estimate to become more reliable. Avoid demanding false precision from an incomplete brief. A bounded discovery or first milestone can produce better information for the next decision. The proposal should also identify what is not included in a useful, specific way, so omitted responsibilities do not appear for the first time near release.
What should happen after the first release?
An app needs an operating owner. Discuss how issues are reported, who decides their priority and how updates are tested and released. Clarify support hours, response expectations and the difference between maintenance and new features. Platform changes, dependencies and third-party services can create ongoing work even when the product roadmap is quiet.
Dappr offers app and custom development, including iOS, Android, React Native and AI-assisted work, with the actual project approach set through scope. Because Dappr is a provider, this guide reflects a provider's perspective rather than an independent ranking of developers. Use the same questions with every candidate, including us, and choose on the evidence relevant to your product.
Questions before you begin
Should I hire one developer or a team?
Choose based on the work and the responsibilities that must be covered. A smaller project may suit one experienced developer with appropriate support, while a product needing design, back-end, mobile and release work may require several roles. Make those responsibilities explicit.
Does using AI remove the need to assess developer skill?
No. Someone still needs to understand the requirements, review generated work, verify behavior and maintain the product. Ask how the team checks AI-assisted output rather than treating the tool itself as evidence of quality.