How to Price QA Testing and Maintenance as a Freelance Developer

You estimate a feature at 40 hours, multiply by your rate, and send the quote. The implementation takes roughly 40 hours. Then you test mobile layouts, reproduce an intermittent API error, fix a regression, help the client review the release, and handle deployment. The project is technically successful, but the effective hourly rate is much lower than the number on the proposal.

That is a pricing problem worth solving before the next quote. Testing and maintenance become expensive surprises when they are left undefined. This guide shows how to turn them into visible assumptions, using a worked project estimate, a maintenance example, and a practical review process.

The figures below are hypothetical business-planning examples, not market-rate benchmarks or a recommended allowance for every project. A small brochure website and a payments application need different testing plans. The method is to price the work your project actually requires, then make its boundaries understandable to the client.

1. Separate your hourly floor from your project estimate

Your hourly floor and your delivery estimate answer two different questions. The floor asks what each billable hour needs to contribute toward your income target, expenses, and assumed tax reserve. The estimate asks how many hours the agreed work will consume.

For a concrete example, assume an $81,750 annual take-home goal, $500 in monthly business expenses, an illustrative 25% combined effective tax rate, 46 billable weeks, and 25 billable hours per week. The calculator's simplified model gives:

Required annual revenue = $81,750 / (1 - 0.25) + $6,000
                        = $115,000
Annual billable hours   = 46 x 25 = 1,150
Hourly floor            = $115,000 / 1,150 = $100

The 25% input is an assumption for this example, not a determination of anyone's federal, state, or self-employment taxes. See our tax-reserve planning guide for the model's limitations.

A $100 floor does not mean a 40-hour implementation is a complete $4,000 project. You still need to estimate discovery, testing, review, and release work. Equally, a thorough project estimate does not make an unsustainable hourly floor adequate. Review both sides of the equation.

2. Count testing time once, in the right place

There are several legitimate ways to describe QA commercially. Under a time-based arrangement, you may bill agreed testing work as hours. In a fixed-price project, those hours can be included in the fee even if the client never sees a separate “QA” invoice line. The important question is whether the quote recovers the time.

General business administration belongs in your capacity planning. Testing performed to deliver a particular client's project belongs in that project's estimate. A common mistake is to treat every non-coding activity as non-billable overhead, then hope a higher hourly rate quietly covers an unknown amount of delivery work.

The opposite mistake is double counting. If you already included eight hours of project QA in a fixed fee, do not add a second undefined testing surcharge for the same hours. If your capacity model excludes testing hours, check how those hours are recovered before also including them in billable project time.

• Business overhead: your own bookkeeping, general marketing, and other work needed to run the practice.
• Project delivery: implementing, testing, reviewing, and releasing the client's agreed scope.
• Future service: maintenance and support after the initial engagement, with its own boundaries.

3. Build the QA estimate from failure scenarios

“Allow 20% for testing” is easy to put in a spreadsheet. It is harder to defend when nobody can say what that time is supposed to cover. A better starting point is a short list of important workflows, supported environments, and plausible failure conditions.

For a client portal, that list might include signing in, permission boundaries, form validation, uploading a file, handling a failed API request, and completing the central business workflow on the devices the client supports. An integration can also need checks for duplicate requests, timeouts, missing data, or a third-party service being unavailable.

Then separate activities that often get bundled together:

• Automated checks: writing and running focused unit or integration tests for important behavior.
• Manual verification: checking real workflows, responsive layouts, browser behavior, and relevant accessibility interactions.
• Regression testing: confirming that a change has not broken existing behavior the project depends on.
• Client review: preparing a review environment, reproducing feedback, and checking agreed acceptance criteria.
• Release verification: checking configuration, deployment, and critical behavior in the live environment.

Choose the coverage appropriate to the project's risks. A security-sensitive workflow may require specialist review beyond a general development engagement. The OWASP Web Security Testing Guide is a primary reference for web security testing. It does not provide a universal freelance pricing percentage, and citing it does not mean your project has received a complete security audit.

For each activity, record the environment, the expected result, and an estimated effort. If a major part cannot be estimated yet, put that uncertainty in front of the client rather than hiding it in a small allowance.

4. Work through a complete project estimate

Consider a small web-app engagement with 40 hours of implementation. For this example, the developer also estimates four hours of planning, six hours of automated testing, four hours of manual checks, three hours of client review, and three hours of deployment and handoff.

The ten testing hours equal 25% of the 40 implementation hours, but that percentage is a consequence of this estimate, not a rule for future projects. A different application could require substantially different coverage.

If you quote only $4,000 and deliver all 60 hours, your effective rate is about $66.67. That is one third below the example's $100 floor. You did not necessarily code too slowly. You sold 60 hours of delivery while pricing only 40 of them.

Effective hourly rate = project fee / actual delivery hours
$4,000 / 60 hours      = approximately $66.67 per hour

A $6,000 baseline covers those 60 estimated hours at the chosen floor. It is still not a guarantee of profit, a final market price, or an allowance for every possible change. Payment fees, additional risk, business margin, and the value of the work can affect the quote you ultimately choose.

5. Handle uncertainty explicitly

Suppose the estimate includes an unfamiliar integration. You identify a possible extra five hours of investigation or release work. At the example's floor, those five hours represent another $500 of capacity. A planning case with 65 hours therefore has a $6,500 baseline.

Be clear about how that uncertainty is handled commercially. A fixed fee, capped time-based budget, and separately approved investigation phase are different arrangements. An internal contingency does not automatically create an additional charge the client agreed to pay.

When uncertainty is concentrated in one unknown, a short discovery or technical investigation can be more informative than applying a broad percentage to the whole job. It may reveal constraints, clarify acceptance criteria, or show that the scope needs to change before a reliable fixed fee is possible.

The useful record is the reason behind the allowance: an undocumented API, unclear data quality, a difficult migration, or an environment you cannot yet reproduce. Keep that reason alongside the estimate so you can learn whether the allowance was appropriate after delivery.

6. Define maintenance before naming a monthly price

“Maintenance included” can mean almost anything. One client may expect dependency updates; another may expect new features, urgent incident response, hosting administration, and unlimited support messages. A low monthly fee becomes risky when it sits beside a large undefined promise.

Describe the service before you price it. Useful questions include:

• Which applications, environments, and dependencies are covered?
• Are monitoring review, routine updates, backups, and restoration checks included?
• How are requests submitted, prioritized, and approved?
• Does the service include feature development or only agreed maintenance activities?
• What response window is offered, during which working hours?
• How are emergencies, larger changes, unused time, and overages handled?
• Who pays hosting, licenses, API usage, and other third-party charges?

A response window is not the same as a resolution guarantee. Likewise, a monthly block of development time is not automatically round-the-clock availability. If a client needs reserved capacity or an urgent-response service, assess the scheduling commitment and your ability to deliver it before agreeing to the price.

7. Price maintenance using active work and its coordination cost

Imagine a maintenance service with six hours of routine engineering work per month and one hour for triage, communication, and reporting. At a $100 floor, seven hours produces a $700 monthly baseline.

For this example, the client pays infrastructure vendors directly. The $700 therefore does not include hosting, paid monitoring services, taxes on the sale, an emergency-response commitment, or unspecified additional work. It is a capacity-based starting point, not a recommended retainer for every developer.

Seven hours per month is 84 hours per year. If those hours come from the same 1,150-hour annual billable plan used earlier, they leave 1,066 hours for other client work. Include both the maintenance revenue and its capacity commitment when planning the year; do not sell that same time twice.

Tools can reduce some repetitive tasks without removing responsibility for the result. GitHub documents how Dependabot supports dependency alerts and update pull requests. A proposed update still needs a decision about compatibility, relevant testing, release, and whether it fits the agreed service. Budget for the workflow you actually perform.

8. Distinguish defects, changes, and ongoing support

A reported problem can be a defect against the agreed requirements, a newly requested behavior, a third-party change, or a configuration issue outside the original scope. Those categories should not be invented only when an uncomfortable invoice is due.

Before starting, agree how acceptance is assessed, how issues are reported, and how post-launch work is classified. Keep the practical distinctions understandable. For example, correcting an agreed validation rule that was implemented incorrectly differs from adding an entirely new approval workflow after acceptance.

This guide does not supply legally complete warranty or support terms. The operational point is to make the intended service explicit and obtain appropriate advice about the agreement itself. Avoid a promise of unlimited fixes or permanent compatibility unless you understand the obligation and have priced it accordingly.

9. Explain the quote in terms of delivery

A client does not need a lecture about your tax reserve to understand why testing appears in a project plan. Explain the activities that make the agreed feature usable: verifying key workflows, checking supported environments, addressing review feedback, and preparing the release.

A practical proposal outline might separate requirements, implementation, verification, release, and optional ongoing service. For each stage, describe the deliverable or acceptance evidence. That is more useful than a miscellaneous “extra time” line with no explanation.

When a budget is constrained, discuss scope and risk deliberately. You may be able to reduce the number of features, supported environments, or delivery phases. Do not quietly leave out important verification while continuing to promise the same outcome.

The estimate is also a conversation about responsibilities. Specify what the client must provide, which accounts they control, who approves release, and what happens when required access or feedback arrives late. Delays can consume coordination time even when implementation is finished.

10. Use completed projects to improve the next estimate

Track time by a small set of categories that match your estimate: planning, implementation, testing, review, release, and maintenance. The categories are useful because they let you compare like with like, not because every minute needs an elaborate label.

At project close, compare estimated and actual hours. Ask which activities were missed, which were genuinely unexpected, and which expanded because the scope changed. Check the effective hourly rate using the complete delivery time, including work you absorbed without a separate invoice.

If three similar projects each needed more review time than expected, that is a reason to change the next estimate. It is stronger evidence than adopting a universal QA percentage from a generic pricing article. Build a small record of your own projects, with enough context to explain why they differed.

Common questions

Should QA always appear as a separate charge?

No. It can be included in a clearly scoped fixed fee or billed as agreed delivery time. The important part is that the estimate and fee account for the work and the client understands the arrangement.

What percentage should I add for testing?

There is no universal percentage established by this guide. Estimate the relevant workflows and risks, then compare actual results. In our example, ten testing hours happen to equal 25% of implementation time.

Does a maintenance retainer include new features?

Only if your agreed service includes them. Define the covered activities, available capacity, response expectations, and process for larger requests.

Does the calculator price QA automatically?

No. It estimates a financial hourly floor from your inputs. You use that floor with your own complete delivery estimate. The optional PDF report does not replace technical scoping or a maintenance agreement.

Continue with how to calculate your freelance rate from an income goal for the full financial model behind your hourly floor.