Two development proposals can describe the same product and promise very different things. One prices the screens. Another includes the integrations, administration tools and release work needed to operate them. A third assumes your team will supply those parts. Comparing the totals before resolving those assumptions can leave you choosing between different projects.
When evaluating a custom software development company, ask each supplier to explain the same business journey, delivery evidence and handover. The aim is a proposal you can test as work progresses, with a clear account of what remains your responsibility.
Start with a complete business journey
Choose one important task and follow it from the first user action to its operational result. For a mobile product, that might mean creating an account, recording an activity, synchronising it and showing the correct information to an administrator. For an internal application, it might be receiving a request, checking permissions, assigning work and producing a report.
Describe who does each step, which existing system supplies the information and how completion is confirmed. Give every shortlisted supplier that same description. Ask them to identify assumptions and exclusions against it. A screen list becomes much more useful when it explains the business behaviour behind each screen.
Check whether the proposal covers the whole product
First-hand observation
Our work on Ritualize’s web, mobile and organisational reporting illustrates why these boundaries matter. Kitek developed participant-facing applications alongside reporting for the organisations running wellbeing programmes. A participant completing an activity and a customer reviewing engagement need different views of the same broader product. A mobile-only brief would leave important questions about definitions, access and reporting unresolved.
The integration boundary can be narrower. For ePark’s parking application, Kitek developed the mobile application using the API supplied for the existing web portal. That distinction matters when assessing a proposal: using an available API and building or replacing one are different commitments. Ask who owns changes when the supplied interface cannot support a required journey.
Make mobile behaviour explicit
Custom mobile app development services need a scope for the conditions people will actually encounter. Ask which devices and operating-system versions will be supported, how permissions and notifications will work, and what happens if the app closes during a task. Identify whether users need to read information, enter information or do both without a connection.
Google’s offline-first architecture guidance explains that local and network data may need synchronising and that conflict handling depends on the application’s requirements. For a buyer, the practical question is which actions the supplier will demonstrate offline, and what the user sees when synchronisation fails.
These are product decisions, rather than a request for a particular framework. A proposal should turn them into agreed behaviour and tests. Avoid accepting an undefined promise that the app will simply “work offline.”
Compare evidence against the same questions
| Area | Ask the supplier to specify | Evidence to review |
|---|---|---|
| Scope | Included journeys, exclusions and customer dependencies | A demonstrable end-to-end scenario |
| Integration | Existing interfaces, missing capabilities and responsibility for changes | A test against the agreed system boundary |
| Mobile delivery | Device coverage, permissions, connectivity and release responsibilities | Results from representative devices and failure conditions |
| Acceptance | Who approves each outcome and how defects are handled | Recorded results against agreed examples |
| Ownership | Code, accounts, documentation and third-party dependencies | A handover package your team can access |
| Operation | Monitoring, incident response, updates and support boundaries | An operating plan with named responsibilities |
Include failures in the acceptance examples
Consider a hypothetical field-service app that records a completed visit. The normal demonstration saves the record and shows it in an office report. A useful acceptance exercise also interrupts the connection, repeats a submission and checks what happens when the user cannot access that customer. Agree the expected outcome for each case before comparing the suppliers’ answers.
This does not require writing a technical specification for every possible failure. Start with the situations that could lose work, create duplicate work or show information to the wrong person. Ask how the team will make those outcomes visible and recoverable.
Our continuing work on My Safety Buddy’s existing web and mobile platform includes mobile verification and permission onboarding as well as activity and login reporting. Those are examples of delivery extending beyond a new feature’s main screen. Use your own users and operating conditions to decide the acceptance tests.
Resolve security, ownership and ongoing costs
Ask how the supplier manages access, handles vulnerabilities and provides information needed to investigate an incident. CISA’s Secure by Demand guidance announcement encourages buyers to assess whether security is part of the supplier’s development practices and procurement process. Put the relevant questions into the proposal discussion before delivery begins.
Also request a list of the accounts, licences and recurring services the product needs. Confirm who controls the source repository, infrastructure and app-store accounts, what your team receives at handover and how another team could continue the work. Have the appropriate adviser review the contractual ownership terms.
Separate implementation fees from hosting, third-party usage, maintenance and future changes. Ask what the support arrangement covers, when a change becomes new development and how communication will work across time zones. Application support and maintenance should have an agreed scope of its own.
Use discovery to resolve the important unknowns
If an integration or business rule remains uncertain, ask the supplier to propose a focused discovery step with a defined output. That output might be a tested interface, a clarified journey or a revised delivery scope. It should help you make the next decision, rather than merely generate another presentation.
Compare the remaining uncertainty as carefully as the quoted price. A clear exclusion may be manageable. An important dependency that neither proposal acknowledges is harder to plan around.
Kitek’s custom software development services cover web and mobile delivery connected to existing business systems. Bring us the proposals, critical journeys and known constraints, and we can help identify which questions need answering before the build starts. Kitek is based in Melbourne and works with businesses worldwide.
If the proposal includes an AI application, workflow or agent, use our AI development proposal checklist to review its deliverables and acceptance evidence.