Outsourcing C# and .NET Development: What to Specify Before You Hire
Most outsourced C# projects that struggle were not hired badly. They were briefed badly. "We need three .NET developers" can mean a new application, a rescue of someone else's code, or a long-overdue move off an older framework, and a provider will answer each very differently. The fix is to be specific before the first conversation.
This guide lists what to settle, in the order that matters.
1. What kind of work this is.
Start with the type of work, because it decides almost everything else. There are four common cases: building something new, extending a system that is live, maintaining a system that works but needs ongoing attention, and modernizing an older system onto a current platform. Each needs different people, different habits and a different definition of success. If you are not sure which you are buying, say so and describe the symptoms instead.
2. What the stack actually is.
"We use .NET" is not enough. State the framework and version: modern .NET, or the older .NET Framework. Name the web layer (ASP.NET Core, MVC, Web Forms, or something older such as classic ASP or VB), the database and its version, the front end, and where it runs: your own servers, Azure or another cloud. A provider needs this to know whether the work is routine or whether it will meet old technology that few engineers still know.
3. What state the codebase is in.
Be honest about the condition. Is there documentation? Are there automated tests, and do they pass? How long does a build take, and does it succeed on a clean machine? Who understands the system today? A codebase with no tests and one departed author is not a reason to avoid outsourcing, but it changes the plan, the team and the first phase. Providers should offer to review the code before committing to a scope. BlastAsia does this for existing .NET systems, including modernization of older VB and classic ASP applications. For the broader decision, see refactor or replatform.
4. What the team should look like.
Decide which roles you need: developers, a business analyst, QA, a team lead. A cross-functional team with analysis and testing built in is easier to direct than a group of developers you have to supplement yourself. Say how many people, at what seniority, and how long you expect the work to continue. A dedicated team works as an extension of yours, assigned to your product and not shared with other clients.
5. How the work will be run.
Specify the rhythm. Short sprints with working software at the end of each are a good default; BlastAsia works in two-week sprints. State how work is prioritized, who accepts it, how progress is shown, and how often you expect to meet. If you already run Scrum or Kanban, say so, and ask the provider to work in your process, not alongside it.
6. Which standards the code must meet.
Put your standards in writing: coding conventions, branching and review rules, testing expectations, static analysis, security requirements, and how builds and releases happen. If a provider is going to work in your repositories, it should follow your rules, not bring its own. Where you have none, agree them up front and write them down.
7. What access and environments they need.
Decide early who gets access to what: source control, ticketing, build servers, test environments, and any data. Be specific about data. Production data with personal or financial information needs rules about where it can go and who can see it. Delays in access are one of the most common reasons the first sprint slips.
8. How quality will be judged.
Define what "done" means. Acceptance criteria written per feature, automated tests that must pass, a review step, and a clear owner on your side who accepts the work. Without these, quality becomes a matter of opinion at the end.
9. Who owns the code and the knowledge.
Write down that you own the source code, the intellectual property and the documentation, and that the work lives in your repositories from the first day. Ask about handover: what documentation and knowledge transfer you will get if the engagement ends or the team changes. Knowledge that lives only in the heads of the outsourced team is a risk.
10. How you will communicate.
State the working hours you need to overlap, the tools you use, and who talks to whom. Engineers should be able to speak to your product owner and to each other directly. The Philippines is UTC+8, which suits Asia and Australia well and gives planned overlap with Europe and North America. We cover this in our post on offshore software development in the Philippines.
Red Flags in a Response
A provider that does not ask about your codebase before quoting is guessing. One that cannot tell you who will actually do the work, or that changes the team after the contract is signed, is hard to manage. One that is vague about ownership or handover is a risk you will meet later. And one that promises a scope and a team without having seen the system has not yet done the thinking you are paying for.
A One-Page Brief
Before you contact a provider, try to fill in one page: the type of work, the stack and versions, the condition of the code, the team you expect, the working rhythm, your standards, the access you will give, the definition of done, the ownership terms and the communication plan. Even a partial page makes the first conversation more productive and the proposals easier to compare.
If you are planning to outsource C# or .NET work and want help shaping the brief, see our page on outsourcing C# and .NET development, or tell us about the system and what you need done, and we'll help you scope it.
About BlastAsia: BlastAsia is a Philippines-based software company that builds AI-powered software for enterprises worldwide, whether it's a new application or AI layered on the systems you already run. We build it AI-natively: specifications first, with code generated and reviewed on the Xamun Software Factory, so delivery is faster and more predictable. Engage us as a dedicated team (xDD) or as a fixed-scope Turnkey build, and you own what gets built.
Comments