How to scope a fixed-price milestone without setting the feature up to fail

Last substantive review: August 2026.

A fixed price does not make uncertainty disappear. It decides who will carry the cost when reality differs from the plan. That can be a fair trade when a feature is understood well enough to test, the important dependencies are visible, and both sides agree how changes will be handled. It is a bad trade when the fixed number is doing the emotional work of creating certainty that the scope cannot support.

The most useful fixed-price milestone is small enough to inspect and valuable enough to release or use. It names the user or operational outcome, the included behavior, the evidence required for acceptance, and the conditions the estimate depends on. It also says what happens if an API changes, test data arrives late, a stakeholder adds a workflow, or production exposes a problem that staging could not.

This is an operating guide, not legal advice. Your signed agreement and applicable law control the commercial and intellectual-property terms.

The one-question preflight

Ask two reasonable people who were not in the sales calls to read the milestone. Could they run the same acceptance test and reach the same answer about whether the work is complete? If not, the scope is not ready for a fixed price.

That does not mean every implementation detail must be frozen. The team can retain freedom over architecture and task sequencing. What must be stable is the promised behavior, the quality threshold, the environment and data used to judge it, and the commercial path for facts that change.

Put a boundary around discovery first

Do not hide discovery inside a feature estimate and hope it stays small. Give it its own purpose, inputs, outputs, time box, and decision. For an existing product, discovery may include a repository review, reproduction of the current problem, a walkthrough of the deployment path, data-model inspection, third-party API validation, and a short product session with the person who can make scope decisions.

A discovery milestone can be fixed price if its output is the investigation and decision package, not a guarantee that every unknown will be resolved. Define the deliverables. A useful package might include a workflow map, architecture note, dependency list, risk register, test strategy, wireframes for disputed states, a delivery estimate, and a recommendation to proceed fixed price, proceed hourly, or stop.

State the boundary. For example: discovery includes read-only inspection of the application repository and staging environment, interviews with the product and engineering owners, and validation of the payment provider's sandbox. It excludes production changes, a penetration test, a full data migration rehearsal, and remediation of defects found during inspection. That sentence prevents the discovery phase from quietly becoming unpaid implementation.

The milestone sheet should fit on a few pages

A milestone does not need a long statement of work, but it does need complete fields. Put the commercial summary near the front and link detailed test cases or designs as versioned attachments.

Use stable versions for the documents that define scope. If an acceptance criterion points to a design file that changes every day, nobody knows which interface was priced. Record the approved design version or attach an export. Name who can approve a replacement.

Write acceptance criteria as tests, not aspirations

An acceptance criterion should let someone observe an input, action, and result under stated conditions. Consider a marketplace refund workflow. An aspiration says the admin can issue refunds easily. A testable criterion says: given a captured order in the payment-provider sandbox, an authorized support admin can submit a full refund from the order screen; the application records the provider refund identifier, changes the order state to Refunded after confirmed provider success, and shows a retryable error without changing state when the provider rejects the request.

Add the test environment and data. If performance matters, name the volume, measurement point, tooling, and percentile. Do not copy a latency number from another product. If browser or device support matters, list it. If a workflow has role boundaries, specify the permitted and denied roles. If a migration changes stored data, define counts, reconciliation checks, and how a failed migration is rolled back.

Feature acceptance criteria are not the same as a team's general Definition of Done. The official Scrum Guide describes the Definition of Done as the shared quality state required for an increment. Your organization might require code review, automated checks, deployment to staging, documentation, and no unresolved critical defects for every feature. Acceptance criteria then describe what this particular refund workflow must do. Put both in the milestone.

Use published standards where the requirement needs a shared yardstick. The OWASP Application Security Verification Standard can provide contract-ready verification requirements for web application controls. The W3C's Web Content Accessibility Guidelines 2.2 provides testable accessibility success criteria. Select the applicable requirements and version explicitly; do not promise broad compliance with a name alone.

Make assumptions visible and dependencies owned

An assumption is a fact used in the estimate that may not yet be verified. A dependency is something the work needs from a person or system. They are related but require different treatment.

Write assumptions so they can fail cleanly. Examples: the current API supports idempotent refund requests; the existing order model can represent partial refunds without a schema rewrite; designs cover desktop and mobile error states; historical orders do not need to use the new flow. For each assumption, state how and when it will be checked. If an unverified assumption can change the price materially, validate it during discovery or take that work out of the fixed scope.

Give each dependency an owner and need-by date. API credentials by client security, final copy by product, hardware revision by the device vendor, production window by operations, and legal approval by the client's counsel are clearer than client will provide required materials. Also state the consequence of delay: milestone dates move day for day, the team switches to another approved item, or the work pauses and is rescheduled.

Use a risk register as a commercial tool

The risk register should not be a graveyard of generic concerns. For each meaningful risk, record the condition, likelihood, impact, owner, mitigation, trigger, and what happens commercially if it occurs.

The point is not to transfer every risk to the vendor. It is to prevent a surprise from becoming an argument about memory. Some risks belong with the builder, some with the client, and some with a third party neither side controls.

Change control should preserve product judgment

Fixed price should not make a team pretend that learning is failure. The principles behind the Agile Manifesto welcome changing requirements and treat working software as the main measure of progress. A commercial agreement can respect that principle while still requiring an explicit route for changes.

Use a lightweight written flow. Record the request and the reason. Let the delivery lead assess effects on acceptance criteria, architecture, dependencies, testing, timing, and price. Give the authorized client owner a small set of options: swap work of comparable effort out of the milestone, approve added price or time, defer the request to a later milestone, or reject it. Then update the versioned scope before work proceeds.

Do not let chat messages become invisible contract amendments. A developer can explore an idea without committing to deliver it. A product owner can clarify wording without triggering a change. The decision record should say whether the request is a clarification, correction of a covered defect, or scope change and why.

Tie payment triggers to evidence

There is no universal payment split that makes a milestone fair. The right triggers follow the work's cash needs and the buyer's ability to inspect progress. A bounded milestone might invoice at authorization, at approval of a staging evidence package, and at production handoff. A separate discovery milestone may be paid at kickoff and delivery of its agreed artifacts. Avoid arbitrary equal payments if the underlying effort is not equal.

Define who can accept the work, the review window, the evidence supplied, and how issues are classified. The evidence package could include a staging URL, test results, release notes, screenshots or recordings of non-visual workflows, migration output, and a list of known limitations. If the approver reports a failure, tie it to an acceptance criterion with reproduction steps. The contract should explain how disputed items are handled and whether undisputed portions can be accepted and invoiced.

Be careful with deemed acceptance by silence. It may be useful in some contracts, but it can also turn a delayed stakeholder response into a relationship problem. Have counsel draft the legal mechanism. Operationally, use reminders, an escalation contact, and a scheduled acceptance session so the work is reviewed while the delivery context is fresh.

Scope QA and release as work

QA is not the period after development when somebody clicks around. Name the test responsibilities inside the estimate: unit and integration coverage for changed logic, regression around affected workflows, role and permission tests, browser or device matrix, data reconciliation, accessibility checks, security verification, performance testing under defined conditions, and user acceptance.

The NIST Secure Software Development Framework is useful here because it treats security practices as part of the software development lifecycle and gives acquirers and suppliers shared language. For a milestone, that can translate into explicit requirements for threat review, dependency handling, code review, secrets, vulnerability remediation, and retained evidence. Pick what fits the risk; a marketing-site change and a payment flow should not carry the same verification burden.

Release criteria deserve their own checklist. State who schedules production, who has deployment access, what database or configuration changes run, which dashboards and alerts will be watched, how long the observation window lasts, and what triggers rollback. For third-party or hardware-dependent features, include the people needed to diagnose a failure. A release is not complete merely because code merged.

Make the six-month warranty testable

Horizon Labs offers a six-month code warranty on product-team work. The signed statement of work controls the exact terms. In the milestone, identify when the warranty begins, the code and environments it covers, how a defect is reported, the evidence needed to reproduce it, severity handling, and how a fix is delivered.

A warranty should distinguish a defect from new scope. A defect is generally behavior in the delivered code that fails an agreed acceptance criterion or documented requirement under the covered conditions. A new workflow, changed business rule, newly required browser, third-party API change, customer modification, or infrastructure incident may need a separate estimate. Those are common examples, not a substitute for the language in the signed agreement.

Keep the handoff usable during the warranty. If nobody retains logs, test data, release identifiers, or access to the affected environment, triage becomes guesswork. Name the support route and the people authorized to approve production changes.

Do not leave IP and handoff to implication

Code ownership is not established by paying an invoice and downloading a repository. In the United States, copyright ownership and work-made-for-hire rules are specific; the U.S. Copyright Office's text of Title 17, Chapter 2 is a useful primary reference, but your counsel should draft and review the assignment, license, and third-party component terms for your situation.

Operationally, list what the client receives: application and infrastructure repositories, commit history, build and deployment configuration, environment inventory, dependency and license list, design source files, API documentation, database migration files, test suites, runbooks, dashboards, account ownership, and an open-issues register. Transfer secrets through an approved secure process and rotate them where appropriate; do not put credentials in the handoff document.

State when transfer occurs and what can be withheld, if anything, for unpaid invoices. Identify pre-existing vendor tools, open-source components, commercial services, fonts, models, or datasets that are licensed rather than assigned. For a deeper contract checklist, read Horizon's guide to code ownership and IP assignment.

When hourly work is safer

Use hourly or capped time-and-materials work when the buyer needs learning more than a fixed deliverable. Common signals include an inherited codebase that has not been inspected, incident response, intermittent device faults, research-heavy AI behavior, undocumented integrations, a third-party approval process with uncertain timing, changing product priorities, or a data migration whose quality is unknown.

Hourly does not mean unmanaged. Set a weekly capacity, priority owner, spend ceiling, evidence cadence, and stop/go checkpoint. A senior specialist can investigate until the team can define the next milestone responsibly. A useful hybrid is a capped diagnostic followed by a fixed feature build, with a decision package at the boundary.

Do not force a senior embedded, IoT, AI, or platform engineer into a fixed-price promise before the failure mode is understood. The vendor will either price the uncertainty, narrow the warranty, or lose money and fight about scope. None of those outcomes helps the roadmap.

A worked milestone: marketplace refund controls

Imagine an established marketplace needs authorized support staff to issue full refunds without opening the payment provider's dashboard. The milestone objective is to let the support team refund an eligible captured order from the internal admin tool while keeping the marketplace order state reconciled with the provider.

Included behavior: permission check, full-refund action, confirmation step, idempotent provider request, pending and confirmed states, audit record, customer-facing status update, and a retry path for a recoverable provider failure. Exclusions: partial refunds, multi-currency adjustments, chargeback handling, refund-policy changes, historical data repair, and replacement of the existing admin authentication system.

Assumptions: the provider API supports the required refund and idempotency behavior; the current order model can store the provider refund identifier and pending state; the client supplies sandbox and production credentials through its approved access process; the product owner approves copy and error states before development starts.

Acceptance evidence: test results for authorized and unauthorized roles; a successful sandbox refund with recorded provider ID; duplicate submission producing no duplicate refund; a rejected provider response leaving the order unrefunded and showing the approved message; an audit record with actor, order, time, request, and result; regression results for order display and existing support actions; a production release plan and rollback decision.

Payment triggers can follow approval of the scope and access, acceptance of the staging evidence package, and production handoff after the observation window. A provider behavior outside the documented and tested assumptions goes through the change path. A defect against the accepted flow enters the six-month warranty process under the signed terms.

This example is specific enough to estimate because it constrains actors, states, provider behavior, exclusions, evidence, and decisions. It still leaves the engineering team room to choose the internal design.

How Horizon Labs scopes the two delivery lanes

The Horizon product-team lane, normally priced at $100–120 per hour, combines full-stack engineering, QA, launch support, and a six-month code warranty. Once discovery has reduced uncertainty, a bounded feature or product micro-service can be contracted as a fixed milestone with a clear total, acceptance package, and handoff.

The $150–200 per hour senior-specialist lane is a better fit for inherited systems, urgent backlog work, embedded or IoT debugging, production AI, risky integrations, and platform problems. Those engagements often begin hourly or with a cap because the first valuable output is a diagnosis. Fixed price becomes safer after the team can reproduce the problem and see the dependencies.

Fixed, hourly, and outcome-based structures solve different risk problems. Horizon's outcome-based pricing guide explains when a measurable business result can support another model.

If you have a feature in proposal form, contact Horizon Labs with the current requirement, affected systems, desired release window, and unresolved assumptions. We can help decide whether it is ready for a fixed milestone or needs a short diagnostic first.

Sources used

• Principles behind the Agile Manifesto
• The official Scrum Guide
• NIST SP 800-218: Secure Software Development Framework
• OWASP Application Security Verification Standard
• W3C Web Content Accessibility Guidelines 2.2
• U.S. Copyright Office: Copyright ownership and transfer

Frequently asked questions

What belongs in a fixed-price milestone scope?

A fixed-price milestone should name the objective, included user journeys, deliverables, acceptance criteria, quality bar, assumptions, dependencies, exclusions, change process, acceptance and payment triggers, release plan, warranty boundary, and handoff. Each dependency needs an owner, and each acceptance criterion needs a test method and expected result.

How are acceptance criteria different from the Definition of Done?

Acceptance criteria describe the behavior required from a specific feature, including the conditions and evidence used to test it. The Definition of Done is the shared quality standard applied to every increment, such as review, testing, documentation, and staging requirements. A strong milestone includes both.

What does Horizon Labs' six-month code warranty cover?

Horizon Labs offers a six-month code warranty on product-team work, with the signed statement of work controlling the exact coverage. The milestone should define covered code and environments, the warranty start, defect reporting, reproduction evidence, severity handling, and how fixes are released.

When is hourly work safer than fixed price?

Hourly or capped work is safer when the first task is learning: inspecting an inherited codebase, reproducing an intermittent failure, validating an uncertain API, investigating data quality, doing research-heavy AI or embedded work, or responding to changing priorities. A capped diagnostic can create the evidence needed for a later fixed milestone.

Who owns the code from a fixed-price feature build?

The signed agreement should state ownership, assignment, licenses, third-party components, and the timing of transfer; payment alone should not be treated as the ownership rule. Have counsel review the language for the applicable jurisdiction, and pair it with an operational handoff list covering repositories, deployment assets, documentation, tests, accounts, and open issues.