10 Questions to Ask Before Hiring a Software Company

The difference between a clean 12-week MVP and a $250k write-off usually shows up in the first two meetings with a vendor — if you know what to ask. These are the questions to ask before hiring a software development company, written for US founders and product leads shortlisting two to four agencies. Each one includes what a strong answer sounds like, the red flags that should kill the deal, and one follow-up probe to push past the sales pitch.

Print it. Share it with your CFO or outside counsel. Bring it to the pitch.

Before the questions: know what you're actually hiring

Not every engagement calls for the same scrutiny. Three shapes dominate:

• Fixed-scope SOW (Statement of Work) — you want a discrete deliverable: an MVP, a migration, an integration. Price, scope, and timeline are locked. Change orders adjust the contract.
• Dedicated squad (retainer) — a named team of 3–6 people working your backlog for 3–12+ months. Predictable monthly burn, flexible scope.
• Time & materials (T&M) — hourly rates against a loose backlog. Max flexibility, least budget predictability. Best for discovery or evolving product.

Your questions shift with the shape. On a fixed SOW, press on scope definition and change management. On a dedicated squad, press on team composition, retention, and ramp-down rights. On T&M, press on velocity reporting and a weekly/monthly cap. If the vendor can't articulate which model they're pitching you and why, that's the first red flag of the engagement.

A few procurement-side essentials every shape needs, regardless of the above:

• MSA (Master Services Agreement) — the umbrella legal terms. Signed once, governs every SOW underneath.
• SOW — deliverables, acceptance criteria, timeline, fee schedule, assumptions.
• NDA — mutual, signed before the first technical deep-dive.
• IP assignment clause — explicit transfer of all work product to you on payment.
• Termination for convenience — typically 30 days' notice, with pro-rated fees and source code handoff.
• Warranty period — 60–90 days post-delivery for defect fixes at no charge.

If you need a primer on scoping timelines and budgets before the RFP, our 2026 cost guide and realistic timeline guide give you the baselines most US buyers use. Now to the ten questions.

1. Can we see three case studies from clients at our stage — and speak with two of them?

Portfolio pages are marketing. Reference calls are evidence.

What a strong answer sounds like: "Yes. Within 48 hours we'll introduce you to three clients — one who shipped an MVP in 10–14 weeks, one mid-engagement now, and one we worked with for more than a year. We'll cover fintech, SaaS, and marketplace verticals so you can pick the closest fit." The vendor offers named founders/PMs, not vague titles. Case studies include team size, duration, spend band, scope changes that happened, and at least one metric beyond "launched" (activation, retention, throughput, uptime, NPS).

Red flags: Only written testimonials. Logos without case studies. Shops that talk about "clients we can't disclose" for every reference. Portfolios padded with logos the team contributed one feature to five years ago.

Follow-up probe: "What's a project that went sideways — and what did you change as a result?" A vendor that can't name a failure has either never shipped enough to have one, or they're lying. Either is disqualifying.

2. Who exactly is on my squad — names, seniority, allocation, and will any of them be shared?

The classic bait-and-switch: senior architects show up to the pitch, mid-level and juniors show up to the standup. It's not always malicious — utilization pressure is real — but it's your product, so you set the rule.

What a strong answer sounds like: Named engineers with LinkedIn profiles, titles (Staff, Senior, Mid), years at the firm, and % allocation to your squad. For a 12-week MVP, a typical shape is 1 tech lead at 25–50%, 2 senior full-stack engineers at 100%, 1 designer at 30–50%, 1 QA at 30–50%, and a PM/delivery lead at 20–30%. Any shared resources are disclosed upfront with rationale.

Red flags: "We'll assign the team after signing." Allocations that don't add up to a shippable squad. More than two people under 30% allocation (context-switching tax will eat your timeline). Refusal to name the tech lead before contract.

Follow-up probe: "If the tech lead leaves during our engagement, what's the handover protocol and who's the named backup today?" Turnover happens. A vendor with a real bench has a real answer.

3. What's the communication cadence, time zone overlap, and escalation path?

This is where nearshore shines over pure offshore, and where "we're flexible" is the wrong answer.

What a strong answer sounds like: A concrete rhythm — for example, async Slack during business hours with a 2-hour response SLA, 15-minute daily standup at a fixed US time, 30-minute Monday weekly review, 45-minute Friday sprint demo. A shared Linear/Jira/GitHub project with client access. A named delivery lead as your single point of contact, and a clear escalation path (PM → Delivery Director → Principal) with 24-hour ack on written escalations. For a nearshore partner in Brazil, expect 1–3 hours of offset from US time zones — roughly 6 hours of live overlap with the West Coast and 8+ with the East Coast.

Red flags: "Email is fine." No written SLA on responsiveness. Time zones that leave less than 4 hours of overlap with your core hours. A tech lead who can't join the kickoff live. Vendors hiding behind an account manager who translates every technical question for an offshore team.

Follow-up probe: "Show me a live standup recording or a redacted sprint retro from a current client." The artifacts tell you more than the pitch.

4. What's your pricing model, and what's the blended rate?

US on-shore blended rates typically run $140–$225/hr. Eastern European nearshore runs $55–$95/hr. Latin American nearshore (including Brazil) runs $45–$85/hr blended, depending on team mix and engagement size. Offshore India/Southeast Asia commodity shops quote $20–$40/hr — and you get what you pay for.

What a strong answer sounds like: Clear pricing shape tied to the engagement model. For fixed-scope SOW: total fee, payment schedule tied to milestones (typically 20–30% upfront, balance at named milestones with a final 10% on acceptance), and a spelled-out change order process. For dedicated squad: per-role monthly rates, ramp-up period, ramp-down notice, and role swap terms. For T&M: blended or per-role rates, weekly/monthly cap, and invoicing cadence. Vendor is transparent about which currency invoices are issued in — USD wire is standard for Brazilian partners — and whether the vendor is set up to issue you a W-8BEN-E (foreign entity certification for US tax withholding purposes) so your finance team can properly 1099 or withhold as needed.

Red flags: Quotes well below the nearshore floor (under $40/hr blended) usually mean a staffing-agency commodity shop with high turnover. Quotes above on-shore rates from a non-US entity. Vendors that refuse to break out rates by role or who won't commit to a change order process.

Follow-up probe: "Walk me through an invoice from a similar-sized client." Real invoices kill vague pricing in 30 seconds.

5. Who owns the source code, and when does IP transfer?

This is the question that sinks the most exits and M&A diligence processes. Get it right before kickoff.

What a strong answer sounds like: "All work product — source code, designs, documentation, ML models, prompts — is a work made for hire assigned to you on invoice payment. The MSA has an explicit IP assignment clause plus a backup assignment for jurisdictions that don't recognize work-for-hire. Your GitHub org owns the repos from day one; we're added as contributors. Third-party OSS licenses are documented. No background IP is embedded without a disclosed license." For Brazilian nearshore partners specifically: Brazil's Software Law (Lei 9.609/1998) and Civil Code support work-for-hire assignment, and a well-drafted MSA under Delaware or New York law with a dispute-resolution clause (ICC or AAA arbitration in a neutral venue) is standard practice and fully enforceable.

Red flags: Repo lives in the vendor's GitHub org with no contractual obligation to transfer. "Assignment on final payment" without a partial-payment clawback protection. Any "exclusive support" clause that locks you into paying for maintenance to keep access. Background IP referenced but not itemized.

Follow-up probe: "Can we add a source code escrow clause with a third-party agent (Iron Mountain, NCC Group)?" For projects over ~$150k or anything mission-critical, escrow is cheap insurance. A serious vendor says yes.

6. What are your security practices — SOC 2, secrets management, pen testing, access controls?

If your product touches PII, payments, or health data, your vendor's security posture becomes your security posture the moment they clone the repo.

What a strong answer sounds like: Named practices, not slogans. SSO with MFA on all internal tools. Role-based access on your repos and cloud accounts with least-privilege, revoked within 24 hours of engagement end or staff change. Secrets in a vault (AWS Secrets Manager, Doppler, 1Password Business) — never in .env files in repos. Dependency scanning (Snyk, Dependabot) and SAST (Semgrep, SonarQube) on every PR. A pen test done annually or per-release on security-sensitive features, with a redacted report available. For regulated verticals: SOC 2 Type II (not just Type I) report available under NDA; HIPAA BAA for health data; PCI-DSS scope understanding for fintech; GDPR/CCPA data processing addendum in the MSA. Incident response plan with a 24-hour breach notification SLA to you.

Red flags: "We follow best practices" with no specifics. Secrets in .env committed to repos (ask to see a current repo's .gitignore). No SOC 2 and no roadmap to get one for an engagement over $200k. Shared admin accounts. Engineers using personal Gmail for client tooling.

Follow-up probe: "Send me your security questionnaire responses and your last pen test summary." If they can't produce either, the security posture is theoretical.

7. How does your QA and release process work?

"We test before we ship" is not a process. You want a named pipeline.

What a strong answer sounds like: A CI/CD pipeline with automated tests running on every PR (unit, integration, component). Coverage targets (typically 60–80% for business logic, not a vanity 95% everywhere). E2E tests on critical flows (Playwright, Cypress, Detox for mobile). Staging environment that mirrors production, with seeded data and feature flags. A written release checklist. Mobile releases managed through TestFlight and Play Console internal tracks before production. Rollback plan for every deploy. Observability stack (Sentry, Datadog, New Relic) wired before launch, not after the first outage. Named QA owner on the squad or a dedicated QA engineer for projects over ~$100k.

Red flags: Manual regression as the only QA strategy. No CI configured on the first code drop. Deploying on Fridays without feature flags. No observability until production breaks.

If you want to benchmark a vendor's testing maturity, our automated testing overview and software development best practices articles cover the floor a competent shop should clear.

Follow-up probe: "How do you handle a critical bug found in production at 10pm on a Sunday?" The answer reveals whether there's a real on-call process or just hope.

8. How do you handle scope change?

Scope change is inevitable. Unmanaged scope change is how fixed-price projects become lawsuits.

What a strong answer sounds like: A written change order process. For fixed-scope SOWs: any change outside the SOW assumptions requires a CO with impact analysis (hours, timeline, dependencies) approved by your delegated signer before work starts. Minor scope clarifications within the SOW assumptions are absorbed. A "change budget" of 10–15% is often baked into the SOW for small adjustments so you don't paperwork-tax every sprint. For dedicated squads: scope is fluid by design, and the ceremony is re-prioritization in the weekly review, not a legal process. For T&M: scope is whatever the backlog says, with a monthly cap protecting you from runaway spend.

Red flags: "Sure, we'll handle that" to every mid-project request without a CO — either they're eating the cost and cutting corners elsewhere, or you're getting surprise-billed at the end. No template CO in their standard contract pack. Engineers directly accepting scope changes from your team in Slack without the PM looping in.

Follow-up probe: "Show me a sample change order from a past project." Redacted is fine. The format is the tell.

9. What's the post-launch plan — warranty, handover, and ongoing support options?

A good vendor has an answer ready. A mediocre one improvises on the call.

What a strong answer sounds like: A 60–90 day warranty period post-acceptance covering defects traceable to the delivered work, at no additional charge. A structured handover: runbook (how to deploy, how to debug, how to roll back), architecture decision records (ADRs), API docs, infrastructure as code (Terraform/Pulumi) that you own, credentials rotation, and a 2–4 week knowledge transfer window if you're moving to an internal team. Clear support tier options: a retainer for bug fixes only, a retainer for bug fixes plus small enhancements, or a dedicated squad continuation. SLAs spelled out by severity (P0 1 hour, P1 4 hours, P2 next business day, etc.). Clarity that new features are cost-separated from warranty work.

Red flags: "Support is ad-hoc after launch." 30-day warranty or less. No runbook or ADRs planned. Handover treated as an afterthought. Retainer priced to lock you in rather than support you.

Follow-up probe: "Can we bring in an internal hire in month 6 and ramp you down to a part-time retainer?" The answer tells you whether the vendor is building your capability or their dependency.

10. Can we speak with two references from the last 18 months at companies our size or funding stage?

Yes, this overlaps with question 1 — and it's the single highest-signal check you'll make, which is why it's worth its own slot.

What a strong answer sounds like: Two introductions within a week. Named contacts (founder, CTO, product lead), not account managers. The vendor doesn't gatekeep the conversation. Ideally at least one reference is a post-engagement client — i.e., the contract is over — so you're not talking to someone mid-dependency.

Red flags: Only current clients, never ex-clients. Delays or "we'll get back to you" that stretch past a week. References that sound rehearsed.

Follow-up probe (to the reference, not the vendor): "Knowing what you know now, would you hire them again?" and "What did they miss — and how did they handle it when you flagged it?" The answers cut through vendor polish in under a minute.

Vendor red flags at a glance

Patterns to kill a shortlisted vendor on the spot:

• Blended rate under $40/hr for a nearshore vendor — you're buying a staffing agency, not a partner.
• Instant yes to every feature in scoping — they're selling, not engineering.
• No senior engineer on the kickoff call — the pitch team and the delivery team are different, and you'll only see the pitch team again at renewal.
• Refusal to allow source code escrow for an engagement over $150k.
• No SOC 2 Type II or HIPAA BAA for regulated data, and no roadmap to get there.
• Vague IP assignment — any language softer than "work made for hire assigned on payment" gets redlined or walked away from.
• No portfolio of shippable apps on public app stores — ask for App Store / Play Store IDs and tap them in the meeting.
• Asks you to write the SOW — the vendor should draft v1, you redline. Reversing it means they don't have a standard motion.

Side-by-side vendor scorecard

Copy this into a sheet. Weight the rows to your risk profile and score each vendor out of 5.

The nearshore-Brazil procurement angle

If you're evaluating a Brazilian partner alongside on-shore or eastern European vendors, here's what changes operationally:

• Time zones: São Paulo / Cuiabá run 1–3 hours ahead of US time zones year-round. You get 6–8 hours of live overlap with ET and PT — more than any other major offshore hub.
• English fluency: Senior engineers and delivery leads at reputable shops are comfortable in written and spoken English. Mid-level engineers vary — ask to meet the team and gauge it yourself.
• IP jurisdiction: A well-drafted MSA governed by New York or Delaware law with a mutual arbitration clause (ICC or AAA) is standard and enforceable. Brazilian courts recognize foreign arbitral awards under the New York Convention. Brazilian Software Law (Lei 9.609/1998) supports work-for-hire assignment on top of that.
• Tax and payments: A Brazilian LLC equivalent (Ltda. or S.A.) can issue you a W-8BEN-E certifying foreign status, which typically eliminates US withholding on services performed outside the US. Payment is via international wire in USD. Your vendor is neither a 1099 contractor nor a W-2 employee — it's a foreign corporate services provider, and the invoice lives in AP like any other overseas vendor.
• Cost: 30–60% savings vs US on-shore blended rates at comparable engineering quality for most B2B SaaS and mobile work. Not the 70%+ savings pitched by commodity offshore shops — and not the quality issues that come with them.

For a fuller look at the Brazilian market context, see our guide to the best software houses in Brazil, and if you're still deciding on the build-vs-outsource question, this outsourcing guide walks through the operating model tradeoffs.

A short contract checklist before you sign

1. MSA signed, governing law and venue agreed (typically Delaware, New York, or the vendor's home jurisdiction with an arbitration clause).
2. SOW with deliverables, acceptance criteria, timeline, milestones, fee schedule, assumptions, and change order process.
3. Mutual NDA executed before the first technical deep-dive.
4. IP assignment clause — explicit work-made-for-hire language plus backup assignment. Named repos and tooling owned by your org.
5. Warranty clause (60–90 days minimum).
6. Termination for convenience (30 days) with source code handoff and pro-rated fees.
7. DPA / GDPR-CCPA addendum if any user data flows through the vendor.
8. Security exhibit — SOC 2 reference, access controls, breach notification SLA.
9. Insurance — E&O and cyber liability coverage appropriate to engagement size.
10. Source code escrow for engagements over $150k or mission-critical systems.

Common US buyer mistakes (avoid these)

• Hiring by price alone. The cheapest quote rarely ends up cheapest. Factor rework, turnover, and opportunity cost.
• Skipping reference calls. Two 20-minute calls will save you three months of pain. Do them.
• Starting work before the SOW is signed. "We'll paper it up next week" is how scope disputes start.
• No written acceptance criteria. If you can't define "done" on paper, neither can your vendor.
• Owning the repo later. Day-one repo ownership or it doesn't get signed.
• Treating security as a post-launch concern. It moves from a $2k fix to a $200k fix the moment you have users.
• Assuming English fluency on the pitch call means fluency on the squad. Meet the squad.

Ready to run this checklist on FWC?

We've shipped 30+ mobile apps and web systems for B2B and B2C clients across fintech, logistics, service management, e-commerce, and AI/automation, with engagements scoped between 30 and 120 days. Our standard contract pack — MSA, SOW, NDA, IP assignment, DPA — is ready to redline. Reference calls are on offer. If you have a shortlist and want to slot us in, book a scoping call or send your scope through our project intake form and we'll come back with a named squad, timeline, and fee structure within five business days.

Bring the full list of questions to ask before hiring a software development company. We'll have answers for every one.