- You're not really buying code — you're choosing the people, process, and technical decisions your business may depend on for years.
- A strong development partner should be transparent about people, ownership, process, quality, security, cost, and what happens when the engagement ends.
- Don't settle for one-paragraph answers. For every question, ask what a good answer sounds like and what a red flag sounds like — the difference is usually obvious once you know what to listen for.
- Before you ask any of the 15 questions below, ask Question Zero: should you be building custom software at all?
- We're a software development company, so we're obviously not a neutral party here. But these are questions we think every prospective client should ask every development company — including us.
01 — The premise
You're Not Really Buying Code
When you hire a software development company, you're not buying a finished product off a shelf. You're choosing the people who will build it, the process that will shape it, and a set of technical decisions your business may have to live with for years. That makes this decision closer to hiring a key employee than purchasing software.
The basic "questions to ask before hiring a developer" article has become a crowded format — most versions read the same, and a vendor can answer nearly all of them with a confident "yes" without actually telling you anything. The more useful version isn't a longer list. It's a better structure for using the list you already have.
For every question below, we give you four things:
- Why it matters — the real risk the question is designed to surface
- A good answer — specific, concrete, and verifiable
- Red flags — vague language that should make you slow down
- Evidence to request, where it applies — something you can actually ask to see
02 — Question Zero
Should You Even Be Building Custom Software?
A good development company shouldn't automatically recommend development. Sometimes the right move is to connect what you already have, automate an existing workflow, or configure an off-the-shelf product — and sometimes it really is building something new. The first sign of a good software development company is that they're willing to tell you that you may not need custom software.
That establishes credibility before anyone has sold you anything. And it's worth saying plainly: we're a software development company, so we're obviously not a neutral party in this conversation. But these are the questions we think every prospective client should ask every development company — including us.
03 — Part 1
Evaluate the People
The people in the sales meeting aren't always the people writing the software. Start here, because everything else in the relationship runs through the humans actually doing the work.
1. Who will actually work on my project?
Why it matters: Staffing gets decided after the contract is signed at a lot of firms — and that's when you find out who you actually hired.
- A good answer: Names, roles, seniority, and how oversight works — plus whether the work is done by employees, contractors, offshore teams, or subcontractors.
- Red flags: "Our development team will handle it." No names offered. Unclear or undisclosed outsourcing.
- Evidence to request: Meet the project manager or engineer who will actually be involved — not just the salesperson.
2. Have you built something comparable — and what went wrong?
Why it matters: A portfolio of unqualified wins tells you less than one honest story about a project that hit trouble.
- A good answer: A specific comparable project, plus a real account of a problem they hit and how they handled it.
- Red flags: Only ever "our biggest success," with no willingness to discuss anything that went sideways.
3. Can I speak with clients you've actually worked with?
Why it matters: References confirm — or contradict — everything else you've been told.
- A good answer: Willingness to connect you directly, without heavy screening of the conversation.
- Red flags: Reluctance, or references that turn out to be one very old project.
- Evidence to request: Ask the reference about communication, surprises, budget changes, and whether they'd hire the company again.
04 — Part 2
Understand the Money and Process
This is where most engagements quietly go wrong — not because the estimate was dishonest, but because the assumptions behind it were never made explicit.
4. How do you estimate software projects?
Why it matters: Fixed-price and time-and-materials both work — the danger is a number with no visible assumptions behind it.
- A good answer: Clear assumptions, named exclusions, and an honest range that accounts for uncertainty.
- Red flags: An instant fixed quote with no discovery conversation first. If you want the fuller picture on what actually drives software cost, we cover it in How Much Does It Cost to Build a Custom Software Application in 2026?
5. What happens when requirements or scope change?
Why it matters: Requirements almost always evolve. The question is whether that process is defined or improvised.
- A good answer: A named change-order process — who approves changes, and how cost and timeline effects get communicated.
- Red flags: "We'll figure it out as we go," with no defined approval step.
6. What does your development methodology actually look like?
Why it matters: "Do you use Agile?" is a weak screening question — almost every firm says yes. Ask how it actually affects you as the client.
- A good answer: How often you'll see working software, how you give feedback, and how that feedback changes the next sprint. The Agile Manifesto's own principles emphasize frequent working software and responding to change as the real measures of progress — not the label a team uses.
- Red flags: Process buzzwords with no description of what you, specifically, will see or do differently.
7. How often will I see working software?
Why it matters: Status reports are not the same thing as progress you can see and react to.
- A good answer: Staging access, regular demonstrations, and a real feedback loop that shapes upcoming work.
- Red flags: "We'll show you when it's done" — no interim visibility at all.
05 — Part 3
Protect the Product
This is the section a lot of buyers skip until something goes wrong — usually a falling-out with a vendor, or a surprise about who actually controls the accounts the business depends on.
8. Who owns the source code and intellectual property?
Why it matters: "The client should always own everything" sounds right but oversimplifies a genuinely nuanced area — custom code, pre-existing components, and open-source or third-party licenses can carry different terms.
- A good answer: Clear, written contract language covering ownership, licensing, and any pre-existing or third-party components. This isn't legal advice — the U.S. Copyright Office's work-made-for-hire guidance is a useful starting point for why commissioned-work ownership is more complicated than most buyers assume.
- Red flags: No written IP terms, or a vague assumption that ownership "just happens" at project end.
9. Who controls the repository, cloud infrastructure, and other critical accounts?
Why it matters: Managed hosting isn't inherently a problem — the real question is access, control, and what happens during a transition.
- A good answer: A clear list of who holds the repository, hosting/cloud, domain, database, payments, and analytics accounts, and how you'd get access if you needed it. GitHub's own documentation recommends organizational ownership and defined roles rather than a single individual holding the keys.
- Red flags: Everything sits under one developer's personal account, with no organizational ownership.
10. How do you approach security and privacy?
Why it matters: "We're secure" is not an answer — it's a claim with nothing behind it.
- A good answer: Defined practices for access controls, secrets management, dependency handling, secure coding, and data handling. The NIST Secure Software Development Framework is built specifically for buyers to use in conversations like this one.
- Red flags: A one-line reassurance with no specifics on access, secrets, or dependencies.
06 — Part 4
Evaluate Engineering Quality
Quality is the hardest thing to assess from the outside — which is exactly why it's worth asking about directly, rather than assuming it from a polished portfolio site.
11. How is QA and testing handled?
Why it matters: Developers testing only their own work leaves an obvious blind spot.
- A good answer: Developer testing plus independent QA, regression testing, automation where it makes sense, and defined acceptance criteria.
- Red flags: No separate QA step — the person who wrote the code is the only one who tests it.
12. How do third-party integrations and APIs work?
Why it matters: "How do integrations work?" invites a shallow yes. The better question is what happens when a connection breaks.
- A good answer: A clear process for evaluating third-party APIs and handling failures, rate limits, versioning, and authentication when something changes on the other end. See our system integration services for how we approach this specifically.
- Red flags: "We'll deal with it if it breaks" — no monitoring or fallback plan described.
13. How will the software scale?
Why it matters: "Can it scale?" gets a yes from nearly every agency. The useful version asks about specific assumptions.
- A good answer: Explicit assumptions about users, transactions, and data volume, and a clear point at which the architecture would need to change.
- Red flags: A confident "yes, it scales" with no assumptions named — or the opposite problem, over-engineering for load you don't need for years.
07 — Part 5
Make Sure You Can Launch — and Leave
The final test of any development relationship is whether it survives its own ending — whether by a clean handoff, or because the partnership simply runs its course.
14. How do you deploy software and support it after launch?
Why it matters: Launch day isn't the finish line, and "we'll support it" needs specifics.
- A good answer: A defined process for staging, production deployment, rollback, monitoring, and a stated post-launch support window.
- Red flags: No rollback plan, or "support" left undefined in the contract.
15. What happens if we stop working together?
Why it matters: This is the ultimate test of a healthy vendor relationship — could a different, competent team pick up where this one left off?
- A good answer: A clear commitment to hand over source code, credentials, documentation, the database, design assets, and deployment instructions.
- Red flags: Anything that sounds like the business would be stuck without this specific vendor.
And a bonus question worth asking every vendor directly: "What about my project makes you uncomfortable?" That single question can reveal more than asking whether they think they can build it.
08 — Compare at a glance
How to Compare Software Development Companies
Once you've asked all 15 questions of two or three vendors, the answers can start to blur together. This condensed version puts the strong signal and the red flag for each area side by side.
| Area | Strong signal | Red flag |
|---|---|---|
| Team | Named people, direct access | "Our team" — no names |
| Estimate | Assumptions explained, honest range | Instant fixed quote, no discovery |
| Progress | Working software, staging access | Status reports only |
| Scope changes | Defined change-order process | Surprise invoices |
| Ownership | Written IP and licensing terms | Ambiguous or verbal-only IP terms |
| Security | Defined practices, named frameworks | "We're secure" and nothing else |
| QA | Independent, repeatable QA process | Developers only test their own code |
| Exit | Clear, documented handoff | Dependency on this vendor to function |
09 — What to watch for
Five Red Flags That Deserve Extra Attention
You've already seen these individually throughout the 15 questions — here they are together as a fast gut-check before you sign anything.
Red-Flag Checklist
If more than one of these shows up in a single vendor conversation, slow down.
- Vague staffing — no named people, unclear or undisclosed outsourcing
- A confident fixed quote before the vendor understands the actual project
- Agreeing with everything you propose, with no pushback or tradeoff discussion
- Unwillingness or inability to show working software before the final delivery
- Unclear ownership, licensing, or exit terms — nothing in writing
10 — Our answer
How Virgo Development Approaches These Questions
We think a software development company should be willing to answer every question on this list — so here's how we answer them. Named engineers instead of an anonymous queue. Direct client contact instead of a layer of account managers. Weekly progress reports and shared visibility into the work as it happens. No undisclosed offshore or outsourced development. Client ownership of the code you paid for. Production-grade engineering, chosen to fit the project instead of forced into one stack because it's the only one we know.
That said, we'd rather be honest than tidy: there isn't always one universally correct answer to every question above. Fixed-price isn't automatically better than hourly. Agile isn't automatically the right fit for every engagement. Client-owned cloud infrastructure isn't the only legitimate hosting arrangement. The real test isn't which answer a vendor gives — it's whether they can explain the tradeoffs behind it.
11 — Next step
Already Comparing Software Development Companies? Get a Second Opinion.
If you're already evaluating a vendor, bring us your requirements, estimate, or proposed architecture. We'll help you identify the questions worth asking before you commit — even if Virgo Development isn't ultimately the right fit for the project.
Common questions
Quick Answers
Who should own the source code when I hire a software developer?
Source-code ownership should be explicitly defined in the development agreement. In most custom-development relationships, the client ultimately receives ownership of the custom code, while the developer may retain rights to pre-existing libraries, tools, or licensed components. What matters most is that ownership, licensing, and transfer rights are unambiguous before development begins.
What is the single most important question to ask a software development company?
There isn't one universal answer, but "what happens if we stop working together?" tends to reveal the most — it tests whether the relationship depends on trapping you with a single vendor or on a clean, documented handoff any competent team could pick up.
Is fixed-price or time-and-materials better for a custom software project?
Neither is automatically better. Fixed-price offers budget certainty but works best when requirements are well defined up front. Time-and-materials offers flexibility as requirements evolve but requires more trust and visibility into progress. The stronger signal isn't which model a vendor prefers — it's whether they can clearly explain the assumptions and tradeoffs behind their recommendation.
Should I be worried if a software company says I might not need custom development?
No — that's a good sign. A development company willing to recommend connecting existing tools or automating a workflow instead of selling a custom build is demonstrating that its recommendations are driven by your actual problem, not by billable hours.
Jamie Lords ↗ LinkedIn is CEO of Virgo Development and teaches Business and Marketing at Southern New Hampshire University. Jamie's work centers on helping business owners make confident, well-informed decisions about the software partners they hire. This article isn't legal advice — intellectual property and contract terms should be reviewed with your own attorney before signing any development agreement.