Re-prioritisation
Something matters more than something else, and both were already in scope. Absorbed without a conversation about money, because the outcome agreed has not changed.
Agile delivery on a fixed price: how both can be true
Buyers are often told they must choose: a fixed price with no flexibility, or agile delivery with an open-ended bill. That is a false choice, and understanding why it is false is the difference between a predictable project and a disputed one.
- ✓Price fixed against a completed design, not against a brief
- ✓Delivery runs in sprints inside that fixed scope
- ✓Re-prioritising within the agreed outcome is absorbed
- ✓New scope is a conversation before the work, not after
100+Products delivered this way
$1.5B+Client revenue generated
2013Refining the process since
100%In-house delivery team
Why the two look incompatible
Fixed price assumes the scope is known. Agile assumes it is not, and that discovering it as you go produces a better product. Put crudely, one prices certainty and the other prices adaptability, which is why providers tend to offer one or the other and buyers tend to feel they are picking a risk rather than an approach.
The contradiction dissolves once you notice that the two answer different questions, and that they apply at different times.
Fix the scope after design, not before it
The reason fixed-price projects go wrong is almost never the fixed price. It is fixing a price against a brief rather than against a design. A brief describes intent and cannot be counted. A completed design can be.
PixelForce completes a paid Product Design Blueprint first, then issues a fixed-cost, fixed-scope Statement of Work against it. Within that scope, delivery runs in sprints - sequencing, detail and day-to-day decisions stay adaptive. What is fixed is the commercial commitment and the outcome. What flexes is the path.
What happens when requirements change
Two different things get called scope change, and conflating them is where disputes start.
Genuinely new scope
A new integration, a new audience, a capability nobody had considered. A commercial conversation - and one held explicitly before the work starts, rather than surfacing in an invoice afterwards.
What to ask before you sign anything
These four questions separate a predictable engagement from a disputed one, whoever you are buying from.
Is this price against a completed design, or a brief?
The most important question, and the one that predicts whether the number will hold. A price against a brief is an estimate wearing a decimal point.
What specifically counts as new scope?
If the answer is vague at signing, it will be contested during delivery. Ask for the distinction in writing, in the Statement of Work.
How often will I see working software?
Sprint cadence is the honest measure of whether delivery is genuinely iterative. A status report describing percentage completion reports on the plan, not the product.
Who absorbs an overrun?
The question that reveals what you are actually buying. By the hour, it lands on you. Against a brief, it is argued as scope. Priced after design, it lands on the provider.
Comparing a fixed price against an hourly quote? We will show you what each one is really committing to.
Book a discovery callOne conversation.
Three phases.
Built to grow.
The same canonical PixelForce engagement model behind 100+ shipped products and $1.5B+ in combined client revenue, applied to your app. The 1-3-1 method runs through every conversation - one problem, three options with honest trade-offs across budget, timeline and scope, one recommendation. No Blueprint, no Build.
-
0Free
Discovery call
A free, no-obligation conversation to find the right path for your app before you commit a dollar.
- Mutual NDA signed up front
- 1-3-1 method: one problem, three options, one recommendation
- Honest trade-offs across budget, timeline and scope
- A straight answer on what a credible build looks like
-
14-8 weeks
Scoping & Design
Everything you need to build with total confidence - a fully costed, designed plan with no scope surprises.
- Strategic workshops and BRD
- Full UX/UI design system, every screen built
- PRD and a fixed-cost Statement of Work
- No Blueprint, no Build - Phase 1 before any Phase 2 quote
-
23-6 months
Development, QA and Release
From approved designs to your live app, built and tested at a steady sprint cadence.
- Sprint cadence with regular demos
- QA across iOS, Android and the edge cases
- End-to-end App Store and Google Play submission
- Built to scale from 1,000 to 1,000,000 users
-
3Ongoing
Post Launch Support
We do not disappear at launch - monitoring, warranty, and an optional retainer keep your app growing.
- 24/7 monitoring and a critical-defect warranty
- Ongoing technical support
- Optional Product Retainer: four-week sprints and quarterly reviews
- The model that grew SWEAT to a $400M platform
Frequently asked questions
The questions buyers and search engines ask most about this stage.
Yes, provided the price is fixed against a completed design rather than against a brief. A brief describes intent and cannot be counted; a completed design can. Once scope is defined that precisely, delivery inside it can run in sprints, with sequencing and day-to-day decisions staying adaptive. What is fixed is the commercial commitment and the agreed outcome. What flexes is the path taken to reach it.
Waterfall completes each stage before starting the next and assumes requirements are known up front. Agile delivers in short iterations and assumes requirements will be refined as real software gets built and reviewed. Most competent custom software delivery is a hybrid in practice: design and scope resolved deliberately at the start, then iterative delivery within that scope. Pure waterfall struggles with discovery; pure agile without a defined scope struggles to give a client a number they can budget against.
It depends on the kind of change. Re-prioritising between things already in scope is absorbed, because the agreed outcome has not moved. Genuinely new scope - a new integration, a new audience, a capability nobody had considered - is a commercial conversation, and a good provider raises it before doing the work rather than presenting it in an invoice afterwards. The distinction should be stated explicitly in the Statement of Work.
This is the question that reveals what you are actually buying. On an hourly engagement it lands on you, by the hour. On an estimate against a brief it is usually argued as a question of scope. At PixelForce the price is set after the design is complete, so an overrun that is not new scope is ours to absorb - which is the point of doing design before pricing rather than after it.
Delivery runs in sprints with a set communication cadence covering progress, challenges and opportunities, including the things you would rather not hear. Working software reviewed regularly is the only reliable measure of progress; a status report describing percentage completion is not, because it reports on the plan rather than on the product. Clients on a product retainer also get quarterly business reviews.
Where this sits in the journey
The step before and the step after, or the full picture on our process.
Previous step
Choosing a tech stack
The other decision made during design, and the one buyers over-weight.
Fix the outcome. Stay flexible on the path.
No obligation, and no scope you cannot afford. You leave the first call with one recommendation and the reasoning behind it - even when that recommendation is not us.