How US projects are priced, and what stops them running over
Most US web projects that go badly do not go badly on price. They go badly on change. The number agreed in week one is rarely the number invoiced in week twelve, and the gap is almost always a series of small reasonable requests that nobody priced as they arrived. This page sets out how we structure engagements to make that visible: when fixed scope is the right model and when it is not, how a change order works, who owns what at the end, and how payment terms and sales tax are handled.
A fixed price is only fixed if the scope is. Everything below is about making the scope specific enough that the price can hold, and making the moment it changes an explicit decision rather than a surprise on an invoice.
Fixed price contracts create an incentive nobody intends. The supplier is now financially motivated to interpret every ambiguity narrowly, and the client is motivated to interpret it broadly, so the relationship becomes a negotiation over what the words meant. Time and materials removes that tension and replaces it with a different one: the client carries the risk of an estimate that drifts, and has limited ability to see it drifting until the invoices arrive. Neither model is wrong. Choosing the wrong one for a given project is what produces the overrun.
When this work makes sense
Questions worth asking any supplier
Whether the requirements are genuinely known. Fixed scope works when the thing being built is well understood and fails when discovery is still happening, because every unknown becomes a dispute.
How much internal review the project carries. Approval chains are a schedule cost and often a real cost, since a build waiting three weeks for sign off still has to be picked back up.
Whether integrations touch systems you do not control. A third party API with poor documentation is the most common source of an estimate doubling, and it is worth pricing separately rather than absorbing.
Whether accessibility is a requirement or an aspiration. Building to a recognized standard changes design, markup, testing and timeline, and it is materially cheaper to do from the start than to retrofit.
Who owns the code and the accounts at the end. This belongs in the contract, not in a conversation after launch, and it affects the value of what you are buying.
Deliverables
A written statement of work with numbered requirements, so a change can be pointed at
An explicit exclusions list, which is the half of the scope most proposals leave out
A change order process with a stated turnaround, so a request gets priced rather than absorbed or ignored
Milestone based invoicing tied to verifiable deliverables
Net payment terms stated in the contract rather than assumed
Assignment of ownership in the code and full transfer of all accounts on final payment
A defined warranty period after launch covering defects, with what counts as a defect written down
Process
US engagements are usually split rather than run as one fixed number. Discovery is priced and delivered on its own, and it produces the specification that the build is quoted against. That sequence matters: a fixed price quoted before discovery is a guess wearing a contract, and it is the root of most overruns. After discovery you are free to take that specification elsewhere, which is deliberate. A discovery phase that only has value if you continue with the same supplier is not really a deliverable, it is a deposit.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three engagement models, and when each one is the right choice
Fixed scope
Fits: Requirements are documented and stable, and you need a number to take to finance
Limits: Every ambiguity becomes a negotiation, so it is the wrong model while discovery is still happening
Time and materials with a cap
Fits: Something important is unknown, usually an integration nobody can test in advance
Limits: You carry more of the risk, which is why it comes with a weekly burn report and a ceiling
Monthly retainer
Fits: Continuing work such as SEO, Google Business Profile management or ongoing development
Limits: Priced on hours reserved, never on rankings or traffic, because nobody controls those
Case studies
No client contract values or project costs are published here. There are no published case studies with figures attached, because we have neither permission to name the clients nor numbers any reader could independently verify. When a client agrees to be named, it will be published here.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do you work fixed price or time and materials?
Both, chosen per project rather than as a house policy. Well defined work with stable requirements is quoted fixed. Work where discovery is still happening, or where a third party system is an unknown, is better on time and materials with a cap and a weekly burn report, because a fixed price on an unknown is priced for the worst case and you pay for that risk whether it materializes or not.
How do change requests work?
Every request is priced against the numbered statement of work and comes back as a written change order with cost and schedule impact before any work starts. Nothing is absorbed quietly and nothing is done on the assumption you will agree. The overwhelming majority of overruns are a series of small unwritten yes answers, so this is the single most important mechanism on this page.
Who owns the code?
You do, on final payment, along with every account created for the project. This is written into the contract rather than left to goodwill. Any third party licenses are named separately, because those are licensed rather than owned and that distinction matters if you ever move suppliers.
What are your payment terms?
Milestone based, with net terms stated in the contract. We do not invoice against dates that have passed without the corresponding deliverable existing, which sounds obvious and is not universal.
How is sales tax handled?
Treatment depends on where your business is located and where the services are considered delivered, and it varies by state. We state the position applicable to your engagement in the contract rather than assuming one, and your own accountant should confirm it. Nothing on this page is tax advice.
Will you sign our MSA and our security questionnaire?
Usually yes, and it is better to send both before the proposal than after. Procurement requirements frequently change the scope, particularly around data handling, hosting location and access control, and discovering that after a number has been agreed is how a fixed price stops being fixed.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.