Fixed Price vs. Hourly Custom Software Development

Fixed price is not automatically safer than hourly billing, and hourly billing is not automatically more honest. The safer model is the one that matches how well the work is understood and makes scope, uncertainty, approval, evidence, and stopping rules visible.

A fixed price can protect a stable, testable release. It can also hide contingency, reduced scope, or a change-order strategy. Hourly billing can adapt to evidence. It can also become open-ended when there is no estimate, cap, reporting, or decision boundary.

What fixed price actually means

The provider agrees to deliver a defined scope for an agreed total. If the work takes more effort than expected without a scope change, the provider generally bears that labor risk. If the client requests different or additional behavior, the price and schedule may change.

Fixed price does not make the scope fixed by magic. It depends on written requirements, assumptions, exclusions, acceptance criteria, client responsibilities, and a change process. A one-line promise to "build a CRM for $20,000" is not controlled merely because the total is printed.

What hourly software development means

The client pays an agreed rate for verified time worked. Priorities can change without renegotiating the entire contract, and technical learning can influence the next task.

Pure hourly billing places more effort risk on the buyer. It needs an initial estimate or range, time reporting, regular demonstrations, budget alerts, approval limits, and the ability to pause before the budget is exhausted.

What capped-hourly billing means

Capped-hourly billing charges for time actually used up to an approved maximum for a defined scope. If the provider finishes below the estimate, the buyer pays less. If the agreed work takes longer, the written terms determine who absorbs the extra hours.

At Vertinus, project work is billed at $49.99 per hour for time actually worked, up to the approved estimate. If the agreed scope takes longer, Vertinus absorbs those extra hours. Client-requested additions are estimated and approved separately.

This is a hybrid: the buyer sees the hourly basis and receives a ceiling for the approved scope.

When fixed price works well

Fixed price is a good candidate when:

• The users, roles, records, workflow, and exceptions are documented.
• The provider has inspected representative data.
• Integration documentation and access are available.
• The interface can use a known component system or approved designs.
• Migration volume and quality are understood.
• Security, performance, and compliance requirements are explicit.
• Acceptance can be demonstrated through named scenarios.
• The client can make decisions and supply materials on schedule.

Examples include a defined form-and-approval workflow, a known export, a small reporting tool over clean data, or a second phase repeating an architecture already proven in the first.

When fixed price becomes expensive or brittle

A responsible provider prices uncertainty. If the source data has not been inspected, the external API is unreliable, or users disagree about the workflow, the fixed total may include significant contingency.

An irresponsible provider may instead omit the uncertainty, win with a low price, and recover margin through changes. The resulting conflict sounds like this: the client believes a behavior was implied, while the provider says it was never written.

Fixed-price work is also brittle when the business needs to test a solution and change direction. A contract that rewards strict delivery of the original feature list can punish useful learning.

When hourly billing works well

Hourly billing fits:

• Technical investigations and difficult defects.
• Legacy systems with incomplete documentation.
• Uncertain or poorly supported integrations.
• Iterative products using real customer feedback.
• Data cleanup whose exceptions must be discovered.
• Ongoing improvements with changing priorities.
• Work in which the client wants to trade features inside one budget.

The model works only if progress remains inspectable. The client should see completed slices, time by task, remaining estimate, decisions, and risks often enough to change course.

When hourly billing becomes dangerous

Be cautious when a provider refuses to estimate because "software is unpredictable." Exact totals may be impossible, but experienced developers can still define the current assumptions, likely range, first milestone, and point at which they will reassess.

Other risks include vague time entries, large teams appearing without approval, no budget alerts, repeated rewrites, weak acceptance criteria, and invoices arriving long after the buyer could have paused.

A discovery-first model can separate uncertainty

When the project cannot be responsibly priced, buy a small investigation before the large build. The phase might inspect the workflow, data, integration, architecture, security constraints, and representative interface.

The result should be a go, change, buy, or stop decision plus usable deliverables. Discovery is not valuable merely because meetings occurred.

After discovery, stable implementation work can use a fixed or capped estimate. Remaining exploratory items can stay hourly with their own budget.

Milestone pricing is not a separate risk model

A milestone describes when payment occurs. The work behind it can still be fixed price, hourly, or capped. Ask what happens if a milestone takes more time, is partly accepted, or changes because of new evidence.

A milestone should name a complete outcome such as "approved purchase request moves through manager review and produces an accounting-ready export." Percent-complete statements are weak payment evidence.

Compare cost, not only the rate

A $200 hourly specialist who needs 40 hours costs less than a $60 provider who needs 160 hours. A $15,000 fixed proposal can be more expensive than a capped-hourly estimate that finishes at $11,000. A cheap build can also create expensive licensing or maintenance.

Normalize:

• Included release and deferred work.
• Estimated hours, rates, caps, and contingency.
• Team roles and management overhead.
• Data, integration, testing, deployment, and training.
• Third-party subscriptions and infrastructure.
• Ownership and handoff.
• Defect correction, support, and maintenance.
• Change and cancellation terms.

The guide on why custom software quotes differ provides a more detailed proposal-normalization checklist.

Example: a $5,000 first release

At $49.99 per hour, a $5,000 budget represents roughly 100 hours. Suppose the goal is a job tracker with customer records, assignments, statuses, notes, filters, and a basic administration area.

A fixed-price proposal needs every required status, role, field, exception, import, notification, and acceptance scenario defined. A capped-hourly proposal can define the complete first workflow and allow some field or interface decisions to emerge while protecting the approved ceiling.

An uncapped hourly arrangement may still be appropriate if the real task is investigating a failing legacy tracker, but it should begin with a small diagnostic limit rather than the entire budget.

See what a $5,000 custom software budget can build for additional scope examples.

Questions to ask before choosing

• Which assumptions make this price or estimate valid?
• What evidence was inspected before pricing?
• What is included, optional, deferred, and excluded?
• How are hours recorded and reported?
• What alerts occur before a cap or milestone is reached?
• Who pays when the provider underestimates agreed work?
• What counts as a scope change?
• Can the client reorder work within the same budget?
• What can be used if the project stops early?
• When does ownership transfer?

Choose the model that makes uncertainty visible

Do not choose fixed price because it sounds certain when the project is not. Do not choose hourly because documentation feels inconvenient. Match the contract to the evidence available today, then reduce uncertainty in small, useful stages.