developer.law / Knowledge

Hiring Developers in 2026: Contractor Classification, NDAs, and Non-Solicits

The four issues that come up every time you staff a project: classifying who you hire, protecting confidential information, keeping clients from poaching your team, and picking the right entity and insurance.

What is developer classification, and why does it matter?

When you bring a developer onto a project, you are not free to simply decide whether they are a contractor or an employee. Federal and state law makes that determination based on the actual working relationship, not the label on your agreement or the form you issue at tax time.

The IRS uses its common law control test, the Department of Labor uses an economic reality test, and more than 20 states now apply an ABC test with strict requirements a worker must satisfy before they can legally be treated as a contractor. Getting this right from day one matters because the exposure from a wrong call compounds every week the relationship continues. developer.law builds a purpose-built framework for capturing classification-friendly facts inside every subcontractor agreement, so the contract reflects the actual relationship rather than creating a paper mismatch that invites scrutiny.

Why contractor classification matters more in 2026

Misclassification has been the IRS's top enforcement priority for several years running, and the agencies involved don't act independently. When the IRS identifies a misclassified worker, it routinely shares that finding with the DOL and relevant state agencies, triggering a multi-front audit. For a small dev shop working with several developers simultaneously, one finding can cascade into a review of every worker relationship in the business.

The 2026 landscape adds complexity on top of that. Revenue Procedure 2025-10 updated the framework governing Section 530 relief — the safe harbor that can reduce penalties when a business had a reasonable basis for its classification decisions. The 2024 DOL Final Rule introduced a six-factor economic reality test that runs parallel to the IRS analysis. And in states like California, Massachusetts, and New Jersey, the ABC test is the operative standard, meaning that even a developer who clearly passes the IRS common law test may still be treated as an employee under state law. A shop with developers in multiple states has to apply each state's test independently.

Common classification challenges dev shops face

Most owners understand they need contractor agreements. The harder problem is that the working relationship often drifts away from what the agreement describes — and agencies look at reality, not paperwork.

Behavioral control creep. A developer engaged for a defined deliverable gradually absorbs internal responsibilities — daily standups, internal processes, working exclusively for the shop over an extended period. The IRS and DOL read this pattern as evidence of employment regardless of what the contract says.
Tool and equipment dependency. When a developer exclusively uses the shop's software licenses, cloud environments, or hardware, that financial-control factor tilts toward employee status. Contractors in a genuine independent relationship typically provide their own tools.
Single-client relationships. A developer who works only for your shop, with no other active clients, lacks one of the clearest markers of independent contractor status — the IRS and DOL both treat economic dependence on a single payer as significant.
The ABC test B-prong problem in California. California's Dynamex standard requires that the work a contractor performs fall outside the hiring company's usual course of business. A software development agency generally cannot satisfy that requirement when it hires a software developer for software development work — one of the most consequential rules for tech shops operating in or with developers located in California.

The fix isn't to avoid contractors — it's to structure the relationship from the start to reflect genuine independence: project-based scope, deliverable-oriented milestones, contractor-controlled schedules, an explicit right to work for other clients, and contractor-supplied tools. Those facts need to be in the contract before the first day of work.

What to look for in a subcontractor agreement

A subcontractor agreement that holds up under IRS or DOL review documents the structural facts of the relationship in the contract language itself, not just a label.

Project-scope definition. Define work by deliverable, not by hours on-call or general availability — an outcome-oriented engagement rather than a continuous service arrangement.
Right to control means. State explicitly that the developer controls how the work gets performed. The IRS common law test examines behavioral control first, and language reserving the right to direct methods and processes is the single most damaging provision a subcontractor agreement can include.
Multi-client permission. State that the developer is free to provide services to other clients during the engagement — this one provision addresses both the financial-control and relationship factors at once.
Contractor-supplied tools. Identify that the developer provides their own development environment, hardware, and software licenses where applicable.
IP assignment and work made for hire, together. Software created by an independent contractor doesn't automatically fall into the statutory categories that qualify for work-made-for-hire status, so every agreement needs a present-tense IP assignment as a backup — without it, the developer retains copyright regardless of who paid, which creates a chain-of-title problem that surfaces in diligence or client disputes.
Confidentiality. Not optional — your developers have access to client specifications, proprietary processes, and source code. Define confidential information specifically, and make the obligation survive termination.
No-conflict and independent-status recital. A recitation that both parties intend an independent contractor relationship and that the developer isn't entitled to employee benefits. This doesn't control the classification outcome, but it documents a baseline of intent.

Protecting IP and keeping deliverables clean

A client hires your shop to build software. Your shop hires a developer to do the work. If the subcontractor agreement doesn't include a proper IP assignment, the developer may own the copyright to the code your client believes they're buying — that's the default result under U.S. copyright law when a business fails to obtain a written assignment from an independent contractor.

The dual-clause approach. Combine a work-made-for-hire clause with a present-tense assignment clause in every agreement. The work-made-for-hire clause attempts to fit the deliverable into the statutory category; the assignment clause transfers ownership directly as a fallback for anything that doesn't qualify. Both need to be signed before any work begins.
Pre-existing IP and background technology. Developers often bring pre-existing libraries or components into a project. The agreement needs to give the shop either a license to use that background technology in the deliverable or a restriction on incorporating it — otherwise your client may receive a deliverable containing code they don't own and can't use commercially without a separate license. See what's background technology for the full carve-out mechanics.
Confidentiality scope. Define "confidential information" to cover client identity, project specifications, technical architecture, business logic, and source code — broad definitions like "any potentially sensitive data" are harder to enforce than definitions tied to a specific project.
Downstream obligations. If your developer will engage sub-subcontractors or assistants, require that those individuals are bound by equivalent confidentiality and IP assignment obligations — one unbound downstream contributor can create a gap in the chain of title.
Residuals and return of materials. Require that all work product, documentation, and credentials are returned or destroyed at the end of the engagement — this matters most when a relationship ends poorly.
Survival. Confirm explicitly that IP assignment and confidentiality obligations survive termination — a gap often left in generic templates.

NDAs before scoping calls: when you need one and what it should cover

The question comes up before almost every new engagement: do you need an NDA before discussing the project? Yes, with one practical condition — the NDA needs to be in place before confidential information is exchanged, not after.

A scoping call is a substantive conversation. The client shares product ideas, architecture decisions, and competitive context; your shop shares team structure, internal processes, and sometimes proprietary methodology. Both sides are disclosing information they don't want the other to use without permission, and a mutual NDA executed before the call is what makes genuine disclosure possible.

Mutual coverage. A one-way NDA that only covers the client's information leaves the shop exposed — your approach, team composition, and internal processes deserve the same protection.
A specific definition of confidential information. Include technical architecture, business models, proprietary processes, internal project structure, and team composition — a definition tied to the specific purpose of the engagement is more defensible than a vague one.
Permitted disclosures. Identify who within each party can receive confidential information, and what obligations they carry — if your developer hears client details during scoping, the NDA needs to cover that downstream disclosure.
Exclusions. Standard carve-outs for information already public, independently developed, or received from a third party without restriction protect both sides from overreach.
Duration. Two years from the date of disclosure is a common, reasonable term for software project NDAs. Trade secret obligations should survive longer.
AI usage restrictions. A 2026 NDA should address whether either party may input confidential information into AI tools — a relatively new exposure legacy templates don't cover.
Dispute resolution. Arbitration is faster and more private than litigation for confidentiality disputes, which is usually what both sides want.

Keep it short, plain, and easy to sign electronically. A two-page document that covers the core terms gets signed faster than a ten-page agreement with extensive carve-outs.

Non-solicitation clauses: protecting your team from client poaching

Clients who work with your developers over the course of a project sometimes try to hire those developers directly at the end of the engagement — one of the most common business disruptions small dev shops face. A non-solicitation clause in the client-facing agreement addresses this directly: it restricts the client from soliciting or hiring anyone who worked on their project, without preventing them from hiring generally or preventing your developers from finding other work.

Duration. Courts generally view six months to two years as reasonable; beyond two years attracts scrutiny and is more likely to be modified or voided. A 12-month restriction is both practical and enforceable for most dev shop engagements.
Scope of covered individuals. Define the restricted pool as people who worked directly on the client's project, not every employee or contractor in the shop — broader restrictions are more likely to be challenged as overbroad.
Definition of solicitation. Name the prohibited conduct specifically — recruiting, hiring, and encouraging departure. Vague language like "contact" is harder to enforce and may unintentionally prohibit innocent networking.
Geographic scope. For most remote dev shops, geography isn't the operative limitation — don't add a restriction that adds complexity without benefit unless you operate in defined markets.
Legitimate business interest. Courts require the clause to protect a genuine business interest rather than suppress ordinary competition — a dev shop has one: the relationship was built on the developer's skills, client knowledge was shared during the engagement, and replacing a poached developer mid-project causes real operational harm.
Consideration. The clause must be supported by adequate consideration — included in the services agreement at the start of the engagement, the engagement itself is the consideration. Adding it later, without something new in exchange, creates an enforceability problem.
State law variation. California doesn't enforce non-solicitation clauses tied to contractor relationships the way other states do; Massachusetts, New Jersey, and Illinois each have their own standards. Draft for the jurisdiction that will actually govern the agreement.

Key clauses in a dev shop client agreement

A clause-by-clause summary of what belongs in every client-facing agreement, generated together so the definitions stay consistent across the document.

Clause	Purpose	Key Drafting Note
Scope of Work	Defines deliverables and project limits	Tie to milestones, not open-ended availability
IP Assignment	Transfers ownership of work product to client	Must be a present-tense assignment; work-made-for-hire alone is not enough for contractor-created software
Confidentiality	Protects both parties' proprietary information	Define by category; include AI tool restrictions
Non-Solicitation	Prevents client from hiring the shop's team	12-month duration; limit to individuals who worked on the project
Payment Terms	Sets milestones, rates, and late-payment remedies	Tie payment to milestone acceptance, not calendar dates
Change Order Process	Controls scope creep	Require written approval before any out-of-scope work begins
Limitation of Liability	Caps exposure for each party	Cap at total fees paid; carve out IP and confidentiality breaches
Dispute Resolution	Sets process for resolving claims	Arbitration is generally preferred for IP and confidentiality disputes
Survival	Confirms which clauses survive termination	IP, confidentiality, and non-solicitation should all survive

Best practices for dev shop contracts and team protection

Execute agreements before work starts. IP assignment and confidentiality obligations are only as strong as the moment they were signed — a contractor who has already written code has leverage in any negotiation over IP terms.
Run a classification review on every engagement. The common law and ABC test factors aren't static — review each contractor relationship when scope changes, duration extends, or exclusivity increases.
Keep the subcontractor agreement and the client agreement aligned. If your client agreement assigns IP to the client, your subcontractor agreement must assign IP upstream to the shop — gaps in the assignment chain create title problems that are expensive to unwind.
Use mutual NDAs before every substantive sales conversation. It signals professionalism and sets the tone for how the engagement gets documented. A client who hesitates to sign a short mutual NDA is telling you something worth knowing before you share your approach.
Draft non-solicitation clauses for the jurisdiction that governs. A clause governed by California law faces a different enforceability standard than one governed by Texas or New York — choose your governing law clause with that in mind.
Build clause survival explicitly. Every services agreement should list the provisions that continue after the engagement ends — IP assignment, confidentiality, and non-solicitation matter most, and their absence is a gap practitioners exploit in disputes.
Document classification facts at engagement start. Keep a simple internal record for each contractor noting project scope, tools used, other clients, and schedule structure — a contemporaneous record is far more useful in an audit than a contract that doesn't match the real relationship.

Entity structure and insurance: the foundation underneath every contract

LLC vs. S-corp

An LLC provides liability protection and pass-through taxation with minimal administrative overhead — a single-member LLC reports on Schedule C, a multi-member LLC files a partnership return, and it works well for a shop in its early years or one with modest net profit after the owner's compensation.

An S-corp isn't a separate entity type — it's a tax election an LLC or corporation can make, and its core advantage is splitting income between a reasonable salary (subject to payroll taxes) and distributions (which aren't). As a general rule, the election starts producing meaningful savings once net profit exceeds the owner's reasonable salary by $40,000 to $60,000 or more; below that threshold, the compliance cost of running payroll and filing a separate corporate return can offset the tax savings. Start as an LLC, and when annual net profit above your salary consistently clears $50,000 to $60,000, model the S-corp election with a CPA familiar with service businesses.

Insurance

Insurance isn't optional. Most enterprise clients require proof of coverage before executing a services agreement, investors review it during diligence, and the exposure from a software bug, data breach, or misclassification claim can exceed what a small shop can absorb without it.

Technology E&O is the foundational policy — it covers claims that your software, advice, or services caused a client financial harm. Generic professional liability policies often exclude technology product failures, so a technology-specific form is necessary. Small shops typically pay $1,300 to $1,800 annually for a $1,000,000 per-occurrence limit.
Cyber liability responds when your shop experiences a data breach, ransomware attack, or other security event — breach response, forensics, legal fees, notification expenses, and business interruption. It's often bundled with Tech E&O into a single policy, typically the most cost-effective structure for a small shop.
General liability covers bodily injury and property damage — required by most leases and many client agreements as a baseline, but it does not cover professional negligence claims, which is why Tech E&O is a separate, non-negotiable policy rather than a substitute.
Workers' compensation is required in virtually every state if you have W-2 employees. If your team is genuinely independent contractors this may not apply, but a misclassified worker injured on the job can create exposure you didn't anticipate.

How developer.law simplifies contracting for dev shops

Subcontractor agreements, client services agreements, mutual NDAs, IP assignment, non-solicitation provisions, and classification-compliant language all need to work together as one system. developer.law generates the full stack — jurisdiction-aware, so the non-solicitation clause in a California-governed agreement reflects California's enforcement standards and the classification language reflects the ABC test where it applies.

Consultant — $69/mo — subcontractor agreements that flow your client obligations downstream, with NDAs and IP assignment attached, for shops up to 3 owners and 3 employees.
SMB — $99/mo — the same hiring and vendor process at scale, across unlimited owners, clients, and subcontractors.

FAQs about hiring developers

Q: Are the developers I hire contractors or employees, and how do I classify them?

A: It depends on the actual working relationship, not the label in your agreement. The IRS applies its common law control test, examining behavioral control, financial control, and the type of relationship. More than twenty states apply a stricter ABC test — in California, a software developer performing software development work for a software company generally cannot qualify as a contractor under the ABC test's B-prong. developer.law's subcontractor agreements are structured to document the classification-supporting facts that survive scrutiny under both federal and state standards.

Q: What happens if I misclassify a developer as a contractor?

A: Exposure comes from multiple agencies simultaneously. The IRS can assess penalties starting at $50 per unfiled W-2 and up to 40% of unpaid FICA taxes, plus 100% of the employer share for intentional violations, and it routinely shares findings with the DOL and state agencies. Total exposure for a single misclassified worker commonly runs from $15,000 to $100,000 or more depending on duration and willfulness, and the IRS may audit up to six years of records.

Q: Do I need an NDA before discussing a software project with a potential client?

A: Yes. A pre-scoping NDA protects both parties during a conversation where real confidential information gets exchanged — your shop's processes and team structure, the client's product specifications and business model. It should be mutual, define confidential information by category, address downstream disclosure to team members, and in 2026 include explicit language on AI tool usage restrictions.

Q: What should a subcontractor agreement for developers include?

A: A project-based scope tied to deliverables rather than hours; contractor control over work methods; explicit permission to work for other clients; contractor-supplied tools language; a work-made-for-hire designation combined with a present-tense IP assignment; a confidentiality clause that survives termination; pre-existing IP provisions; and an independent contractor recital. developer.law generates all of these together in a single, jurisdiction-aware document.

Q: How do I add a non-solicitation clause so clients can't poach my developers?

A: Include a non-solicitation clause in your client services agreement that restricts the client from directly soliciting or hiring any team member who worked on their project. Draft it with a 12-month duration, limit the covered individuals to those who actually serviced the engagement, define solicitation specifically to include recruiting and hiring, and tie it to the jurisdiction whose law you want to govern enforcement.

Q: Should my software development agency be an LLC or an S-corp?

A: An LLC is the right starting structure for most dev shops — liability protection, pass-through taxation, minimal administrative overhead. When net profit above the owner's reasonable salary consistently exceeds $50,000 to $60,000 a year, an S-corp election becomes worth modeling with a CPA, because it lets you split income between salary (subject to payroll tax) and distributions (which are not).

Q: What insurance does a small software development shop actually need?

A: Three core coverages. Technology E&O covers claims that your software or services caused a client financial harm, and is typically the most important policy a dev shop carries. Cyber liability covers breach response, ransomware, and notification costs. General liability covers bodily injury and property damage and is required by most leases and enterprise client agreements — but it does not cover professional negligence claims, so Tech E&O is a separate requirement, not a substitute.

Ready to hire without the exposure?

Subcontractor agreements with classification-supporting language, NDAs, and IP assignment already built in.

We're lawyers, remember? Please read this important note:

Story LLP is a law firm, and Story's lawyers built Aegis to deliver better, standard legal services at scale so founders can choose between top-tier specialized lawyers and standardized process automations that replicate those lawyers according to their needs and budget. By definition, a standardized process may not be perfect for you. Please review our Policies page to better understand the difference, as well as how we use AI and how we manage conflicts, privilege, etc.

As a law firm, we must screen clients for conflicts of interest, and we treat all correspondence with clients seeking legal advice as privileged and confidential to the maximum extent possible in consideration of any conflicts. However, Story's law firm or our Attorney Allies do not represent you or your company as your lawyer, do not have an attorney-client relationship with you or your company, and do not provide you with legal advice absent a formal Engagement Letter signed between you and the Story LLP law firm. Please don't confuse the free knowledge we offer on this site with legal advice for you.

Consultant — $69/mo SMB — $99/mo