How to Hire a Web App Developer Without Getting Burned

The short answer on how to hire a web app developer is that the rate you negotiate matters far less than the paperwork you sign and the accounts you own. People rarely get burned because a developer was expensive or cheap. They get burned because, nine months in, the copyright still belongs to the developer, the repository lives in someone else's account, the domain is registered to a person who no longer answers email, and nobody can deploy the application without that one person's laptop.

All four of those are fixable in a single afternoon before work starts. None of them are fixable afterwards.

This article gives you the things that actually decide the outcome. A sizing rule that picks your hiring model from the volume of work rather than your budget. Cost math built from federal wage data so you can tell a real quote from a fantasy one, including a break-even model for the offshore question that probably contradicts what you have read. The contract clauses that control who owns the code, with the statutes behind them. A day-one account setup list. And a 14-point handoff readiness checklist you can run before every milestone payment.

Key takeaway: A "work made for hire" clause does not, by itself, transfer the copyright in software. Software is not one of the nine commissioned-work categories in the Copyright Act, so you need an express written assignment signed by whoever owns the rights. Check your contract for the word "assigns" today.

How to hire a web app developer: size the work before you pick a model

Most buying advice starts with your budget or your company stage. Start instead with the volume of engineering work you expect over the next two years, because that is what determines whether a model is sustainable.

Two things in that table catch people out.

The first is the internal reviewer. If nobody on your side can read a pull request, judge an estimate or say "this is not done," then a contractor engagement quietly converts into an agency engagement where you are supplying the project management for free and doing it badly. Clutch's own comparison makes the same distinction in softer language: agencies bring project managers and QA, freelancers do not. That is the real product difference, and it is worth paying for when you lack it.

The second is that "in-house is cheaper" is usually false at small volumes, for reasons the next section makes concrete.

What does a web app developer actually cost in the US?

There are two useful anchors: what the market quotes, and what the labor actually costs. Compare them and most pricing confusion disappears.

What the market quotes

Upwork publishes its own rate bands on its web developer cost page: "Web Developers on Upwork Cost $15–$50/hr," broken down as $15–$25 an hour for entry level, $30–$50 for intermediate and $50–$200 for expert. That is a marketplace with a global supply base, so treat the low end as a statement about geography and seniority rather than a benchmark for anyone local.

What the labor costs

Federal data gives you a floor that no US vendor can go under for long.

• The median annual wage for web developers and digital designers was $99,520 as of May 2025, or $47.85 an hour, according to the BLS Occupational Outlook Handbook.
• Software developers, a more senior and more application-focused category, had a median annual wage of $135,980 over the same period, with QA analysts and testers at $104,300 (BLS).
• Wages are not the whole cost. Benefits averaged 30.0 percent of total compensation for private industry workers in June 2026, with total compensation at $46.89 an hour against $32.82 in wages and salaries (BLS Employer Costs for Employee Compensation).

Grossing up the median web developer wage for that benefits share gives a fully loaded employer cost of about $142,000 a year, or $68 an hour across 2,080 paid hours. Doing the same for a software developer gives about $194,000, or roughly $93 an hour.

Key takeaway: Paid hours are not productive hours. Subtract about 15 percent for holidays, vacation and sick time, then about 20 percent of what remains for meetings, administration and learning, and 2,080 paid hours becomes roughly 1,414 productive engineering hours. At $142,000 loaded, that is about $101 per productive hour for a mid-level in-house web developer.

That number reframes everything. An in-house mid-level developer costs about as much per hour of real work as a mid-tier agency, and you carry the recruiting, management and retention risk on top. In-house wins when you have enough work to keep the person busy for years and the accumulated product knowledge is itself valuable — not because the hourly math is better.

It also tells you what a US agency quote has to clear. If direct loaded labor is $68 to $93 an hour and a developer bills roughly 70 percent of their paid hours, direct labor per billed hour is already $98 to $133 before any sales, project management, QA, tooling or profit. A US-based agency quoting $75 an hour with US-based engineers is either not paying median wages, subcontracting the work elsewhere, or not making money. Any of those is worth knowing before you sign.

The benefits percentage above is an all-industry private-sector average, not a technology-sector figure, so treat it as an approximation. The direction of the error is conservative: tech benefits packages tend to be richer, not thinner.

A rate card you can budget against

For a typical internal or customer-facing web application — authentication and roles, 10 to 15 screens, two integrations, reporting, and a payment flow — plan on 1,000 to 1,400 hours of engineering, plus design and QA. Here is what that costs at different rates.

Add 10 to 20 percent of the build effort per year for maintenance, dependency upgrades and small changes. If you want the cloud side of the budget, our breakdown of why an AWS bill climbs faster than anyone expects covers the run costs this table excludes.

Is cheap development really more expensive? Run the break-even

The standard warning is that a cheap build costs more once you count the rewrite. Run the arithmetic and that turns out to be a weaker claim than it sounds, which is worth knowing because it explains why so many sensible people keep hiring at $28 an hour.

Take 1,200 hours of work. A competent US team at $130 an hour costs $156,000. Now suppose a $28-an-hour team needs 30 percent more hours for the same output, so 1,560 hours at $28 is $43,680. Let f be the fraction of that output a US team later has to rebuild at $130 an hour.

On money alone, the cheap route stays ahead until roughly 72 percent of it has to be thrown away. Assumptions: a 1.3x hours multiplier, rebuild work priced at the US rate, and no change in scope. Move any of those and the break-even moves, so treat this as a model for your own numbers rather than a finding.

So where does the money actually go wrong? Three places, none of them the hourly rate.

Calendar time. If the application saves or earns $20,000 a month, six months of extra delay costs $120,000 — more than the entire rate difference above. Write down what a month of delay is worth to you before you optimize for rate. It is usually the largest number in the decision.

Your attention. Cheap engagements consume senior management time in specification, review and rework coordination. That time has a real cost and it does not appear on any invoice.

Total loss. The genuinely expensive outcome is not a bad build; it is no build. You cannot get the source code. The copyright was never assigned. The cloud account is in someone else's name. You pay full price a second time and lose the year. That failure mode is governed entirely by the contract and the accounts, which is why the rest of this article is about those.

Who owns the code? The law is less intuitive than the contract implies

This is the question buyers get wrong most often, and the answer sits in three sections of the Copyright Act.

Copyright starts with the author, not the payer. Under 17 U.S.C. § 201(a), "Copyright in a work protected under this title vests initially in the author or authors of the work." Paying an invoice does not move it.

"Work made for hire" has two halves, and only one of them helps you. Section 101 defines a work made for hire as, first, "a work prepared by an employee within the scope of his or her employment"; and second, a work "specially ordered or commissioned" in one of nine listed categories — a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas — and only "if the parties expressly agree in a written instrument signed by them."

Read that list again. Computer software is not on it. A web application commissioned from an independent contractor cannot be a work made for hire under the second half, no matter what the contract says. And whether your developer is an "employee" for this purpose is not something you get to label: in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), the Supreme Court held that a court "first should ascertain, using principles of general common law of agency, whether the work was prepared by an employee or an independent contractor," weighing factors such as skill, who supplies the tools, where the work happens, payment method, benefits and tax treatment. An outside developer working from their own equipment on their own schedule will land on the contractor side of that test. The U.S. Copyright Office covers the same ground in Circular 30.

So you need an assignment, in writing, signed. Section 204(a) is blunt: "A transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed or such owner's duly authorized agent."

None of this is legal advice, and the drafting should go through your counsel. But it does tell you exactly what to search your draft agreement for: the word assigns, in the present tense, covering copyright in all deliverables. A contract that only says "all work product shall be a work made for hire" can fail on the single asset you were buying.

Three more ownership traps in ordinary contracts

Assignment conditioned on payment. This is the market standard, and it is reasonable — but you should know it applies to you. Upwork's Optional Service Contract Terms, effective November 21, 2025, state that "Upon Freelancer's receipt of full payment from Client, the Work Product … will be the sole and exclusive property of Client," and that "If payment is made only for partial delivery of Work Product, the assignment described herein applies only to the portion of Work Product delivered and paid for." Practical consequence: in a payment dispute, you own the paid-for parts and nothing else. Keep milestones small so a disagreement never strands a large unpaid chunk of your application.

Chain of title. An agency can only assign rights it holds. If its own engineers or subcontractors never signed assignments, the agency has nothing to give you. The same Upwork terms handle this by requiring that a freelancer who subcontracts "has entered into agreements with any such employees and subcontractors on confidentiality and intellectual property at least as strong as those in these Optional Service Terms." Ask for that representation and warranty by name.

Pre-existing and open-source components. Every real application includes third-party code. You need to know what, under which licenses, because some licenses obligate you to release your own source. Upwork's terms require a "bill of materials that identifies all Background Technology and other third-party materials" with the name, version, license and how each is used, and bar code whose use would require that the work product "be disclosed or distributed in source code form" unless agreed. Copy that requirement into your own agreement and ask for the bill of materials at every milestone, not at the end.

The nine clauses that decide whether you get burned

Hand this list to whoever reviews your contracts.

Two of these deserve a closer look because almost nobody gets them right.

The confidentiality clause nearly everyone drafts wrong

If your agreement governs the use of trade secrets or confidential information, federal law requires you to include a specific notice. 18 U.S.C. § 1833(b)(3) provides that "An employer shall provide notice of the immunity set forth in this subsection in any contract or agreement with an employee that governs the use of a trade secret or other confidential information," and that if the employer fails to do so, "the employer may not be awarded exemplary damages or attorney fees" in a Defend Trade Secrets Act action against that person. Critically, the statute defines "employee" to include "any individual performing work as a contractor or consultant for an employer."

In plain terms: your developer NDA needs a short paragraph telling the developer they are immune from liability for confidentially reporting a suspected legal violation to a government official or attorney, or for filing a trade secret under seal in court. Leave it out and you keep the confidentiality obligation but lose two of the remedies that make it worth enforcing. It costs one paragraph.

Acceptance criteria with a security baseline

"The vendor shall use industry best practices" is unenforceable. Name a standard.

Two public references are good enough for almost any mid-sized company, and both are free. The OWASP Top 10:2025 lists the categories an application review should cover: Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions. NIST's Secure Software Development Framework, published as SP 800-218 version 1.1, organizes practices into four groups — Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities — which maps neatly onto what you should expect to see evidence of.

The FTC's Start with Security guide makes the same point to businesses from the enforcement side: train engineers in secure coding, test for common vulnerabilities using frameworks like OWASP, verify that privacy and security features actually work, and make sure your service providers implement reasonable security measures — including verifying compliance rather than taking it on contract language alone.

If your application touches regulated data, that bar rises considerably, and the engineering work is only part of the cost. Our AI compliance work covers the documentation side for regulated industries, and the HIPAA development checklist shows how much of the effort in a regulated build is evidence rather than code.

Data processing terms, if personal information is involved

If the application handles personal information about California residents and you are a covered business, California Civil Code § 1798.100(d) requires an agreement with your service provider or contractor that does five things: specifies that the information is disclosed only "for limited and specified purposes"; obligates them to comply with the law and "provide the same level of privacy protection" it requires; grants you rights to take "reasonable and appropriate steps" to verify their use is consistent with your obligations; requires them to notify you if they can no longer meet those obligations; and gives you the right, on notice, to "stop and remediate unauthorized use."

Other states impose comparable requirements. Which laws apply to you is a question for your counsel, but the structural point holds everywhere: a developer who touches your customer data needs processing terms, not just an NDA.

Day-one account setup, and the 14-point readiness checklist

The paperwork protects you legally. Owning the accounts protects you practically, and it is faster.

Do this before work starts, yourself:

1. Create the source-control organization in your company's name, then invite the vendor as a member with write access. Not the reverse. GitHub does support transferring a repository later — issues, pull requests, wikis, stars, webhooks and history move with it, and old links redirect — but it needs administrator access on the source side and permission to create a repository on the target side. In other words, it needs the vendor's cooperation. Start in the right place and you never need it.
2. Open the cloud account under your company billing. Give the vendor scoped access, not the root credentials. This also means the spend is visible to you from the first day rather than arriving as a line item on an invoice.
3. Register the domain yourself, at your own registrar. Changing the registrant later triggers a transfer lock: ICANN's Transfer Policy provides that "The Registrar must impose a 60-day inter-registrar transfer lock following a Change of Registrant," though a registrar may let the holder opt out beforehand. As of October 2026 that is the policy in force, updated in February 2024 with a compliance deadline of August 2025, and ICANN has approved changes that would revise this process — check the current text when it matters to you. Either way, a 60-day window where you cannot move a domain is a bad thing to discover during a vendor dispute.
4. Stand up a secrets vault you control and require that API keys, signing certificates and database credentials live there rather than in a developer's password manager.
5. Open analytics, payment processor and transactional email accounts in your company's name, then grant access. These are the quiet ones. People remember the repository and forget that the Stripe account and the sending domain reputation are also assets.

Then run this at every milestone, not at the end:

The last three items are the ones that separate a working application from a demo. A new engineer should be able to clone the repository and run the application locally from the written instructions. Deployment should be a scripted pipeline rather than a person with a laptop. And someone should have restored the database from a backup and written down how long it took. If any of those three is a "no," you do not have a deliverable yet, whatever the demo looked like.

How to vet a web app developer before you commit the budget

Portfolios tell you what a vendor has been near, not what they did. Here is what to substitute.

Ask for a repository walkthrough, not a demo. Request a 45-minute screen share of a codebase they own, with permission. You are looking for commit history that shows incremental work rather than three giant drops, tests that exist and run, a README a stranger could follow, and configuration separated from code. You do not need to read the code yourself; you need to watch how they talk about it.

Ask how they would find out they were wrong. Good answers involve a spike, a prototype, a load test or a conversation with your users. Weak answers go straight to a technology choice.

Ask for the estimate behind the estimate. A number with no breakdown is a guess. Ask which parts they are confident about and which they are not, and what would make the uncertain parts worse. Vendors who name their own risks are telling you they have been burned before and learned something.

Call a reference that did not go well. Ask directly: "Tell me about a project that went badly and what you changed." Then ask to speak to that client. Refusal is informative; so is a candid account.

Check how they handle AI-written code. This is new and it matters. Stack Overflow's 2025 Developer Survey, with over 49,000 responses from 177 countries, found 84 percent of developers use or plan to use AI tools, up from 76 percent in 2024, while 46 percent said they do not trust the accuracy of AI output, up sharply from 31 percent the year before, and 45 percent cited time-consuming debugging of AI-generated code as a key frustration (Stack Overflow). The right answer from a vendor is neither "we don't use it" nor "it writes most of our code." It is a review and testing policy: who reviews generated code, what tests must pass, and how license provenance is handled.

Then buy a small piece of the real work. A paid one-to-two-week engagement on a genuine slice of your application beats every other signal combined. You see their questions, their estimate against reality, the shape of their commits, and whether the handoff artifacts exist. If the trial produces something you can run and a specification you understand, you have learned what six reference calls cannot tell you. We use the same logic for AI agent engagements, where a working prototype in one to two weeks replaces a lot of arguing about architecture.

Red flags, ranked by what they cost you

Worker classification: don't accidentally hire an employee

One more thing worth 10 minutes of attention. If you engage a contractor full time, direct their hours, supply their equipment and integrate them into your team, you may have created an employment relationship regardless of what the agreement says.

The IRS weighs three categories of common-law factors: behavioral control ("Does the company control or have the right to control what the worker does and how the worker does his or her job?"), financial control (who provides tools, how payment works, expense reimbursement), and type of relationship (written contracts, benefits, duration, and whether the work is integral to the business). The agency is explicit that there is no "magic" or set number of factors, and that you have to weigh the entire relationship. Either party can ask for a determination using Form SS-8 (IRS).

Practically: keep contractor engagements organized around deliverables and statements of work rather than hours and attendance, and confirm your own situation with your counsel or payroll advisor before you structure a long full-time engagement as contracting. Note that the test for employment is also the test that decides work-made-for-hire status, so answering it clearly helps you twice.

When not to hire a developer at all

Three honest cases where the right answer is to stop.

You have not validated the problem. If you cannot name the specific task someone does today, how long it takes, and how often, you are not ready to commission software. Spend two weeks watching the work instead.

Off-the-shelf covers 80 percent of it. Custom software earns its keep on the parts of your business that are genuinely yours. Our guide to replacing spreadsheets with custom software lays out the specific conditions that justify a custom build and the four cheaper options to try first.

Nobody internally will own it. Applications need a person who decides what changes and answers questions. Without that, a well-built app decays into a system nobody trusts within a year. Name the owner before you name the vendor.

What to do next

Hiring a web app developer well comes down to four decisions, in this order. Size the work and pick the model from the volume, not the budget. Price the work against the labor floor so you can recognize a quote that cannot be real. Get the paperwork right — an express assignment, chain of title, a bill of materials, confidentiality with the DTSA notice, data processing terms, and a priced exit. Own the accounts from day one and run the handoff checklist at every milestone.

Do those four things and the worst realistic outcome is a project that disappoints you, which is recoverable. Skip them and the worst outcome is a project that takes your money, your year and your source code, which is not.

If you want a second opinion on a scope, a quote or a contract before you sign it, talk to a specialist. We build custom web apps and software for US companies, a specialist replies within one business day, and the discovery call is free. Bring the statement of work you were sent; the gaps are usually in the same three clauses.