Choosing a Software Project Pricing Model

Time-based and fixed-price software delivery allocate uncertainty differently. Neither model guarantees a lower final cost, better quality, or a successful product. The useful question is which contract and delivery controls fit the current scope, dependencies, evidence, and ability to change direction.

Every project is different. Wavect uses time-based, fixed-price, and staged arrangements depending on what can be responsibly scoped. A staged agile fixed-price approach can be useful when early evidence should reduce uncertainty before bounded deliverables are priced.

Before choosing a model, compare its trade-offs and write the commercial controls into the agreement. This is an engineering and delivery perspective, not legal advice.

Hourly Billing

The supplier invoices measured time at agreed rates, often subject to a budget, quota, or approval threshold. Goals and priorities can be explicit even when the exact backlog remains adaptable.

• The customer pays for actual effort, so forecast accuracy, time records, rate cards, and approval rules matter.
• Without a cap or stop rule there can be less budget certainty; a rolling forecast and explicit decision points reduce surprise.
• The backlog can remain more adaptable, but changes can still affect schedule, cost, quality, and dependencies.

Fixed Price

A fixed amount is agreed for a defined deliverable or scope. The agreement should state assumptions, customer dependencies, acceptance criteria, exclusions, payment milestones, and how changes are estimated and approved.

• Price predictability depends on the defined boundary. Suppliers may price uncertainty, narrow the scope, share a risk allowance, or use change requests. No single response is automatic.
• Clear outcomes and acceptance tests create scoping overhead, but every implementation detail need not be frozen if the agreement preserves a controlled way to learn and change.
• An estimate miss creates commercial pressure, but quality does not have to decline. Definition of Done, testing, security requirements, acceptance evidence, escalation, and scope decisions should remain explicit.

For Austrian contracts, the label used by the parties is not the whole analysis. Section 1151 ABGB distinguishes a service commitment for a period from producing a work for remuneration, while the current WKO guidance describes a Werkvertrag as owing a sufficiently concrete result (RIS, ABGB Section 1151) (WKO Werkvertrag guidance). Have qualified counsel review the actual allocation of result, cooperation, acceptance, change, payment, warranty, and termination duties.

"Never compromise the Plan for presumed Speed."

Agile Fixed Price

Agile delivery does not remove planning or commercial governance. The Agile Manifesto welcomes changing requirements and values frequent delivery, while the Scrum Guide frames complex work around transparency, inspection, and adaptation (Agile Manifesto principles) (official Scrum Guide). Neither source prescribes a pricing model.

One planning pattern for larger custom software development projects uses three commercial phases. This is an illustrative Wavect delivery pattern, not a universal definition of agile fixed price.

Portability also matters. At each phase, define repository access, documentation, environments, credentials, intellectual-property terms, and a usable handover state. These controls can make a supplier transition less disruptive, but cannot promise that another team will continue without onboarding or rework.

1. Discovery Phase

Discovery should reduce the uncertainties that affect product value, feasibility, delivery risk, and pricing. Its duration and outputs depend on the project. Work can include goals such as reducing operating cost, testing an investment case, or releasing a marketable product.

Agree the discovery deliverable before work begins. It might include decisions, assumptions, risks, user journeys, architecture options, a prioritized backlog, estimates, and next-step choices. A short concept can be useful, but page count does not establish completeness or portability.

Discovery evidence is not automatically a full requirements specification or a fixed-price promise. Record what was validated, what remains uncertain, and who must decide next.

2. Test Phase

The test phase implements enough of the riskiest path to replace assumptions with evidence.

A time-based budget or capped quota can preserve flexibility while the team measures complexity, dependencies, user feedback, and delivery throughput. Define the cap, stop rule, and approval authority before starting.

Use a review cadence appropriate to the risk and delivery cycle. Report completed increments, remaining uncertainty, spend against budget, forecast, quality evidence, and decisions needed.

At the agreed decision point, review the product state and backlog. Continue time-based work, stop, rescope, or move sufficiently bounded outcomes into a finalization phase.

The deliverable is not necessarily an MVP. Define the exit state contractually, including code, tests, documentation, deployment assets, known defects, licenses, credentials, and acceptance evidence.

3. Finalization Phase

If the remaining outcomes are sufficiently bounded, they can be defined as epics, user stories, acceptance scenarios, or other testable deliverables and priced separately.

A fixed price can offer more budget predictability for that boundary when priorities, goals, dependencies, assumptions, and change control are understood.

Some uncertainties will remain. State them, assign owners, and define what happens if an assumption fails.

See also: our Fractional CTO Austria service explains how we scope senior engineering leadership. Confirm the current offer, availability, price inputs, authority, and contract terms for the actual mandate.