How to choose a software development company: 12 questions that separate pros from amateurs

To choose a software development company well, you need to verify five things: who actually writes the code, who owns everything at the end, how and how often they deliver, whether their references check out, and what happens if you want to leave. The 12 questions in this guide cover those five dimensions — and more important than each question is knowing what answer to expect. A serious vendor answers all 12 without flinching; the one who gets uncomfortable is saving you time.

Full disclosure: we're a biased party. Freshwork has been building custom software from Chile for over 10 years, and we compete for these same projects. That's exactly why we wrote down the answers any good vendor would give — not just us.

What should you ask about the team?

1. Who will actually write my code?

Expected answer: specific names and their seniority — ideally the same people who sat in the sales meeting. Red flag: "our team of 50+ developers" without telling you who yours is, or discovering later that the work is subcontracted. Agencies that sell with senior profiles and execute with unsupervised juniors are the single most common cause of failed projects.

2. Where is the team located and what hours do they work?

Expected answer: a concrete location and time zone with real overlap with your workday. This is where nearshore beats classic offshore: a team in Chile works US Eastern hours, so questions get resolved the same day instead of crossing the night by email. Also ask what language the work happens in — meetings, documentation and code.

3. Who will be my point of contact during the project?

Expected answer: direct access to the technical people, not just an account executive. The telephone game between you, a project manager and a developer you've never met makes every iteration slower and more expensive. In small senior teams, you talk to the people who build.

What should you ask about ownership and the contract?

4. Do the code, accounts and data end up in my name?

Expected answer: an unqualified yes, in the contract. Source code, repositories, servers, domains and credentials in your name from day one. Red flag: monthly licenses "to use the platform," the vendor's proprietary framework, or repositories you can't access. That's not custom development — it's renting with extra steps.

5. How do you price projects, and what happens when scope changes?

Expected answer: a breakdown by stage or module, plus an explicit mechanism for changes: what gets re-quoted, what gets absorbed, who decides. Scope always changes; what distinguishes a good vendor is having a process for it instead of a war of change orders. To calibrate numbers before requesting quotes, see our custom software development cost guide.

6. What happens if I want to leave mid-project?

Expected answer: you take everything built to date — code, documentation, access — and the contract defines an orderly exit without abusive penalties. A vendor confident in their work doesn't need to lock you in. Red flag: long lock-in clauses, or an awkward silence when you ask.

What should you ask about how they work?

7. How often will I see working software?

Expected answer: frequent deliveries — weekly or biweekly — in an environment where you can click around and test. Red flag: "we'll present the complete system in 4 months." Big-bang delivery is the classic recipe for disaster: you pay blind for months and every problem surfaces at once at the end. Our internal rule: if by week four there's nothing you can try, something is wrong.

8. What technologies do you use, and why?

Expected answer: a focused, mature stack with a broad talent market (think Laravel, React, Vue, PostgreSQL), justified in business terms: maintainability, developer availability, operating cost. Red flag: whatever's trendy this quarter with no rationale, or "we work with everything" — which usually means they've mastered none of it.

9. How do you test and document what you build?

Expected answer: automated tests on critical paths, code review, and documentation good enough that another team could take over. You don't need to audit the technical details: ask to see the documentation from a past project. If it doesn't exist, you already know how yours will end up.

What should you ask about results and backing?

10. Can I talk to two current clients?

Expected answer: real names and contacts, no drama. Call them and ask three things: did they hit deadlines? how did they handle problems (there are always problems)? would you hire them again? A pretty portfolio doesn't replace this call — logos get pasted on a website; references have to be earned.

11. What happens with bugs after launch?

Expected answer: a defect warranty for a defined period (construction errors get fixed for free) plus clear ongoing support options afterwards. Red flag: charging to fix their own bugs from day one, or refusing to distinguish between a defect and an improvement.

12. Will you ever tell me no?

The most underrated question on the list. Expected answer: concrete examples of when they advised a client not to build something — because a SaaS already solved it, because the scope didn't hold up, because starting smaller made more sense. A vendor that says yes to everything isn't a partner; it's an order-taker, and you'll pay for their silence.

What signals should rule a vendor out immediately?

Beyond the 12 questions, there are fast disqualifiers:

• They quote without asking questions. Nobody can size what they don't understand.
• You can't meet the technical team before signing.
• The code won't be in your name, or proprietary licenses are involved.
• They promise impossible dates without cutting scope: the full platform in 3 weeks.
• No contactable references — just logos on a website.
• High-pressure sales with discounts that expire tomorrow. Software should be bought calmly.

None of these signals alone dooms a project, but two or more together almost always end in a rescue. We know because part of our work is rescuing and modernizing systems that started badly.

Frequently asked questions

Should I hire a freelancer or a development company?

A senior freelancer works well for small, short projects. For systems your operation will depend on for years, a company gives you continuity: if one person gets sick or leaves, the project doesn't die with them.

How much should my project cost before I request quotes?

As a reference with senior nearshore teams: automations from US$ 3,000, web applications with an admin panel between US$ 5,000 and 15,000, MVPs between US$ 10,000 and 30,000. Full detail in our 2026 cost guide.

What do I do if I'm already stuck with a failing vendor?

Secure the assets first: code, access and data in your name. Then get an independent technical second opinion on the real state of the system. Often you can recover and modernize what was built without starting over.

If you're evaluating vendors, ask each of them these 12 questions — including us. Write to us and we'll answer all 12 straight, or check our FAQ first.