The three white-label pricing models agencies use are project, sprint, and retainer: project fits closed scope with a defined end, sprint fits iterative delivery inside a fixed window, and retainer fits ongoing capacity when priorities shift week to week. Each model moves risk differently between your agency and the development partner. The sections below cover when to pick each one, where teams get burned, and how ZICUA quotes project and sprint work with closed scope.
Picking the wrong model does not only change the invoice shape. It changes who absorbs change requests, how fast you can start, and whether your account team can commit dates without hedging every sentence.
Project-based pricing
Project pricing works when the deliverable is knowable up front: a marketing site with a fixed template count, a redesign with approved designs, or a build that maps cleanly from a complete Figma file. You sell a fixed fee to your client, you buy a fixed scope from the partner, and everyone plans around a single end date. This is the default model for campaign microsites and brochure rebuilds where discovery already happened.
The risk is scope creep dressed up as small favors. “Can we add one more template?” sounds trivial until it lands on the same critical path as launch. Project pricing only stays healthy when the scope boundary is written down—page and component inventory, integrations in or out, content entry responsibilities—and when changes go through a written change order instead of a Slack emoji. On our side, white-label web development projects are quoted that way: closed scope first, then a number.
Project pricing pairs cleanly with a disciplined design file. If the handoff is incomplete, the fixed quote becomes a guess. That is why we treat the white-label Figma to WordPress process as part of pricing hygiene, not a separate craft concern.
Sprint-based pricing
Sprint pricing fits work that is real but not fully specified: phased launches, iterative landing systems, or product-like sections where the backlog will evolve after kickoff. You buy a fixed window of capacity—typically one or two weeks—with a committed set of outcomes agreed before the sprint starts. Priorities can be reordered between sprints without renegotiating the whole engagement.
The failure mode is a vague backlog. If nothing is ranked, the sprint burns on debates instead of delivery, and both sides leave the retro frustrated. Sprint pricing works when someone on your team owns the priority order and accepts that cutting scope is how a sprint ends green—not how it fails. It also requires honest feedback loops: a mid-sprint check beats a big reveal at the end.
For agencies, sprints are also a staffing shock absorber. Instead of hiring for a spike you cannot forecast, you convert pipeline volatility into a scheduling decision. When spikes become the normal state rather than the exception, the comparison in when your agency hits a development wall becomes the more relevant planning conversation.
Retainer-based pricing
Retainer pricing buys standing capacity: a block of reserved partner hours or delivery points each month for ongoing needs—support tickets, campaign pages, component extensions, QA passes. It suits agencies with continuous overflow who want a known response path instead of re-kickoff every time work appears.
Risks here are organizational, not technical. Unused capacity creates tension if rollover rules are fuzzy; overused capacity creates silent debt if the retainer has no ceiling. A retainer needs a clear definition of what counts as billable work, what response times you can actually expect, and what happens in months when the queue is light. Without those terms, the relationship degrades into negotiation by mood.
Retainers also change behavior on your side: they reward feeding the partner consistent work instead of hoarding emergency tasks for internal staff who are already underwater.
Side-by-side: project vs sprint vs retainer
| Model | Best when | Scope control | Main risks | How ZICUA quotes |
|---|---|---|---|---|
| Project | Deliverables and designs are fixed; launch date matters more than flexibility | Strongest: page/component inventory and exclusions are agreed before kickoff | Scope creep; change requests late in the timeline; incomplete handoffs inflate build time | Fixed fee against a closed scope document; changes move through written change orders |
| Sprint | Direction is clear but details will evolve; you want shipping cadence, not a big-bang launch | Strong per window: sprint goals are committed up front, backlog order can change after | Unranked backlog; stakeholders who treat the sprint as infinite; mid-scope swaps without cutting something else | Fixed window and committed outcomes; scope for that sprint closes before work starts |
| Retainer | Ongoing overflow, support, and campaign work with no single end date | Weaker unless defined: needs explicit hours/points, priorities, and rollover rules | Idle-capacity disputes; unbounded requests; work drifts without a product owner | Monthly reserved capacity with agreed queue priorities and clear out-of-scope handling |
How ZICUA quotes agency work
We quote projects and sprints with closed scope. Before a number exists, we align on outcomes, inputs, and edges: what designs are final, which templates and components are in, what integrations are included, who writes content, and what “done” means for QA. That gate is the same discipline as a Figma handoff checklist—if the inputs are fuzzy, the price will be fiction.
Retainers are available when the work is genuinely continuous, but we still define capacity and priority rules in writing. We do not publish invented rate cards here; pricing depends on stack, motion complexity, and how clean the upstream process is. What stays constant is the model: you always know which bucket the work sits in before anyone starts.
Two examples of scope that changes quotes, not surprises: heavy motion systems sized against the GSAP motion systems approach versus pure CSS state changes, and multi-template builds where imagery and localization are fully prepared versus blocked on client assets.
Key takeaways
- Match model to uncertainty: project for fixed outcomes, sprint for evolving detail with a fixed window, retainer for continuous capacity. Forcing the wrong model moves risk onto whoever has less leverage.
- Fixed models only stay fixed when scope is closed in writing first. ZICUA quotes projects and sprints that way; vague inputs produce revised quotes, not goodwill.
FAQ
Which white-label pricing model is cheapest for an agency?
Cheapest depends on how stable your scope is. Project pricing can look cheapest when the file and inventory are complete, then gets expensive through change orders. Sprint pricing often totals higher than a tight project but avoids renegotiation theater. Retainers cost more per hour on paper and less when you stop paying idle internal staff to context-switch across emergencies.
Can we mix models on one engagement?
Yes, sequence them. Many teams run a project for the core site, then move to sprints or a retainer for campaigns and iteration. Mixing inside a single deliverable is what causes disputes—keep one model active per workstream so invoices map to a clear definition of done.
What should a change request look like?
New page template, new integration, or a redesign of approved components after build start. Describe the delta, the schedule impact, and the fee impact in one short thread before work begins. Tiny untracked favors are how closed scope quietly becomes open scope.
Do retainers roll over unused hours?
Only if you define it up front. Decide together whether unused capacity rolls, expires, or converts to a support queue. The specific rule matters less than having one written rule both account and delivery teams can point at when the month gets busy.
How does pricing connect to the handoff quality?
Directly. Missing states, tokens, or breakpoints become build hours. Agencies that tighten design QA before kickoff usually negotiate calmer project quotes; agencies that hand off ambiguity pay for clarification in delivery time. See the Figma handoff checklist for the gate we use before estimating.