How to choose an app development vendor in São Paulo: a practical checklist for the first meeting

Hiring the wrong vendor for app development in São Paulo often looks like a leak that appears only after a storm: the project continues, budget grows, deadlines slide and maintenance becomes a bigger issue than initial delivery. This guide skips promotion and delivers, right away, the list of questions you should use in your first meeting to avoid surprises and test within 30 minutes whether a supplier understands what matters.

The practical thesis: vendor selection is resolved through three explicit decisions — commercial (how you pay and what guarantees you have), technical (how the work is produced and validated) and operational (how it will be sustained and governed after delivery). If any of these three is weak, cost and schedule risk increase. Below you will find criteria, trade-offs and a ready checklist to include in an RFP or use in the first meeting.

Which commercial questions filter vendors in the first meeting?

Start with the pricing model — ask them to explain how they would charge under time & material and fixed price with examples applied to your scope. Then question guarantees and scope limits: what guarantees do they offer against defects, how do they handle changes, and how are variations priced? Also ask about transition clauses: how will artifacts, code and documentation be transferred at contract end if needed?

Quick commercial checklist

• Proposed pricing model and applied examples to your scope.
• Change policy and estimated impact of scope variations.
• Guarantees (bug fixes, period and acceptance criteria).
• Transition terms and handover deliverables (documentation, scripts, repo access).
• Proposed SLA for production and support responsibilities.

What to ask in a technical proposal to compare vendors?

A comparable technical proposal is more than a list of languages. Request: high-level solution architecture, integration flows with existing systems, CI/CD pipelines, automated testing strategy and security plan. Ask for process evidence — artifacts such as pipeline templates, PR checklists, infrastructure-as-code scripts or examples of automated test reports. These items allow you to compare technical maturity beyond the visual portfolio.

Technical items to require in the RFP

• Architecture diagram and planned integration points.
• CI/CD description: tools, triggers and test coverage in the pipeline.
• Observability plan: logs, metrics and alerting; who operates and how incidents are routed.
• Testing strategy: unit, integration and end-to-end — when each runs.
• Security measures: vulnerability scanning, dependency management and secret handling policies.

How to evaluate sustainment capability and observability?

Sustainment is where projects make or lose money after delivery. Request an operational description: how the support team is organized (shifts, response and resolution SLAs), runbooks and incident handling process. For observability, ask for sample dashboards and alerting policies — not to check exact numbers, but to confirm practices exist rather than mere claims.

Important: differentiate what the proposal does and what the company commits to contractually. Observability described in a proposal does not replace SLA clauses and transfer processes. If sustainment is critical, require a transition plan with rollback tests.

Operational checklist for the first meeting

• Description of the sustainment team and support levels.
• Runbook templates and incident escalation flow.
• Examples of dashboards and types of alerts configured.
• Policy for updates and scheduled maintenance.

What evidence to request to validate delivery capability?

Avoid relying solely on visual portfolio pieces. Request: a functional prototype or technical demo, delivery artifacts (test plans, QA reports), and evidence of processes (backlog templates, definition of done/acceptance). References can help, but prefer process documentation: how they estimate, who reviews code and how they enforce continuous quality.

What is not sufficient evidence

• A client list without context about scope and the vendor's role.
• Demos full of visual elements without access to pipelines or scripts.

Contract models and practical attention points

In contracts, focus on code and IP ownership, operational SLAs, transition clauses and acceptance criteria. Code ownership is more than repo access: include history, build instructions and infrastructure-as-code. For SLAs, detail response and resolution times by severity; for transition, define minimum deliverables and acceptance tests to verify knowledge transfer.

Common trade-offs

Fixed price reduces cost variability but requires a very clear scope and increases change risk; time & material offers flexibility but requires governance and checkpoints to control spending. Be explicit about which risk your organization prefers to accept and include contractual alignment mechanisms — prioritization cadences, demos and quality checkpoints.

Documents the buyer should bring to the first meeting

Bring these items to make the meeting productive and proposals comparable: product vision, list of required integrations, critical user flows, estimated volumes (usage, transactions, concurrent users), technology constraints, priority business rules and decision-maker contacts. Add sample integration data where possible and a simple diagram of your current ecosystem.

• Vision and objectives of the app.
• Required integrations and API examples.
• Traffic estimates and expected peaks.
• Applicable compliance or security requirements.

How to structure a short PoC and signals of success

A short PoC should focus on the principal risk — a critical integration, API performance or a key user flow — with minimal deliverables and clear acceptance criteria. Success signals are not only "it works": they include verifiable deliveries such as an end-to-end CI/CD pipeline execution, integration tests with real systems, and an initial observability report (logs and alerts configured) you can review.

Frequently asked questions

How long does a custom app project usually take?

Timing varies with scope and constraints; rather than a single deadline, ask the vendor for a roadmap with milestones and dependencies — this reveals planning maturity.

How to compare proposals with different pricing models?

Expose the same reference scope and request scenarios: an estimate in T&M and a fixed proposal for the same scope. Compare what is included regarding guarantees, tests and documentation, and evaluate contractual control mechanisms (checkpoints, acceptance and quality metrics).

What about code ownership and IP?

Ensure contracts define code transfer, access to history, build documentation and infrastructure-as-code. Also specify responsibilities for third-party libraries and licensing.

Evaluating portfolio and delivery evidence

Ask for technical demonstrations that show pipelines, scripts and, when possible, a walkthrough of a repository. Prefer vendors that show process artifacts beyond screens. Validate consistency between the technical proposal and demonstrated artifacts.

If you want to use this checklist as a base and schedule a local technical meeting, MVX can help review your RFP and run an alignment session. Schedule a local technical meeting — contact MVX. To learn about services that combine delivery and ongoing support, see Software sob medida, Aplicativos mobile and Sustentação & Evolução.

This guide delivered questions and criteria you can use in the first meeting. Use the checklist, compare artifacts and require clear sustainment plans before signing.