Fixed bid, hourly or subscription: paying for software development

How you pay for software development shapes the project more than most buyers expect. The pricing model determines who carries the risk when scope changes, how much time goes to negotiation instead of building, and whether your vendor's incentives line up with yours. There are three common models, and each works well in some situations and badly in others.

We sell development on a monthly subscription, so we have an obvious interest in this topic. We have tried to describe each model fairly, including the situations where ours is the wrong choice.

Fixed bid

In a fixed-bid project, the vendor agrees to deliver a defined scope for a set price, usually paid in milestones. It is the most familiar model for buyers used to construction or traditional procurement, and it appeals because the number is known in advance.

Where it works

Fixed bid works when the scope really is fixed: a well-specified marketing website, a migration with a clear inventory, a feature with a complete design. If you can describe every screen and every rule before work starts, a fixed price is reasonable for both sides.

Where it struggles

Most software scope isn't fixed. Requirements change as people see working software, which is healthy. Under a fixed bid, every change becomes a negotiation, usually called a change order. Vendors price uncertainty into the bid, so you often pay for risk whether or not it materializes. And when the budget runs tight, the incentive is to deliver the letter of the specification rather than what you actually need.

Hourly, or time and materials

Under time and materials, you pay for the hours worked at an agreed rate, usually invoiced weekly or monthly. Scope can change freely; you pay for the work that was done.

Where it works

Hourly billing suits exploratory work, short consulting engagements, audits and situations where the volume of work is hard to predict, such as investigating a production problem. It is also common when you are adding one specific person to an in-house team.

Where it struggles

The cost risk sits entirely with the buyer. The final total is unknown, and the vendor earns more when work takes longer. Even with an honest vendor, hourly billing creates friction: buyers hesitate to ask small questions because each conversation costs money, and both sides spend time reviewing timesheets. Monthly invoices that swing widely also make budgeting difficult for finance teams.

Subscription

In a subscription model, you pay a flat monthly fee for a defined capacity of work, such as a number of requests handled in parallel. You maintain a prioritized queue, the team works through it, and you can change priorities at any time without renegotiating the contract.

Where it works

Subscriptions suit ongoing product work: building a first version and then continuing to improve it, maintaining a live application, or handling a steady stream of features for a business without its own engineering team. The cost is predictable, scope changes are a matter of reordering the queue, and the vendor's incentive is to deliver efficiently so the relationship continues.

Where it struggles

A subscription is a poor fit for a single project with a hard, fixed scope that you want delivered in one burst and then never touched again. It also asks the buyer to keep the queue filled and make decisions regularly, and capacity you don't use in a month generally isn't refunded. Because capacity rather than scope is fixed, a large project takes as long as it takes at that capacity unless you move to a larger plan.

Comparing the three

The models differ mainly in which variable is fixed and who carries the risk on the others.

• Fixed bid fixes scope and price. The vendor carries delivery risk on that scope; you carry the risk that the scope was wrong, and you pay for changes.
• Hourly fixes the rate. Scope is flexible and you carry the cost risk, because the total is unknown until the work is done.
• Subscription fixes the monthly cost and the capacity. Scope is flexible; the variable is how much gets done in a given period.

Questions to ask any vendor

Whatever the model, the same questions separate dependable vendors from risky ones.

• Who owns the code, the repositories and the cloud accounts, and from when?
• How often will I see working software, and where?
• How are scope changes handled, and what do they cost?
• What happens if I want to stop? What do I receive, and how quickly?
• Who exactly will work on my project, and will that change?
• How are bugs found after delivery handled, and for how long?

How we chose our model

We sell monthly subscriptions because most of our clients need a product that keeps improving after launch, and fixed bids tend to turn client relationships into contract negotiations. A subscription lets both sides agree on priorities each week instead. When a prospective client has a small, clearly defined project, we say so plainly and help them decide whether a subscription makes sense for its duration or whether another arrangement would serve them better.

Whichever model you choose, the protections that matter most are the same: own your code and accounts from day one, see working software often, and get the terms for changes and exits in writing before you start.