How to Structure Payments With a Software Development Agency (Without Getting Burned)

Money leaves your account every month, invoices keep arriving, and yet there is nothing you can confidently point to and say, "This is what we paid for, and it is ready to ship." This is a common failure pattern buyers need to avoid when hiring a software development agency.

The problem is not always the agency's price or technical ability. In many cases, the issue is how the engagement is organized. The contract may be based on hours when the buyer actually needs defined outcomes. Or it may use a single project price before the scope is understood well enough to produce a reliable estimate.

A better approach is to structure payments around accepted, testable deliverables.

This isn't a criticism of time and materials billing or fixed-price contracts. Both can work when they match the shape of the project. The buyer's responsibility is to understand what triggers payment, what happens when the scope changes, and what they will have at the end of the engagement.

One structure that can provide this clarity is milestone billing. But simply calling something "milestone billing" is not enough. The milestones need written acceptance criteria, predetermined prices, clear scope boundaries, and a real exit point.

Why Payment Structure, Not Price, Is What Gets Buyers Burned

When a software project goes wrong, buyers often look back at the quote and think they paid too much. Sometimes that is true. But the more useful question is how the contract connected payment to the actual work.

Consider two mismatches.

The first is evolving work billed as though the scope were fixed. A startup may still be testing its product assumptions, changing requirements, or discovering technical constraints. Yet the contract expects the agency to commit to a complete project price from day one.

The second is defined work billed as open-ended hours. If the buyer already knows what needs to be built, but the agency can continue billing without meaningful delivery checkpoints, the buyer carries much of the cost risk.

In both cases, the payment structure is poorly matched to the work.

A buyer-protective contract makes the connection between money and progress clear. You should know what is being delivered, how acceptance is determined, how much that work costs, and what happens when the original scope changes.

The Three Ways Agencies Bill, and Where Each One Breaks

How a software agency charges for its work can impact the overall financial risk of a project. There are three types of payment: time and materials, fixed-price and milestone billing. It is not a right or wrong answer; the only question is whether the payment is commensurate with the way the work will be scoped, delivered, and accepted.

Time and Materials: Honest for Evolving Work, Dangerous Without Guardrails

Time and materials billing isn't necessarily a bad deal.

When the roadmap is genuinely dynamic, it can be the right fit. Product teams may need to change priorities as they learn more about users, uncover technical constraints, or change the direction of the product. In those situations, trying to define every future deliverable in advance can create a less practical contract than an hourly or retainer arrangement.

The problem is T&M without guardrails.

If there is no limit on the number of hours the buyer can spend, no regular way to report progress, and no tangible milestones to measure, spending can continue without a clear connection between the hours worked and the value delivered.

The important question is not simply whether the agency charges by the hour. It is whether the buyer has enough visibility and control over that spending.

Ask yourself: "What keeps spending under control, and how do I know what I am getting for the hours I am paying for?"

T&M can work as a continuous engagement, but the buyer should still have clear reporting, spending limits, and visibility into how the budget is being used.

Fixed Price for the Whole Project: Why It Invites Padding and Change-Order Fights

A fixed project price can be tempting because the buyer knows the expected cost before development begins.

The problem is that software projects often contain uncertainty that cannot be completely removed on day one.

An agency may include contingency in its estimate to protect itself from that uncertainty. The buyer takes on the cost of that contingency whether or not the risk eventually materializes. Once development begins, the buyer may also discover that some requirements or details were not fully understood during the original scoping process.

That is where change-order fights begin.

The buyer may see a request as a reasonable adjustment to the original product. The agency may see the same request as work outside the agreed scope. Both sides can have a defensible position because the contract required them to define the complete scope before development had actually started.

The issue is not that fixed-price contracts are always wrong. A genuinely fixed and testable piece of work can be priced that way. The problem comes when an uncertain, evolving project is forced into a single fixed number.

Milestone-Based Billing: Paying for Delivered, Accepted Work

Milestone-based billing changes the payment trigger.

Instead of paying because a certain number of hours have been logged or because another month has passed, the buyer pays for a defined milestone after the agreed acceptance criteria have been met.

A real milestone should have:

• A defined deliverable
• Written acceptance criteria
• A price established before development begins
• A clear scope boundary
• A payment trigger based on client acceptance

Although the hours spent completing the milestone might be important for the agency's estimation, hours do not affect payability of the invoice.

This is an important distinction to make. The buyer is not buying an invoice that is designated "Milestone 2". It is a specific piece of accepted work that the buyer is buying.

What a Buyer-Protective Milestone Structure Actually Requires

Not all the contracts that are called milestone contracts are really buyer-friendly.

Label is not the bottom line, it's the mechanics.

Firstly, acceptance criteria must be put in place prior to development. Both sides should understand what needs to be done for the milestone to be deemed successful.

Second, the cost should be determined prior to undertaking the work. A milestone should not be a new opportunity for negotiating the price once the agency has begun work on the project.

Third, billing should be tied to sign-off. The event that triggers payment should be acceptance of the agreed deliverable, not simply the passage of time or the number of hours worked.

Fourth, scope changes should be treated as new work. If the buyer wants something outside the original milestone, it should be defined and priced separately. The contract should also clearly explain what happens if the buyer decides to stop the project.

There should be a clear boundary where the buyer can exit and retain everything delivered up to that point.

These are the mechanics that make milestone billing useful. Without them, "milestone" can simply become another name for a recurring invoice.

Why a Scoping Phase Has to Come Before the First Milestone Is Priced

You cannot price a milestone honestly if you have not understood what the milestone contains.

A product idea must be clearly specified for the development team and buyer to agree upon the work. This might include the identification of epics, stories, technical requirements, dependencies, and acceptance criteria.

Otherwise, the milestone plan is just a guess wearing a schedule.

A short paid discovery phase can solve this problem. Instead of pretending the entire project is known from the first conversation, the agency first does the work required to understand what should be built and how it should be broken down.

Leanware uses this approach through Sprint 0. Leanware Sprint 0 is a fixed-fee scoping phase priced at $5,000 to $15,000 and typically runs for two to four weeks. It ends with a go/no-go decision before the first development milestone is billed.

For a buyer, the value of this phase is not simply another deliverable. It is the information needed to make the subsequent payment structure more honest.

What a Milestone Payment Schedule Looks Like in Practice

If you are wondering what a milestone payment is, it is a payment made when a specific project milestone is completed and accepted. A practical milestone payment schedule usually starts with the scoping phase and then moves into a sequence of defined development milestones.

For instance, a project must have a scoping phase followed by different development stages. Each milestone should clearly state what will be delivered and what is required for acceptance. It should also specify the payment amount due after the client signs off.

Milestones may be scheduled roughly twice a month, depending on the size and shape of the work.

The important point is that this is not a universal template. A serious milestone payment schedule should come from the scoping work rather than being copied from another project.

That distinction matters. A two-week milestone may work well for one project but not for another. The schedule should match the actual deliverables, dependencies, and acceptance criteria.

For a worked example of how this type of engagement can be structured, see the Leanware engagement models guide.

The Five Questions to Ask Any Agency Before You Sign

Before signing a software contract, don’t just accept a general billing explanation. Ask the agency to clearly explain how billing works.

Start with the most basic question: Exactly when does payment trigger? Is it when hours are logged, when the calendar reaches the end of the month, when a milestone is delivered, or when the buyer accepts the milestone against written criteria?

Next, ask: What happens mechanically when scope changes? You should know if new work will be a separate milestone, increase the budget, or be billed as extra hours. If you leave the project early, the contract should clearly state what you keep. Then, make sure the contract explains who pays for any extra costs.

If the agency underestimated a defined milestone, does the buyer automatically pay more? The contract should make that risk explicit.

Finally: Who actually wrote the estimate, and what was it based on? If a project estimate was created before anyone properly scoped the work, ask how the agency arrived at the number.

An agency that can answer these questions clearly before signing is giving you useful information about how the engagement will operate.

How to Structure the Exit So You're Never Trapped Mid-Build

Exit terms deserve more attention than they usually receive.

A contract can contain a "termination for convenience" clause and still leave the buyer with an unclear outcome. The key question is not simply whether you are allowed to terminate. It is what happens when you do.

A practical exit structure creates a defined boundary at a completed milestone.

If the buyer stops after a milestone, they should receive everything completed and accepted up to that point, including source code, infrastructure setup, and documentation.

There should not be a separate hand-off negotiation where the agency decides what it will release or what additional payment is required just to obtain materials already covered by completed work.

The contract should also make clear whether there is a termination penalty.

This is one reason milestone boundaries can be useful. They give both sides a concrete stopping point. The buyer should not have to keep going or leave the project without clear ownership of the work already completed.

Where Leanware Fits: A Working Example of This Structure, Not a Pitch

Leanware provides a useful example of the structure described above.

Its milestone-based approach begins with Sprint 0, which produces the information needed to create the priced milestone plan. Development is then divided into milestones with criteria established before the work begins.

The payment trigger is client sign-off against those criteria. If the scope changes, the additional work becomes a priced milestone rather than silently expanding an existing one.

The exit mechanism also matters. A buyer can leave at a milestone boundary while retaining the code, infrastructure configuration, and documentation delivered through that point.

That is the important part of the example. The model is not simply "pay every time we finish something." It connects scope, acceptance, payment, and exit.

Leanware also works with monthly-retainer engagements when a roadmap is genuinely evolving. That is an important distinction because the goal is not to declare one billing model universally superior.

The right structure depends on the work. Learn how Leanware structures its engagements in the Leanware engagement models guide. It covers milestone-based and monthly-retainer models.

Matching the Payment Structure to the Shape of the Work

There is no single payment model that works for every software project. If the scope is clear and fixed, a fixed-price model may work well.

If the project is likely to change, time-and-materials billing gives the team more flexibility.

The buyer should still insist on appropriate controls around spending and progress.

If the work can be broken into clearly defined deliverables with objective acceptance criteria, milestone billing can connect payment directly to delivered and accepted work.

The buyer's job is not to choose a billing model because the name sounds safer. It is to examine the mechanics behind it.

Ask what causes payment. Ask what happens when requirements change. Ask who carries the risk of an estimate being wrong. Ask what you receive if the engagement ends.

Those answers tell you more than whether the proposal says "fixed price," "T&M," or "milestone."

To better understand the different ways software development projects can be priced, explore Leanware’s Software development pricing models guide.

Final Thoughts

The protection is not in the name of the billing model.

It comes from the mechanics behind it: written acceptance criteria, payment triggered by sign-off, separately priced scope changes, and a real exit point where the buyer keeps what has already been delivered.

Before signing with a software development agency, look at the payment structure as closely as you look at the technical proposal.

The right questions can expose financial risk before the first invoice arrives. If you are planning a software build, you can talk with the Leanware team about your project.

Frequently Asked Questions

What actually distinguishes real milestone billing from relabeled invoices?

Real milestones are tied to clear deliverables. Each milestone has a set price, acceptance criteria, and sign-off. An agency simply relabeling its monthly invoices as "milestones" without these elements has not created a meaningful milestone structure.

Is time-and-materials billing a red flag?

No. It can work well when the scope may change. The key is having spending limits, progress checks, and clear reporting.

What should happen when scope changes mid-project?

Under a properly structured milestone model, the additional scope should be defined and priced as new work. The buyer should agree to the new milestone before development begins.

This is clearer than allowing an existing fixed-price milestone to expand informally or letting a loose T&M arrangement continue accumulating hours without a defined financial boundary.

What am I entitled to keep if I exit early?

The contract should say that you keep everything delivered and accepted up to the last completed milestone. This can include code, documentation, and infrastructure setup.

Why is a paid discovery phase a good sign, not a red flag?

A paid discovery phase can be a positive sign because accurate milestone pricing requires an accurate understanding of the work.

A short scoping phase gives the agency and buyer time to define requirements, break the work into meaningful pieces, and establish acceptance criteria. The result is a milestone plan based on actual understanding rather than an early guess.