Don't Hire a Software Company Before Asking These 15 Questions

-By Sapphire Technologies Expert Team

We've been on both sides of this conversation. As a custom software development company with 200+ delivered projects, we've answered thousands of client questions — and we've watched businesses lose time, money, and sanity by not asking the right ones. This guide exists so you don't repeat those mistakes.

Here's an Uncomfortable Truth 

Most businesses hire a software company the same way they buy a car online.

They look at the website. They check a few reviews. They compare prices. They pick one.

And then — 3 months, 6 months, or £50,000 later — they realise they bought a lemon.

The software doesn't work the way they imagined. The deadlines kept moving. The communication was patchy. The "senior developers" turned out to be interns. And the contract? It protected the vendor — not them.

This happens every single day. And almost every time, it was preventable.

The difference between a catastrophic software project and a successful one often comes down to what you asked before you signed.

At Sapphire Technologies, we believe in radical transparency. So we've compiled the 15 most important questions you should ask any software development company — including us — before you commit a single penny.

Ask them all. Judge the answers carefully. Your project depends on it.

Also Read: Top Mistakes to Avoid When Outsourcing Software Projects

Table of Contents 

1. Can You Show Me Relevant Work You've Done Before?
2. Who Exactly Will Be Working on My Project?
3. What Is Your Development Process?
4. How Do You Handle Changing Requirements?
5. How Will We Communicate — and How Often?
6. Who Owns the Code When the Project Is Done?
7. How Do You Approach Testing and Quality Assurance?
8. What Does Your Pricing Model Look Like?
9. What Happens If You Miss a Deadline?
10. How Do You Handle Security and Data Protection?
11. Can You Scale the Team If the Project Grows?
12. What Does Post-Launch Support Look Like?
13. Have You Ever Failed a Project? What Happened?
14. What Do Your Clients Say About You?
15. Why Should I Choose You Over Everyone Else?

Final Thoughts: The Right Company Will Welcome Every Question

Question 1: Can You Show Me Relevant Work You've Done Before? 

This is your starting point — and it's non-negotiable.

Any software company worth hiring will have a portfolio. But don't just look at it — interrogate it.

Ask specifically:

• Have you built something similar to what I need?
• Can I see the live version of this product?
• Can I speak to the client directly?

Why it matters: A company that's built 10 e-commerce platforms has a fundamentally different level of understanding than one that's built their first. Relevant experience means fewer mistakes, faster delivery, and better decisions throughout your project.

Red Flag: They show you a beautiful portfolio but can't provide a single client reference. Portfolios are curated. Client conversations are real.

At Sapphire Technologies, we don't just show you our portfolio — we connect you directly with past clients. Their words matter more than ours.

Question 2: Who Exactly Will Be Working on My Project? 

This is the question that separates great companies from great salespeople.

You might have your kickoff call with a senior partner who has 15 years of experience. But who writes the code on Monday morning?

Ask directly:

• What are the names and seniority levels of the developers assigned to my project?
• Will any work be subcontracted to a third party?
• What happens if a key developer leaves mid-project?

Why it matters: It's shockingly common for agencies to win projects with senior talent and deliver with junior developers. The quality gap between a mid-level and a senior developer isn't 20% — it's often 300%.

Red Flag: Vague answers like "our talented team of engineers" without specific names, roles, or LinkedIn profiles to verify.

At Sapphire Technologies, every client meets their dedicated development team before a single line of code is written. No surprises. No bait-and-switch.

Question 3: What Is Your Development Process? 

Great software isn't written — it's engineered. And engineering requires process.

Ask the company to walk you through their process from kickoff to delivery:

• Do you use Agile, Waterfall, or a hybrid?
• How are sprints planned and reviewed?
• How do you move from requirements to design to development to testing?
• What project management tools do you use? (Jira, Trello, Asana?)

Why it matters: A company with no defined process is a company that operates on luck. Luck runs out. Process doesn't.

What good looks like: They explain a clear, repeatable methodology. They mention sprint reviews, regular demos, testing cycles, and client checkpoints. They can show you a real project timeline from a past client.

Red Flag: "We're flexible — we adapt to whatever you need." Flexibility is great. Having no process at all is a disaster.

Also Read: Agile vs. Waterfall Software Development Methodology

Question 4: How Do You Handle Changing Requirements? 

Here's a guarantee: your requirements will change.

You'll have a new idea in week 3. Your customers will give you feedback that shifts priorities. Your competitor will launch something that changes your thinking entirely.

This is normal. The question is — how does the software company handle it?

Ask specifically:

• What is your change request process?
• How do changes affect timeline and budget?
• Can you show me an example of how you handled a major scope change for a past client?

Why it matters: Some companies use change requests as a revenue engine — charging eye-watering fees for the smallest adjustments. Others absorb every change without tracking it, leading to scope creep that kills the project.

What good looks like: A clear, fair change management process. Changes are documented, impact is assessed transparently, and the client is always informed before costs are incurred.

Red Flag: Either extreme — "we never charge for changes" (unsustainable) or "any change will require a new contract" (inflexible and expensive).

Question 5: How Will We Communicate — and How Often? 

Poor communication is the silent killer of software projects.

Not poor code. Not poor design. Poor communication.

Ask directly:

• Who is my single point of contact?
• What communication tools do you use? (Slack, Teams, Email?)
• How often will I receive project updates?
• What is your response time commitment for queries?
• How do you handle time zone differences?

Why it matters: A week of silence in a software project can mean a week of development in the wrong direction. Regular, structured communication keeps projects on track and clients informed.

What good looks like: A dedicated project manager as your single point of contact. Weekly progress reports. A shared project dashboard you can access anytime. A committed response time (e.g., within 4 business hours).

Red Flag: "We'll update you when there's something to update." That's not communication — that's radio silence with a label on it.

Question 6: Who Owns the Code When the Project Is Done? 

This question has ended business relationships, sparked legal battles, and cost companies millions.

Ask clearly and directly:

• Will I own 100% of the source code at project completion?
• Are there any third-party libraries or components that restrict my ownership?
• Will you transfer all code repositories to my ownership?
• Do you retain any licence or usage rights over my product?

Why it matters: Some development companies retain intellectual property rights over code they've written — meaning you're licensing your own software rather than owning it. This is more common than most people realise.

What good looks like: A clear IP assignment clause in the contract stating that all code, designs, documentation, and intellectual property belong to you upon final payment.

Red Flag: Any hesitation, vagueness, or "it depends on the contract" response to this question. IP ownership should be non-negotiable and crystal clear from day one.

At Sapphire Technologies, every contract includes an unambiguous IP transfer clause. Your code. Your product. Your future.

Question 7: How Do You Approach Testing and Quality Assurance? 

You don't want to find out about bugs from your customers.

Ask specifically:

• Do you have a dedicated QA team or do developers test their own code?
• What types of testing do you conduct? (Unit, integration, regression, performance, security?)
• Do you practice test-driven development (TDD)?
• How do you handle bug fixes post-launch?

Why it matters: Testing isn't an optional add-on — it's the difference between a product you can be proud of and one you're constantly apologising for. Companies that skip thorough QA are passing their testing costs on to you and your customers.

What good looks like: A dedicated QA process running parallel to development. Multiple testing types. A clear bug tracking system. A defined bug fix policy post-launch.

Red Flag: "Testing is done by the developers who wrote the code." Self-testing is inherently biased. You need independent QA eyes.

Question 8: What Does Your Pricing Model Look Like? 

Budget conversations are uncomfortable. Have them anyway.

Ask directly:

• Do you charge fixed price, time-and-materials, or a retainer?
• What's included in the quoted price and what isn't?
• Are there any hidden costs I should know about? (Hosting, licences, third-party tools?)
• How are payment milestones structured?
• What happens to cost if the project takes longer than expected?

Why it matters: Pricing models have significant implications for your risk exposure. Fixed price sounds safe but often leads to corners being cut. Time-and-materials gives flexibility but requires strong oversight.

Red Flag: A quote with no breakdown of costs. If they can't tell you what you're paying for, you're paying for everything — including their mistakes.

Question 9: What Happens If You Miss a Deadline? 

Every company promises to meet deadlines. Ask what happens when they don't.

Ask specifically:

• What is your on-time delivery rate across past projects?
• Are there contractual penalties for missed milestones?
• What is your protocol when a deadline is at risk?
• Can you give me an example of a delayed project and how you managed it?

Why it matters: Deadlines matter. A missed software launch can mean a missed market window, a failed funding round, or a legal breach with your own clients. You need to know the company takes delivery commitments seriously.

What good looks like: Honest acknowledgement that delays happen — combined with a clear escalation process, proactive communication, and contractual accountability.

Red Flag: "We always deliver on time." No company in the world has a 100% on-time delivery rate. This is either a lie or they've never done a complex project.

Question 10: How Do You Handle Security and Data Protection? 

In 2025, security isn't optional. It's foundational.

Ask directly:

• Do you follow secure coding standards? (OWASP Top 10?)
• How do you handle data protection compliance? (GDPR, HIPAA, etc.)
• Do you conduct security testing and penetration testing?
• How is sensitive client data handled during development?
• What security certifications does your team hold?

Why it matters: A data breach caused by poor security in your software is your liability — not theirs. Security built in from the start costs a fraction of security bolted on after a breach.

What good looks like: OWASP compliance, GDPR awareness, secure coding practices baked into the development process, and a clear data handling policy during development.

Red Flag: "We'll add security features in the next phase." Security is not a feature — it's a foundation. Any company that treats it as optional doesn't understand modern software development.

Question 11: Can You Scale the Team If the Project Grows? 

What you need today might be very different from what you need in 6 months.

Ask specifically:

• How quickly can you scale the team if we need to accelerate?
• What's your current team capacity and pipeline?
• Do you have specialists available for specific needs? (Data engineering, AI/ML, mobile, etc.)
• How do you manage team scaling without losing project context?

Why it matters: If your product succeeds — and it should — you'll need more. A development partner who can grow with you saves you the painful process of finding, onboarding, and briefing a new company from scratch.

Red Flag: "We're a boutique team — we prefer to stay small." There's nothing wrong with being a boutique agency. But if they can't scale, you need to know that upfront before it limits your growth.

Question 12: What Does Post-Launch Support Look Like? 

Launch day is day one — not the finish line.

Ask directly:

• Do you offer post-launch support and maintenance?
• What is your SLA (Service Level Agreement) for bug fixes post-launch?
• How are critical production issues handled? What's the response time?
• What does ongoing development and feature updates look like?
• What happens if we want to move to a different company after launch?

Why it matters: Software needs constant care — security patches, performance optimisation, feature additions, and bug fixes. A company that disappears after launch leaves you stranded.

What good looks like: Clearly defined support tiers, committed response times for critical issues, transparent pricing for ongoing work, and a clean handover process if you ever need to transition.

Red Flag: "Support is quoted separately after delivery." This isn't a red flag on its own — but if they can't give you a clear support structure upfront, you'll be negotiating from a weak position post-launch.

Question 13: Have You Ever Failed a Project? What Happened? 

This is the question most people are afraid to ask.

Ask it anyway.

• Can you tell me about a project that didn't go to plan?
• What went wrong and why?
• What did you do to fix it?
• What did you change as a result?

Why it matters: Every company that's been around long enough has had a project go sideways. What matters isn't that they failed — it's how they responded. Honesty about failure is one of the strongest indicators of a trustworthy partner.

What good looks like: A candid, specific account of what went wrong, ownership of their role in it, and clear changes they implemented as a result.

Red Flag: "We've never had a project fail." This is almost certainly untrue — and if they're willing to lie about this, what else are they willing to lie about?

At Sapphire Technologies, we've had projects that hit turbulence. We own those moments. They made us significantly better at what we do.

Question 14: What Do Your Clients Say About You? 

Don't rely on testimonials on their website. Anyone can curate those.

Go deeper:

• Can you provide 3 client references I can contact directly?
• Are you listed on independent review platforms? (Clutch, Google, G2, Trustpilot?)
• Can I speak to a client whose project was similar to mine?
• What do clients who didn't continue with you say? (Yes, ask this.)

Why it matters: Independent verification is everything in software development. A company with 50 five-star reviews on Clutch has earned them through real client experiences — not curation.

What good looks like: Immediate willingness to provide references. A strong, consistent presence on independent review platforms. Specific testimonials that mention outcomes, not just "great team to work with."

Red Flag: They only have testimonials on their own website and can't provide a single contact you can reach independently.

Question 15: Why Should I Choose You Over Everyone Else? 

Save this one for last. Let them answer it knowing you've asked every other question.

A great answer will be specific, confident, and honest. It will reference your particular project, your industry, and their relevant experience. It will acknowledge their weaknesses alongside their strengths.

A poor answer will be generic. "We're passionate about quality." "We put clients first." "We go the extra mile." These mean nothing without evidence.

What a great answer sounds like:

"For your specific project, we've built three similar platforms. We have a dedicated developer with 8 years of experience in your industry. Our post-launch support is best-in-class because we offer 12 months of included maintenance. And our IP policy means you own everything from day one. Those are the reasons — and here are the client references to back every one of them up."

Red Flag: A generic, rehearsed answer that could apply to any company or any project. If they can't differentiate themselves specifically for your needs, they probably can't serve your needs specifically either.

Final Thoughts 

Here's how you know you've found the right software development partner:

They don't flinch at Question 13.
They answer Question 6 without hesitation.
They hand you references before you ask for them.

The right company doesn't just tolerate your questions — they celebrate them.

Because a client who asks great questions becomes a great collaborator. And great collaborators produce great software.

At Sapphire Technologies, we've built 200+ software products across industries ranging from commercial real estate to e-commerce to enterprise SaaS. Every successful project started with a conversation — the kind where the client asked hard questions and we gave honest answers.

We'd love to have that conversation with you.

Ready to ask us these 15 questions?

Book Your Free Discovery Call →

No sales pitch. No pressure. Just honest answers — and the beginning of something great.

Author: Sapphire Technologies Expert Development & Strategy Team
Last Updated: May 2026
Based on: 200+ delivered projects, 10+ years of industry experience
Tags: Software Development FAQs, Questions to Ask Software Company, Hiring Software Development Company, Custom Software Development, Software Outsourcing, Vendor Evaluation