Decide Whether You Need Native, Cross-Platform, or a PWA
Begin with the job users need to complete, not a requirement that the supplier use one framework. A customer portal used occasionally through shared links may suit a progressive web app, or PWA. A product dependent on sophisticated camera processing or extensive device interaction may justify native development. Cross-platform development becomes attractive when iOS and Android need substantially similar journeys, while still allowing platform-specific implementation where necessary.
Ask each bidder to compare those approaches against your actual requirements: offline behavior, notifications, background activity, discoverability, installation, and hardware access. Browser capabilities vary by operating system and browser, so a PWA proposal needs a concrete support matrix rather than a blanket promise of app equivalence. Native development also deserves scrutiny; separate applications can create duplicated delivery work without automatically improving the experience users actually receive.
Make the architecture recommendation a short decision document. It should identify the preferred approach, rejected alternatives, assumptions, and conditions that could change the recommendation. For example, an illustrative inspection app might prioritize offline photo capture and upload recovery over visual uniformity. A vendor willing to challenge your initial framework preference, with evidence tied to those requirements, is providing more useful advice than one selling a predetermined stack.
Evaluate Flutter and React Native Without Picking a Universal Winner
Flutter and React Native can both support serious business applications, but their tradeoffs matter differently across teams. Flutter uses Dart and its own widget system, making Dart expertise and familiarity with Flutter rendering important evaluation points. React Native uses React with JavaScript or TypeScript and platform integrations. Existing React experience can help, but web development experience alone does not establish competence in mobile performance, permissions, or release management.
Google’s Flutter documentation explains options for integrating with platform functionality, including platform channels and plugins. React Native’s documentation describes platform-specific files and the Platform module for handling differences. These capabilities undermine a common sales shortcut: that selecting a cross-platform framework removes the need for native knowledge. Ask who handles platform-specific work, how that person participates in delivery, and what happens when an external package cannot meet requirements.
Compare the proposed team and dependency plan rather than framework popularity. A Flutter proposal should explain Dart staffing, plugin selection, and custom integration ownership. A React Native proposal should explain native module compatibility and the consequences of its chosen development tooling. For either option, request a prototype of your riskiest interaction. A simple branded screen demonstrates presentation skills; it does not validate the architecture you are buying.
Test Native Integrations Before Committing to the Full Build
Integration risk often hides behind a short feature label. Bluetooth pairing, biometric sign-in, subscription billing, maps, and document scanning can each involve operating-system behavior, permissions, vendor SDKs, and edge cases. Request an integration inventory that distinguishes standard framework functionality, maintained community packages, commercial dependencies, and custom native code. Each entry should name the owner, supported platforms, licensing considerations, and fallback plan if the dependency becomes unsuitable during delivery.
Turn the most uncertain integration into a bounded discovery task before approving the full implementation. The output should be a working build on relevant devices, not a slide claiming feasibility. Ask the team to demonstrate denied permissions, revoked permissions, cancellation, device unavailability, and interrupted connections. For a payment workflow, verify what happens when the app receives an uncertain response instead of treating every transaction as a clean success.
Also examine how the mobile app interacts with your backend. Clarify API ownership, versioning, authentication, retry behavior, and observability when something fails outside the interface. A supplier cannot responsibly guarantee a seamless integration without understanding the systems it depends on. Keep prototype conclusions in the delivery plan, including unresolved constraints. This prevents a successful narrow demonstration from being stretched into an unsupported promise about the entire product later.
Treat Code Sharing as an Engineering Choice, Not a Sales Metric
A high code-sharing percentage sounds economical, but it is a weak purchasing criterion without definitions. Vendors may count generated files, tests, or backend code differently. More importantly, forcing every interaction into shared components can make navigation awkward or accessibility harder. Ask what will be shared across business logic, networking, presentation, and tests, and where separate platform behavior is intentional. The answer should reflect product needs rather than marketing arithmetic.
Request a small architecture walkthrough with the engineer who would lead your project. Have them explain how a new feature moves from an API response to a screen, where platform differences live, and how failures are handled. You do not need to inspect every line. You need evidence that the structure is understandable, testable, and transferable to another competent team without relying on one developer’s private knowledge forever.
Connect architectural choices to change requests you can imagine. Ask how the team would add a second payment provider, alter onboarding on one platform, or support a new device permission. Strong answers identify affected components and testing consequences without pretending to know exact effort prematurely. Require documentation of major decisions and exceptions. A slightly less shared implementation may be the better purchase if it keeps future changes isolated and predictable.
Delivery approaches: fit and evidence to request
| Approach | Potential fit | Evidence to request |
|---|---|---|
| Native iOS and Android | Platform-specific experiences or demanding device interactions. | Demonstrated platform expertise and a plan for coordinating separate implementations. |
| Flutter | Shared application delivery with a Flutter-based interface. | Device integration prototype and plugin ownership plan. Flutter documentation: https://docs.flutter.dev/platform-integration |
| React Native | Shared React-based delivery with deliberate platform adaptations. | Native dependency compatibility and platform-specific implementation plan. React Native documentation: https://reactnative.dev/docs/platform-specific-code |
| Progressive web app | Browser-accessible journeys where installation is not essential. | Target-browser tests for required capabilities, offline behavior, and installation expectations. |
Demand Real-Device QA for Business-Critical Journeys
Simulator screenshots are not sufficient evidence that an application works for customers. Physical devices expose issues involving memory pressure, keyboards, cameras, battery constraints, connectivity, and operating-system permissions. Agree on a device matrix based on your audience and supported versions, including an older or lower-resource device where relevant. The vendor should explain how it selects coverage rather than offering an impressive but irrelevant list of devices it supposedly tests.
Build the test plan around completed journeys and disrupted journeys. For account creation, test expired verification links and returning users as well as successful registration. For offline work, test conflicting updates and uploads interrupted by app termination. Establish expected behavior when connectivity changes mid-task. Evidence should show what was tested, on which device and version, what failed, and whether the fix was retested before the next release candidate.
Separate automated coverage from exploratory testing without treating either as optional decoration. Unit tests can protect business rules, while integration and end-to-end tests address interactions across components. Human testing remains valuable for confusing flows and device behavior. Ask who owns release approval, what defects block launch, and how crash reports become actionable tickets. Avoid accepting a generic assurance that the application will be fully tested before publication begins.
Keep App Store Accounts and Operational Assets Under Your Control
Ownership is operational, not just a sentence stating that you own the finished app. Your business should ordinarily control its Apple and Google publishing accounts, with the supplier receiving appropriate delegated access. Clarify who manages signing materials, subscription products, store listings, privacy disclosures, and review responses. A vendor-owned account can complicate the relationship when you change suppliers, restructure the business, or need an urgent release without the original team.
Apply the same discipline to source repositories, backend infrastructure, analytics, crash reporting, domain names, and third-party service accounts. Access should match responsibilities, and sensitive credentials should not sit in shared chat messages or source files. Ask for a documented process to revoke supplier access and rotate secrets at handover. Contractual ownership language should be reviewed by your advisers; a technical access plan is a separate, equally practical requirement.
Define handover before development starts. It should include build instructions, environment configuration guidance, dependency records, release procedures, and known limitations. Test whether someone other than the original developer can produce a release candidate using those materials. Also distinguish submission assistance from guaranteed approval: app stores make their own review decisions. A credible partner can explain its preparation and response process without promising an outcome it does not control.
Make Accessibility Part of Acceptance, Not a Final Audit
Accessibility affects whether people can complete your core journeys, not merely whether a screen passes a visual review. Include screen-reader navigation, meaningful control labels, text scaling, focus behavior, contrast, and alternatives to gesture-only actions in the specification. Cross-platform components do not make these concerns disappear. Custom controls deserve particular attention because their appearance can conceal missing semantics or interactions that work only through precise tapping on a small target.
Ask the vendor to demonstrate representative tasks using VoiceOver on iOS and TalkBack on Android. Watch whether the reading order makes sense, validation errors are announced, and focus returns to a useful place after dialogs close. Increase system text size and check whether essential actions remain available. Include loading, empty, and error states; accessibility often breaks in those moments even when the main screen appears carefully designed initially.
Put these checks into design reviews and sprint acceptance so defects are corrected while components remain inexpensive to change. Assign responsibility across design, development, and QA rather than leaving accessibility with one reviewer near launch. Where your sector or contracts create specific obligations, obtain qualified advice on applicable requirements. A development proposal should specify testing and remediation commitments, not promise universal legal compliance through a framework, plugin, or automated scanner.
Evaluate Framework Upgrades and Maintenance Before Launch
The first release begins an operating commitment. Framework versions, operating systems, store requirements, SDKs, and third-party packages continue changing after launch. Ask each company to describe its upgrade process and the maintenance scope included in its proposal. Distinguish monitoring, investigation, compatibility work, defect fixes, and new features. Without that separation, an apparently comprehensive support arrangement can become a sequence of disputes about what counts as ordinary maintenance work.
Request a dependency policy covering version tracking, abandoned packages, security updates, and commercial SDK renewals. The team should explain how it tests upgrades in a separate environment and schedules regression testing before release. Avoid a blanket instruction to stay permanently on the newest version or never upgrade a stable app. Both approaches ignore context. The useful question is how the vendor evaluates urgency, compatibility, and the cost of delay.
Compare commercial proposals over an agreed planning horizon, not only the initial build. Include discovery, design, backend work, testing, release support, hosting assumptions, and ongoing maintenance responsibilities. Ask what triggers a change request and who approves it. Require estimates to state exclusions and uncertainty explicitly. This creates a more honest comparison than rewarding the lowest headline proposal and discovering later that essential operational work was outside the quoted scope.
Use a Weighted Scorecard to Compare the Actual Delivery Teams
A scorecard turns vendor selection into a repeatable decision rather than a contest between persuasive presentations. As an illustrative model, allocate 25 points to product and architecture fit, 20 to integration evidence, 20 to QA and accessibility, 15 to ownership and handover, 10 to maintenance, and 10 to delivery transparency. Adjust those weights before proposals arrive so an attractive presentation does not quietly redefine what matters to your business.
Score evidence rather than claims. A relevant working prototype should earn more confidence than a technology logo, and an explained test report should outweigh an unsupported promise of quality. Record unanswered questions beside each rating. Apply minimum thresholds to critical requirements: strong visual design should not compensate for refusing business-controlled publishing accounts. If an essential integration remains unproven, treat that as a discovery condition rather than hiding it inside an average.
Meet the proposed technical lead and delivery manager, not only the sales team. Clarify allocation, subcontracting, time-zone overlap, escalation routes, and replacement procedures. Ask for a redacted example of a decision log or defect report if available, without requesting another client’s confidential material. References can support evaluation, but your requirements still need direct proof. Document why the selected company fits your product and which risks remain accepted or unresolved.
Tie Demo Acceptance to Observable Outcomes
Before signing, agree on how completed work will be demonstrated and accepted. Replace vague milestones such as checkout finished with observable conditions: a user can submit an order, recover from a declined payment, and reopen the app without creating a duplicate transaction. Specify the environment, device coverage, test data, and expected results. Acceptance should assess what the business can use, not simply whether a developer has merged code into a repository.
Run demos from a versioned build distributed through an agreed testing process. Have your product owner perform selected tasks rather than only watching a rehearsed screen share. Record passed criteria, defects, and decisions, then give the team a defined correction and retest process. Keep new feature requests separate from failed acceptance criteria. This protects both parties: the buyer gets evidence, and the supplier is not judged against requirements introduced afterward.
Finish selection with a readiness review covering architecture assumptions, integration findings, account access, test coverage, support responsibilities, and unresolved dependencies. If uncertainty is substantial, commission a bounded discovery phase instead of committing immediately to the entire build. The right cross-platform partner is not necessarily the one offering the broadest promises. It is the team that makes constraints visible, demonstrates difficult behavior early, and leaves your business able to operate the product.
