A portfolio screenshot leaves a lot unanswered. During an app-developer interview, I would ask to follow one user action through to the saved record and then see how the developer changes it.
A polished portfolio is useful evidence of presentation. The hiring decision also needs evidence that the developer can turn your business requirements into software someone can maintain. You can examine that without conducting a programming-language quiz.
Bring a bounded problem to the discussion
Describe one workflow from your business. Explain the people involved, the starting information, and the result you need. Ask the candidate what they would clarify before estimating.
Good questions should expose decisions: who owns a record, who approves an action, which system is authoritative, and what happens when an integration is unavailable. A candidate who offers an immediate fixed scope without discussing those details may be estimating a different application from the one you expect.
Ask for an example of an acceptance check. For a request tracker, that might include creating a request, reloading it, changing its status, and confirming that another user cannot read it. The proposed test should fit the actual business rule.
Review implementation and handover
Request a demonstration the candidate has permission to share. Ask how a change reaches users, how failures are investigated, and what another developer would need to take over. Respect confidentiality; an anonymized example or a small paid evaluation can provide evidence without exposing client material.
Clarify ownership of source, data, credentials, dependencies, and documentation in the agreement. Identify recurring services and who controls their accounts. A working application is easier to maintain when those responsibilities are explicit.
AI assistance should be part of this discussion. Ask how generated changes are reviewed and tested. The important evidence is the developer's ability to explain and verify the result.
Make the evaluation milestone resemble the project
A useful paid milestone for a request app could include intake, saving, an owner assignment, and a simple status view. Specify what happens when a required field is absent. Add an access check if the full project depends on role-based records. Keep the milestone small enough that both sides understand what will be delivered.
During the handover, ask the developer to change a field or rule and show what needs updating. Ask another qualified person to follow the setup or operating notes. This reveals whether the implementation can be understood beyond the person who created it.
Discuss assumptions before judging the result. An unclear approval policy is a product decision you owe the developer. A route that returns another user's private request despite a clear rule is an implementation issue. Distinguishing those helps both sides resolve the right problem.
The milestone should leave you with a demonstrable workflow, the relevant implementation, test results and a list of remaining work. It can support a decision to continue without requiring either party to pretend the entire application is already finished.
Choose the working arrangement for the workload
A freelancer can suit a bounded delivery with clear acceptance criteria. An ongoing product may need a continuing owner for priorities, operations, and changes. An agency can provide several specialties, but you should know who is accountable for the complete application.
Separate roles from headcount. Someone needs to make product decisions, implement the system, review security and access, test it, and own support. The arrangement should explain how each responsibility is covered.
If the team uses OBTO, review the actual application artifacts and behavior together. Our consulting-platform page provides context for that delivery model. Using a platform does not remove the need for accountable technical judgment.
Agree on a small, paid milestone with a demonstrable result, a clear handover, and written acceptance checks before committing to a larger engagement.