How to Vet a Software Development Studio: 31 Questions, Red Flag Answers, and Contract Clauses That Matter

Most software development agency vetting guides are written by software development agencies.

That's the first thing to understand. The advice you'll find in listicles about "10 questions to ask your developer" tends to cover communication style, team structure, and portfolio fit—areas where most studios have reasonable answers. The harder questions—about code ownership, liability caps, what happens if they disappear mid-project, whether their "work made for hire" clause actually works—those rarely appear in the public corpus.

This happens because the people writing those guides have an incentive to keep the conversation comfortable. A founder asking "what's your liability cap?" or "who owns the IP if you go out of business?" is asking the questions that separate well-drafted agreements from ones that leave you exposed.

We've split this into three parts: the 31 questions worth asking (with the ones most guides skip), what answers should actually worry you, and the three contract clauses that matter most.

The 31 Questions: Organized by What They Actually Test

Team & Stability (5 questions)

1. Who are the senior developers that will work on my project? Can they be named in the contract as key personnel?
2. What's your turnover rate for developers on active projects?
3. If a key person leaves mid-project, how do you handle the transition? Who owns the knowledge transfer?
4. Have you had to wind down or restructure in the past five years? What happened to ongoing client projects?
5. Who owns the company and what's the governance structure? (Relevant if you're signing a multi-year relationship.)

Process & Communication (6 questions)

1. Walk me through your project kickoff. What gets documented and who signs off on scope?
2. How do you handle scope creep? Show me a real example of a scope change request.
3. What's your definition of "done"? What does handoff look like?
4. How often will we communicate and through what channels? Can I talk directly to the developers or do I go through an account manager?
5. What happens if we disagree on whether something is working? How do you resolve disputes without billing more hours?
6. Have you ever missed a deadline? What happened and how did you handle it?

Portfolio & Technical Approach (5 questions)

1. Show me three projects similar in scope and complexity to mine. Can I talk to those clients?
2. What's your tech stack for a project like mine? Why those choices? Are you wedded to specific frameworks or do you choose based on the problem?
3. Do you do security reviews, penetration testing, or security hardening as part of standard delivery? What's included and what costs extra?
4. How do you handle technical debt? Do you build time into projects for refactoring, or is that a separate line item?
5. What's your approach to testing? Unit tests, integration tests, end-to-end? What's the coverage bar?

Support & Maintenance (4 questions)

1. What happens after launch? Do you offer a support period? For how long and what's included?
2. If I need a bug fix after the project ends, what's your process and pricing?
3. Will you maintain the code if I want you to? What does that retainer look like?
4. If I want to bring the code in-house or hand it to another developer, will you help with the transition?

Pricing & Terms (3 questions)

1. Is the price fixed or hourly? If fixed, what happens if the scope changes? What's your change order process?
2. What's the payment schedule? Upfront, milestone-based, or at the end?
3. If the project is delayed on your end, do we get a refund or credit? If I ask for more features mid-project, how is that billed?

Code Ownership & IP (5 questions—this is where most guides stop)

1. Who owns the code when the project is done? Get them to say it explicitly and then read the clause in the contract that backs it up.
2. What does your "work made for hire" clause actually say? (Ask to see the exact language.)
3. If work made for hire doesn't apply legally, do you have an assignment clause that transfers ownership to me?
4. Do you use open-source libraries or frameworks? Will I have access to the source code and the list of dependencies?
5. If you built reusable components or modules on my dime, do I own those or do you?

Risk & Liability (3 questions)

1. What's your liability cap? (Most contracts have one; it's usually 12 months of fees or the project cost.)
2. What's covered by your errors and omissions insurance and what's the policy limit?
3. If the app goes down, gets hacked, or loses data after you hand it off, who's responsible?

The Answers That Should Worry You

Some answers are worse than others. Here's what each red flag actually means.

Team Stability

Red flag: "We don't name key people in contracts. We manage projects as a team."

This means if the person you interview and liked leaves, you get whoever's available. It also makes it harder for you to hold them accountable if a specific person underperforms. Push for at least the technical lead to be named.

Red flag: "If someone leaves, we just bring someone else up to speed from the documentation."

Documentation doesn't replace institutional knowledge. If you hear this, ask directly: "Who covers the gap while they ramp up?" and "How much extra time does that add?" If they can't answer, the cost is hidden in your timeline.

Scope & Process

Red flag: "We don't do formal scope changes. We just adjust as we go."

This is how projects balloon. You need every scope change documented, approved, and priced. If they resist a change order process, they're signaling that they plan to absorb costs into your timeline or their margins—which means delays or corner-cutting.

Red flag: "Our estimates are usually within 20% of the final cost."

That's 20% either direction. That's a $100k to $120k range on a $100k project. That's not a range, that's a swing. Ask what they mean by estimate accuracy and push for fixed-price delivery with a change order process.

Support & Handoff

Red flag: "We recommend a 30-day post-launch support period."

30 days is too short. You're still finding bugs and edge cases. At Authect, we build security audits and compliance into delivery, but even then, 30 days puts you in the position of either paying for rush fixes or living with known issues. Push for 60–90 days minimum, with clear SLAs for bug response.

Red flag: "We won't help transition the code to another developer."

This is a sign they've built something unmaintainable or they want lock-in. A well-written codebase with clean handoff documentation should transfer easily. If they push back, it's usually because one of those is missing.

Code Ownership & IP

Red flag: "We use work made for hire clauses. You own everything."

This is partially true, but incomplete. A work-made-for-hire clause alone may not give you ownership in court. According to the U.S. Copyright Office, work made for hire is narrowly defined in the statute, and courts have found that the designation in a contract is not conclusive. Software is not listed as one of the nine enumerated categories where work made for hire applies automatically. The safer structure is belt-and-braces: a work-made-for-hire clause plus an assignment clause that transfers copyright ownership as a backup. If they don't have both, push for an assignment clause in writing.

Red flag: "The code uses our proprietary frameworks. You can't take it elsewhere."

This is lock-in by another name. You own the code but you can't use it without their framework, which means you're paying them forever for maintenance. Ask them to carve out their proprietary pieces and assign everything else to you, or walk.

Red flag: "We open-source components we build for you."

If you're building a competitive advantage, your code should be private. If it's infrastructure, open-sourcing can be fine—but you should agree upfront. Don't find out after launch that your code is public.

Liability & Risk

Red flag: "We don't cap liability. We take full responsibility."

This is actually a yellow flag, not a red one. Full liability sounds good but it's a deal-killer. No development studio will take it, which means they won't sign with you. The real question is whether the cap is reasonable. A cap of 12 months of fees is typical; a cap of 3 months is tight. Negotiate from there.

Red flag: "Liability caps don't apply to breaches of IP ownership or security flaws."

This is reasonable. Push back only if the cap on other items feels too low. IP and security are legitimately high-risk, and studios should carry insurance for those.

Three Contract Clauses You Need to Read Word-For-Word

1. The IP Assignment Clause

This is the most important clause in the contract. It determines whether you own the code or whether the developer retains any rights. Here's what a solid clause looks like:

Developer hereby assigns to Client all right, title, and interest in and to all work product created under this Agreement, including but not limited to all code, documentation, designs, and intellectual property, as works made for hire or, if such designation is deemed invalid, through assignment. Client shall have exclusive ownership of all work product and shall have the right to use, modify, distribute, and sublicense the work product at Client's sole discretion.

The belt-and-braces structure here is key: it designates work as made for hire and assigns it as a backup if that designation fails. Many contracts have only one or the other, which leaves you exposed.

Watch for this trap: Some developers write, "Developer assigns all rights to work created by Developer," meaning code the developer writes on their own time using their own tools outside your project. That's different from work done under the agreement. The clause should say "work created under this Agreement" or "work product" to be clear.

2. The Warranty & Support Period Clause

This sets how long the developer is responsible for fixing bugs after handoff. The catch is that different developers define the warranty window differently, and the contract often contains contradictory language.

Here's what you want:

Developer warrants that the deliverables will be free of material defects and will conform to the specifications outlined in the Scope of Work for a period of sixty (60) days following delivery ("Warranty Period"). During the Warranty Period, Developer shall, at no additional cost, correct any material bugs or defects reported by Client. After the Warranty Period, all support and maintenance services are subject to a separate Statement of Work and fee schedule.

The key variables: Is the window 30, 60, or 90 days? Does "delivery" mean code handoff, go-live, or both? (Some developers start the clock at go-live, which gives them a break if launch is delayed on your end.) Is bug-fixing free or on-call-rate? If on-call, what's the hourly rate and minimum charge?

Read the exact language. One contract might say "30-90 day warranty" in one clause and "30-60 days" in another. That contradiction will bite you when you need a bug fixed on day 75.

3. The Scope Change & Time-for-Payment Clause

This is where delays usually hide. Here's the structure:

Any changes to the scope of work must be documented in a Change Order, signed by both parties, and shall include an updated fee and timeline. If Client requests changes that materially affect the timeline, Developer shall provide a revised estimate before proceeding. If Developer experiences delays caused by factors outside Client's control, Developer shall notify Client within two (2) business days and provide a revised timeline. Delays caused by Client shall extend the timeline by the number of days of the delay; delays caused by Developer shall not extend the timeline or increase the fee without a separate Change Order signed by Client.

The friction point: whose delays cost whom? If you ask for features mid-project, that's a client delay and the timeline moves. If they underestimated and need more time, that's on them. Make sure this is explicit. Vague contracts lead to passive disputes where the developer just works slower and you're left hoping it ships.

What to Do Before You Sign

Three steps:

1. Ask for a redline template. Request their standard MSA and IP assignment in writing before the sales call. Read it with a lawyer or someone who has. This costs a few hundred dollars and saves tens of thousands in disputes later.
2. Reference check with leverage. Don't ask the three reference clients they give you. Ask them for past clients and call three you pick. Ask about timelines, scope creep, and whether they'd work with them again. The clients they don't offer up are usually more honest.
3. Specify key personnel and escalation in the contract. Name the technical lead. Name the point of contact for disputes. Set a timeline for response times on critical issues. Vague accountability = vague responsibility.

FAQ

What if the studio won't sign an assignment clause and insists on work-made-for-hire only?

You have three choices: push back and ask why they won't, find another studio, or accept the risk with eyes open. The belt-and-braces approach (work made for hire plus assignment) is the legal standard for software because courts have found work-made-for-hire designations insufficient on their own. If a studio refuses an assignment clause, either they don't understand copyright law—a red flag on a software project—or they want to retain some control. Either way, you should know about it before signing.

Is a 30-day warranty period actually too short?

Yes. You're typically in bug-discovery and user-testing mode for at least 60 days post-launch. Some of those bugs are the developer's responsibility, some are user error, and some are design changes you'll want to make. A 30-day window forces you to choose between paying for rush fixes or accepting issues as bugs versus features. Push for 60–90 days, with clear definitions of what counts as a defect versus a feature request.

Do I really need a lawyer to review the contract?

For a project under $50k, a technical co-founder or engineering leader can usually spot the obvious gaps: who owns the IP, what happens on delays, what's the liability cap. For projects over $100k or with complex integrations, you want a lawyer who has reviewed software development agreements. The cost—usually $500–$1,500 for a review—is worth it compared to disputes later.

What should I ask about their post-launch support if they recommend a short warranty period?

Get pricing for bug fixes, support retainers, and maintenance contracts up front. Ask: "If I need a critical bug fix 90 days after launch, what's the process and cost?" If they say "that would be billed at our standard rate," pin down that rate. If they say "we'd fit it in with other clients," you know it's not actually a priority.