10 essential questions to ask any .NET development agency before signing. Covers vetting, process, ownership, team structure, and red flags to watch for.
10 essential questions to ask any .NET development agency before signing. Covers vetting, process, ownership, team structure, and red flags to watch for.
Choosing a .NET development agency is a significant decision and the sales process is specifically designed to make every agency look equally capable before you've committed to anything. The questions below are designed to cut through that, surfacing the information that actually differentiates agencies before you sign rather than after.
These aren't trick questions or gotchas. They're the things an experienced technology buyer would want to know, and a good agency should be able to answer all of them clearly and specifically.
This is the single most important question on this list and the answer tells you a lot before the conversation even starts.
Some agencies sell on the strength of their portfolio and senior staff, then assign junior or mid-level developers to your project after signing. Speaking directly with the actual people who'll be doing the work before you commit lets you assess technical depth, communication quality, and fit in a way no sales conversation can replicate.
A strong agency is comfortable with this. Their developers can speak articulately about past projects, ask good questions about yours, and give you a real sense of how they think. If an agency is reluctant to introduce you to the team before signing, ask why. The answer is worth hearing.
The .NET ecosystem moves fast. Microsoft ships a new major version annually, with Long-Term Support versions every two years currently .NET 8, with .NET 10 arriving later in 2026. An agency actively building new projects today should be working in .NET 8 as their standard, with awareness of what's coming in .NET 10.
An agency whose new project work is primarily on .NET 6, or worse still on .NET Framework, is a signal worth following up on. It doesn't necessarily mean the team is weak there are legitimate reasons to support older versions for existing clients but new project work should reflect current versions. Ask why if it doesn't.
This question also surfaces something else: how the developer answers. Someone current in the ecosystem will usually have a nuanced response "we're on .NET 8 for everything new, and we're watching the .NET 10 preview releases" rather than a generic "we use the latest .NET." Specificity is a credibility signal.
Every software project experiences scope changes. The question isn't whether requirements will change it's how the agency manages that when it happens.
The answer you're looking for involves a clear, specific process: how change requests are raised, assessed, and priced, and how they affect timeline. An agency that says "we're flexible, we'll adjust as you need" without describing a structured process is often one where scope changes become informal, undocumented, and eventually disputed.
The answer you're not looking for: "we stick to the original spec" this is either wishful thinking or a warning that the agency will charge heavily for any deviation and become difficult to work with when reality diverges from the initial brief, which it always does.
Code review is one of the clearest proxies for whether an agency takes code quality seriously as a practice rather than as a claim.
A good answer describes a specific, enforced process: all code goes through pull requests, pull requests require at least one reviewer before merging, and what reviewers are actually checking for not just "does it work" but architecture consistency, security patterns, test coverage, and adherence to agreed standards.
A weak answer describes code review as something that happens informally or "when time permits" which in practice means it doesn't happen consistently. On a long project, inconsistent code review compounds into a codebase that's progressively harder to maintain.
If the agency mentions using any specific tooling alongside code review static analysis, security scanning, automated formatting checks that's a stronger signal of a team that has built quality into their process rather than relying on individual developer discipline alone.
This should be non-negotiable, but it's asked less often than it should be. All code written for your project should transfer to you upon payment. You should own it outright not license it, not share ownership with the agency.
Some contracts, particularly from less experienced agencies, include clauses that are ambiguous about IP ownership, or that retain agency ownership of reusable components used in your build. Read the IP section of any contract before signing, and ask specifically: "Does all code written for this project transfer to us on payment, with no exceptions?"
Also worth asking: what happens to IP if the engagement ends early, before full payment? Is partially completed work delivered to you, and under what terms?
Testing is where the gap between agencies that produce maintainable software and those that produce demos is most visible. An agency that builds without tests is building something that works today and becomes progressively harder to modify safely as it grows.
The answer you're looking for: a specific approach to unit tests on business logic, integration tests on key workflows, and a realistic target coverage percentage (80%+ on business-critical code is a reasonable benchmark). Mention of specific frameworks xUnit, NUnit, Moq for .NET adds credibility.
The answer you're not looking for: "we test manually" as the primary answer, or "we write tests if the client requests it." Testing should be default practice, not an optional add-on.
One follow-up worth asking: "Can I see a test suite from a past project?" Not every agency will share this for confidentiality reasons, but the response tells you something an agency that produces good tests usually isn't shy about showing them.
Documentation is the part of software development that most agencies do poorly and most clients only notice the absence of when it's too late typically when they need to extend the application, onboard a new developer, or switch vendors.
What you're looking for: a clear statement of what documentation they produce as a matter of course (architecture decisions, API documentation, configuration setup, deployment runbooks), and where it lives. An agency that uses a shared project wiki Confluence, Notion, or similar and maintains it actively is meaningfully different from one that produces a PDF at the end of a project.
The follow-up question worth asking: "If our engagement ended today, what documentation would we receive and in what format?" The answer reveals both what they actually produce and how they think about your ability to operate independently of them.
Security should be a default practice, not a project phase. An experienced .NET agency should be able to describe specific, concrete security practices without you needing to ask for them to be applied.
A strong answer references specific patterns relevant to ASP.NET Core: input validation and parameterized queries to prevent injection, ASP.NET Core Identity or equivalent for authentication, HTTPS enforcement, proper secret management (Azure Key Vault, environment variables not hardcoded credentials), and an awareness of the OWASP Top 10 as a reference for what they're designing against.
A weak answer: "we follow security best practices" without being able to name any of them specifically. Security best practices in .NET are well-documented and widely understood an agency that can't describe their approach with specifics either hasn't thought about it systematically or isn't confident enough in their knowledge to articulate it, neither of which is reassuring.
Developer turnover happens at every agency, including good ones. The question isn't whether it will happen it's what the agency does when it does, and whether that's your problem or theirs.
A strong answer describes a structured handover process, maintained documentation that reduces knowledge concentration in individual people, and a commitment to providing a replacement developer without billing you for the transition and onboarding time. Some agencies are explicit about this in their contracts; ask to see the relevant clause.
A weak answer: "that hasn't happened with us" (which isn't a policy, it's a claim), or "we'd discuss it at the time" (which means you'd be negotiating from a weak position when you most need continuity).
This question also surfaces how the agency manages knowledge sharing internally. An agency where the developer on your project is the only person who understands your codebase is a single point of failure both for turnover risk and for coverage when someone is sick or on leave.
Portfolio items on agency websites are curated they show the best work, sometimes the most visually impressive work rather than the most technically complex, and they're often described in marketing language that obscures what the actual technical challenge was.
What you're looking for when you ask this question: a specific answer that includes the technology stack used, the actual problem solved (not just "we built a platform for X"), what was technically complex about it, and ideally a reference you can contact. An agency that can describe past work in these specific terms is demonstrating both memory and understanding of what made the work valuable.
If your project involves something specific a microservices architecture, a legacy migration, a compliance-heavy healthcare or fintech application ask explicitly for examples in that category. Strong agencies have done similar work before and can point to it; if they can't, the relevant question is why, and whether that gap matters for your project.
The purpose of these questions isn't to find an agency that answers them perfectly it's to find one that engages with them honestly. An agency that says "we don't have a formal target coverage percentage for tests but here's how we think about testing quality in practice" is being more useful than one that names a number they may not actually hit. What you're evaluating across all ten questions is the same underlying thing: whether this agency has thought carefully about how they do their work, and whether they can explain that thinking clearly to someone who will depend on it.
How many agencies should I evaluate before deciding?
Three to four is a practical number enough to give you genuine comparison points without the evaluation process becoming a project in itself. Use the same questions with each agency so you're comparing answers on equivalent terms, rather than being swayed by whichever agency you spoke with most recently or who had the most polished deck.
Should I ask these questions by email or in a call?
A call, ideally with video. Written responses to these questions can be prepared and polished in ways that verbal responses can't on a call you can ask follow-up questions when an answer is vague, and you get a much more accurate read of how the agency actually communicates. The communication quality in the evaluation process is itself a preview of what the engagement will be like.
Is it reasonable to ask for a paid trial before committing to a full engagement?
Yes and a strong agency is comfortable with it. A paid discovery or initial sprint (2–4 weeks, focused on a defined piece of real work) lets you evaluate the agency on actual output rather than proposals. If an agency is resistant to a trial period or insists on a longer minimum commitment before you've seen their work, that resistance is worth factoring into your evaluation.
What if the agency can't answer some of these questions?
An inability to answer some questions specifically particularly around testing, documentation, and security isn't automatically disqualifying if the agency is otherwise strong. What matters is how they respond: do they engage thoughtfully with the question, acknowledge a gap, and explain how they'd address it for your project? Or do they deflect? The former suggests a team that thinks honestly about their process; the latter suggests one that doesn't.
Do these questions apply to freelance developers as well as agencies?
Most of them, yes with some adaptation. Questions 9 (developer turnover) and parts of 4 (code review) are more agency-specific, since a solo freelancer is the only developer. For freelancers, the equivalent of question 9 is "what happens if you become unavailable mid-project" which is worth asking explicitly, since a solo freelancer has no bench to draw on if they're ill, take on competing work, or simply disappear.
