Pricing custom software for clients: fixed scope, change requests, and protecting your margin
Software projects lose money in the gap between what was sold and what gets built. Price in phases, write down what is out of scope, and agree how changes are handled before work starts.
On this page
Agencies that are confident pricing a brand identity or a campaign often find software harder. The same client who accepts a fixed price for a logo expects a fixed price for a platform, but software has far more unknowns, and they tend to appear after the contract is signed.
The goal is not to avoid fixed prices. Clients like them, and they are often the easiest way to sell. The goal is to make sure the fixed price covers a fixed, written scope, and that everything else has a clear path.
Price in two phases
Split every non-trivial software project into a short paid discovery phase and a build phase.
Discovery (often one to three weeks) produces the user flows, the list of screens, the integrations, the data each part needs, and the risks. It has its own fixed price and its own deliverable, so the client gets value even if they stop there.
Build is priced from the discovery output, not from the original brief. Your quote is now based on facts rather than guesses, and the client sees exactly what the price includes.
Clients sometimes resist paying for discovery. Explain it as the step that makes the build price reliable, for them as much as for you.
Write down what is not included
A scope document that lists only what is included invites assumptions. Add a section called “Not included in this phase” and be specific:
- Native mobile apps (the web app works on mobile browsers).
- Integrations other than the ones named.
- Data migration from the old system.
- Content entry, translations, and photography.
- Ongoing hosting, support, and maintenance after launch.
Each of these is a common source of “I thought that was included”. Listing them turns a future dispute into a future sale.
Agree how changes work before the first one arrives
Changes are normal. Clients learn by seeing the product. The problem is not change, but change without a process. Put this in the contract:
- Every change request is written down, even if it starts in a call.
- Your team estimates its cost and impact on the timeline within an agreed number of working days.
- The client approves it in writing before work starts.
- Small changes can be swapped for scope of similar size that has not been built yet, at no extra cost, if both sides agree.
The swap rule is often what keeps relationships good: the client gets flexibility, and your margin stays intact.
Build buffer into the price, not into the timeline
Every software estimate carries uncertainty. Rather than padding every task, add an explicit contingency to the price for the risks you identified in discovery, and keep the timeline honest. Clients accept a contingency line when it is linked to named risks, such as an unfamiliar third-party API or a data migration whose quality is unknown.
Plan for life after launch
Launch is not the end of the costs. Hosting, monitoring, security updates, bug fixes, and small improvements continue for as long as the product runs. Offer a monthly support plan with a defined number of hours and a response time. It gives the client peace of mind and gives your agency recurring revenue instead of a one-off project.
Your engineering partner’s role
If you work with a white-label engineering partner, involve them in discovery and pricing, not only in delivery. They should give you estimates you can rely on, flag risks before you quote, and price their own work in phases that match yours. Your margin is protected only if the estimates under your quote are realistic.
Our agency menu shows starting prices for fixed-scope builds, and a Product Execution Audit gives you a written scope to quote from before you commit to a client.