How to Choose a Software Development Company: 12 Questions to Ask in 2026

Every year, thousands of businesses hand over their product vision — and a significant portion of their budget — to a software development company they barely know. Some of those relationships are transformative. Many are cautionary tales.

The difference almost never comes down to technical ability alone. The vendors that fail their clients usually looked perfectly competent on paper. What separated them was how they communicated under pressure, who actually owned the IP at the end, and whether their delivery process was built for real-world complexity or just for sales demos.

This guide gives you 12 direct questions to ask every software partner before you sign anything. The goal isn't to catch anyone out — it's to make sure you're choosing a company that will still be a good partner six months in, when things inevitably get complicated.

Most bad outsourcing decisions happen at the selection stage, not delivery

Why choosing on price alone is the most expensive mistake

The cheapest quote almost always becomes the most expensive project. Here's why: a vendor that under-bids to win the contract will compensate through scope disputes, change requests, and a tendency to build to the letter of the spec rather than the spirit of your business need. You end up paying full price — plus the cost of rework, delays, and the emotional toll of a broken relationship.

Budget should be a filter, not the deciding factor. Narrow your options to vendors you can afford, then evaluate them on everything else.

What "proven track record" actually means and how to verify it

Case studies on a vendor's website are marketing. They show the projects that went well. What you actually want to know is what their failure rate looks like, how they handled the projects that ran into trouble, and whether the clients they list would hire them again.

Verification means speaking to those clients directly — not reading a curated quote on a web page.

Before you start: define what you actually need to evaluate

Before you take a single vendor call, be clear on three things:

1. What you're building — not just the product, but the technical complexity. A marketing site and a HIPAA-compliant healthcare platform have almost nothing in common in terms of the skills you need.
2. Your internal capability — do you have a technical co-founder or CTO who can evaluate code quality? Or are you entirely dependent on the vendor for technical judgment?
3. Your engagement preference — do you want a vendor who takes full ownership of the product roadmap, or one that executes against your own specifications?

The answers change which vendors you should be talking to in the first place.

Questions about process and how they work (Q1–Q4)

Q1: What does your development process look like sprint-by-sprint?

You want a specific answer, not a generic one. Any serious development company should be able to walk you through exactly what happens in a two-week sprint: how requirements are broken into stories, how the sprint is planned, what definition of done they use, and what the handoff to QA looks like.

A vague answer — "we follow Agile" — is a yellow flag. Agile is a philosophy, not a process. Press for specifics.

Q2: How do you handle requirement changes mid-project?

This question has no wrong answer, but it has revealing ones. What you're looking for is a process that acknowledges change as inevitable while having clear mechanics for managing it. Good vendors have a defined change request process with transparent cost and timeline implications. Bad vendors either say "we can change anything" (which means the estimate is meaningless) or "we don't allow changes" (which means you'll be locked into whatever you agreed on day one).

Q3: What does the QA process include and who runs it?

Quality assurance should be embedded throughout the build, not bolted on at the end. Ask specifically: do they have dedicated QA engineers, or do developers test their own code? Do they write automated tests? What's the test coverage expectation? Do they run regression testing after every sprint?

A shop with no QA culture will deliver working demos and broken production systems.

Q4: How often will I see working software?

The answer should be "every sprint" — meaning every two weeks you should be able to click through real, functional features, not look at another slide deck. If the vendor proposes any arrangement where you don't see working software for more than three weeks, that's a significant risk signal.

Questions about IP, contracts, and ownership (Q5–Q7)

Q5: Who owns the source code after the project is delivered?

The correct answer is: you do, immediately and completely. Make sure this is explicitly stated in the contract as an IP assignment clause — not just implied. You should own the code, the design files, the documentation, and any third-party integrations built specifically for your project.

Some vendors try to retain licensing rights or include clauses that give them the right to reuse components. Read the IP section of every contract carefully.

Q6: Do you sign an NDA and what does it actually cover?

Reputable development companies sign NDAs without hesitation. But not all NDAs are equal. Ask specifically whether the NDA covers your business idea, your technical architecture, your customer data, and any proprietary processes you share during discovery. A mutual NDA — where both parties are protected — is the professional standard.

Q7: What are the termination provisions if the engagement needs to end early?

This is the question most clients forget to ask until they desperately need the answer. Before you sign, understand: what notice period is required, how much payment is owed on termination, what happens to work in progress, and — critically — does the code and IP transfer to you immediately on termination regardless of circumstances?

If the vendor controls your codebase and you terminate, you need the contractual right to take everything with you.

Questions about communication and project management (Q8–Q10)

Q8: Who is my primary point of contact and what timezone are they in?

This is more important than most clients realise. If your primary contact is a sales account manager in your timezone but the actual engineering team is 8–12 hours away with no overlap, you're going to lose hours and days to communication lag at every decision point.

Insist on knowing, before you sign: who is your dedicated project manager, what are their working hours, and what's the guaranteed response time for a blocking issue?

Q9: How do you handle a project that is running behind schedule?

Every honest project manager will tell you that most complex software projects encounter delays. The question isn't whether delays happen — it's what the vendor does when they do. Look for answers that include: proactive communication as soon as slippage is identified (not at the end of the sprint), root cause analysis, and a recovery plan. A vendor who promises they never miss deadlines is either lying or hasn't built anything complex.

Q10: What project management tools will we use and do I have access?

You should have direct, real-time visibility into your own project. That means access to the project management tool (Jira, Linear, ClickUp — whatever they use), the code repository (GitHub, GitLab), and the communication channel. Anything less means you're dependent on a vendor-curated update, which is never the full picture.

Questions about what happens when things go wrong (Q11–Q12)

Q11: Can I speak to a client who had a project go off-track?

This is the most valuable question on this list, and it's the one almost nobody asks. Any vendor can give you a reference from a project that went perfectly. Ask specifically for a client whose project encountered significant challenges — a missed deadline, a major scope change, a technical pivot — and how the vendor handled it.

If they refuse, or if they only offer references from flawless projects, that tells you something important about how they'll respond to adversity on your project.

Q12: What is your policy on bugs found after launch?

Industry standard is a 30–90 day post-launch warranty period during which bugs are fixed at no additional cost. Anything shorter should be negotiated. Also clarify: what qualifies as a bug versus a new feature request, and what's the response SLA for critical production issues?

The portfolio review: what matters and what is just good marketing

When you look at a vendor's portfolio, focus on these things and nothing else:

• Industry relevance — have they built in your sector before? A great ecommerce developer is not automatically a great healthcare developer.
• Technical complexity — do the projects described match the complexity of what you need?
• Verifiability — can you find the apps in the App Store or the websites live? Can you actually use them?

Screenshots and mockups are not portfolio evidence. Shipped, live products are.

The reference call that most clients skip entirely

If you only take one thing from this guide, make it this: call at least two references before signing any contract. Not email — phone or video call. And ask these specific questions:

• Did the project come in on time and on budget?
• What was the biggest problem you encountered, and how did the vendor handle it?
• Would you hire them again for a project of similar complexity?
• Is there anything you wish you'd known before you started working with them?

The last question consistently produces the most useful answers.

Pricing structures: what each model signals about the vendor

Fixed price works for small, tightly scoped projects (under 8 weeks, well-defined requirements). It gives you cost certainty but no flexibility. Any scope change triggers a renegotiation.

Time and materials is the professional standard for complex, iterative product development. You pay for hours worked, you retain full flexibility, and you share the risk of scope evolution with the vendor.

Dedicated team (monthly retainer for a committed pod of engineers) is best for long-term product development where you want continuity of knowledge and predictable monthly spend.

Avoid vendors who only offer fixed-price contracts for complex products — it usually means they're protecting themselves, not you.

Red flags that should end the conversation immediately

• They can't tell you who your project manager will be before you sign
• They can't show you verifiable case studies from similar-complexity projects
• They push back on giving you IP assignment in writing
• The sales person and the technical team seem to be completely different organisations
• They promise a timeline that seems significantly faster than industry norms without explaining why
• They ask you to pay a large upfront retainer before a discovery phase is complete

How Ortem Technologies answers each of these 12 questions

We'll be direct, because you deserve specifics, not marketing.

Q1: We run two-week Agile sprints with a formal sprint planning session, daily async standups, and a Friday demo you're invited to attend.

Q2: Change requests are documented, costed, and approved by you before a single hour is spent on them. No surprises.

Q3: We have dedicated QA engineers on every project team. Automated test coverage is a delivery requirement, not optional.

Q4: You see working software every two weeks. No exceptions.

Q5: You own everything — all code, all IP — on day one, enshrined in the contract.

Q6: We sign mutual NDAs covering your idea, architecture, data, and business logic as a standard condition of engagement.

Q7: Termination provisions include immediate IP transfer and a structured handover of all work in progress.

Q8: Your dedicated project manager works UK/US business hours and guarantees same-day response to any blocking issue.

Q9: We flag slippage at the earliest possible moment — usually within 48 hours of identifying a risk — with a written recovery plan.

Q10: You have direct access to Jira, GitHub, and Slack from day one.

Q11: Yes. We'll introduce you to clients who had difficult projects. We believe that's how trust is actually built.

Q12: 60-day post-launch warranty, with critical bug SLA of 4 hours.

---

Choosing a software development company is one of the highest-stakes vendor decisions a growing business makes. You can review our case studies to see how we've handled projects across industries and complexity levels. Take the time to ask the hard questions before you sign — because asking them after is considerably more expensive.

If you'd like to put these questions to us directly, book a free 30-minute consultation. We'll answer every one of them, including the uncomfortable ones.

Frequently asked questions

How do I evaluate a software development company's portfolio? Look for verifiable, live projects in your industry vertical with comparable technical complexity. Check that the apps are actually available in the App Store or deployed live — screenshots alone prove nothing. Look for client names you can cross-reference on LinkedIn or Clutch.

What should a software development contract include? At minimum: IP assignment clause (you own all code), NDA, milestone-based payment schedule, change request process, termination provisions with IP transfer on exit, post-launch warranty period, and clear definition of project scope and acceptance criteria.

How do I know if a software development company is legitimate? Check their Clutch or GoodFirms profile for verified reviews with reviewer names you can look up. Ask for video references — not email testimonials. Verify their company registration. Ask to speak directly to the technical lead who will run your project before you sign.

What is a reasonable timeline estimate for a software project? A simple mobile app MVP takes 10–16 weeks. A mid-complexity web platform takes 4–7 months. Enterprise systems typically run 9–18 months. Be cautious of any estimate significantly below these ranges unless there's a clear technical reason — aggressive timelines usually mean something important has been left out of scope.