fixed-price website projects: how agencies can protect margin
Fixed-price web projects lose margin when QA, content migration, integrations, and support sit outside the estimate. Use this scope checklist and worked example.
A fixed-price website project protects agency margin when the fee covers the work required to launch it. Responsive QA, content migration, integrations, approvals, and post-launch support all take time. If the proposal leaves them as assumptions, the agency absorbs the cost or renegotiates after the client expects delivery.
how do you calculate margin on a fixed-price website project?
Gross margin is the fixed project fee minus direct delivery costs, divided by the fee. Include the work that happens after the design is approved, not only the planned design and development hours.
Here is an illustrative €50,000 project model:
| Cost item | Planned amount |
|---|---|
| Design and strategy | €15,000 |
| Development | €15,000 |
| Gross profit before other delivery costs | €20,000 |
| Planned gross margin | 40% |
Suppose the team then absorbs 110 extra hours of QA, integration fixes, and launch support at an internal cost of €85 per hour. That adds €9,350 to delivery cost. Total direct cost becomes €39,350; gross profit falls to €10,650 and gross margin to 21.3%.
The €85 hourly cost and 110-hour overrun are assumptions for this example, not industry averages. Replace them with your own time and cost records. The calculation shows how quickly unpriced work changes a project’s economics.
what should a fixed-price website estimate include?
A useful estimate names the deliverable, its acceptance criteria, and who owns each decision. Define these items before the client signs:
- Pages and content: List page templates, content records to migrate, redirects, and who supplies final copy and images.
- Design and approvals: State responsive states, included review rounds, the approval owner, and what happens when approved work changes.
- Integrations: Name each form, CRM, commerce, analytics, or third-party service. Describe the expected behavior and who handles access or vendor issues.
- Testing and acceptance: Specify supported devices and browsers, functional checks, and performance measurement conditions. Google’s Web Vitals guidance recommends an LCP of 2.5 seconds or less at the 75th percentile, segmented by device. Agree whether acceptance uses lab tests, field data, or both.
- Launch and support: Define content freeze, redirects, deployment, training, warranty period, and which post-launch requests count as new work.
- Change control: Set out how a scope change is approved, priced, and scheduled before the team starts it.
These details protect both sides. The client can compare proposals on the same work. The agency can explain the cost of a new request before it becomes an unpaid launch-week task.
will a different web architecture protect project margin?
Architecture affects delivery cost, but it cannot compensate for an estimate that omits work. Reusable page types and a clear content model can make repeat builds easier to plan. A headless frontend also adds content modeling, preview, integration, and ongoing ownership work. Put those tasks in the estimate.
Choose Shopify, Squarespace, WordPress, or a custom frontend according to the catalog, editorial workflow, design needs, and integrations. A headless build makes sense when its added control solves a real requirement. It adds maintenance when the existing platform already fits.
We built Concrete as a reference site for an asset-heavy creative agency. The page documents an Astro, Storyblok, and Cloudflare build and reports mobile LCP moving from 9.1 seconds to 0.85 seconds. Concrete is our reference build, not client work; those performance figures do not establish a margin or conversion result.
Before signing, give every deliverable an owner and an acceptance check. That keeps disagreements about what is complete out of launch week.
