Fixed price, time and materials, or pay after acceptance

Why the contract model matters

When you buy software work, the price per hour gets most of the attention. The way the work is bought matters just as much. It decides who carries the risk when an estimate turns out wrong, what happens when you change your mind halfway through, and how much of your own time goes into managing the vendor.

There are three common models. Fixed price means one agreed sum for an agreed scope. Time and materials means you pay for the hours worked, usually every week or month. Pay after acceptance means the work is built against a signed specification and you pay once you have tested it and accepted it.

None of the three is right for every project. Each one suits a particular kind of buyer and a particular kind of work, and each one asks something different of both sides.

Fixed price

How it works

You and the vendor agree a scope, usually in a requirements document, and a single price for delivering it. Payment is often split into milestones: a portion at signing, more at agreed stages, the rest at handover. The vendor takes on the job of estimating the hours and absorbs the cost if the estimate is low.

Who it suits

Fixed price works well when the scope is small, stable and well understood. A Surat textile trader who wants a catalogue site with an enquiry form and a simple admin panel can describe the job completely in a few pages. A fixed quote gives a clear number for the budget conversation with partners or the bank.

Risks for the buyer

The vendor carries the estimating risk, so the quote usually includes a margin to cover it. On a well defined job you may pay more than the work would have cost by the hour. When the vendor's estimate turns out tight, the pressure shows up somewhere: in testing, in documentation, or in a narrow reading of the requirements. An advance at signing also means money leaves your account before you have seen any working software.

Risks for the vendor

If the scope was vaguer than it looked, the vendor works hours nobody pays for. Vendors protect themselves by writing scope tightly and charging for anything outside it, which leads to the next point.

How change requests work

Every change goes through a change request: the vendor estimates it, you approve a new price, and the timeline moves. This is fair, and it can also feel slow and adversarial when you are learning about your own product as it takes shape. A Pune founder testing an MVP with early users will want to change things every fortnight, and a fixed price contract turns each of those changes into a small negotiation.

Time and materials

How it works

You agree an hourly or daily rate and pay for the time actually spent, usually invoiced weekly or monthly. Scope is often loose and can change at any point. You direct the work, and the vendor provides people.

Who it suits

Time and materials suits buyers who have a strong product owner or technical lead of their own and work that cannot be scoped in advance. A Bengaluru SaaS team that already has engineers and needs two extra developers to work through its backlog for a few months is a good fit.

Risks for the buyer

You carry the estimating risk. If the work takes twice as long, you pay twice as much. You also pay for hours whether or not they produced something useful, so you need the time and skill to supervise the work closely. Buyers without a technical person on their side often find it hard to judge whether progress is reasonable.

Risks for the vendor

The vendor's risk is low while the client keeps paying. The main risk is relationship risk: if the client feels progress is slow, invoices get disputed and the engagement ends badly for everyone.

How change requests work

Changes are easy. You tell the team what you want next and they work on it. The cost of a change is simply the hours it takes. This flexibility is the real strength of the model, as long as someone on your side keeps an eye on the total.

Pay after acceptance

How it works

Before work starts, you and the vendor agree a written specification that says what done means, line by line, in terms you can test. The work is built in increments and reviewed with you along the way. When a piece is delivered, you test it against the specification. If it meets the specification, you accept it and pay. If it does not, it is put right before acceptance.

Who it suits

This model suits buyers who can describe what they want clearly enough to test it, or who are willing to spend time with the team to get there before the build starts. It is a good fit for MSMEs replacing spreadsheets with a system, for founders with a clear first version in mind, and for overseas teams who have been let down by offshore vendors before and want proof before payment. A Rajkot engineering firm that wants its job cards, machine allocation and late job report moved from Excel to a web system can write each of those as a testable line.

Risks for the buyer

The main cost is effort at the start. A specification good enough to accept against takes real thought, and you need to be available to review increments and test the delivered work. If your idea is still forming, writing a precise specification can feel premature. The model also depends on both sides agreeing what the specification means, so vague lines create disputes at acceptance.

Risks for the vendor

The vendor carries the most risk here: the team does the work first and is paid later. If the specification was misread, the vendor puts it right at its own cost. Vendors working this way need a careful scoping process and the discipline to say no to unclear lines before the build starts.

How change requests work

Changes are welcome, and they are written down. A new requirement becomes a new or amended line in the specification, with its own estimate of hours, agreed before it is built. This adds a little paperwork, and it keeps acceptance clear: everyone knows which version of the specification the work is tested against.

A side by side summary

• Who carries estimating risk: fixed price puts it on the vendor, time and materials on the buyer, pay after acceptance mostly on the vendor, with the hourly rate keeping the price transparent.
• When money changes hands: fixed price often starts with an advance, time and materials pays as hours are worked, pay after acceptance pays once you have tested and accepted the work.
• Effort needed from you: fixed price needs a clear scope up front, time and materials needs ongoing supervision, pay after acceptance needs a clear specification and time to test.
• Changes: fixed price handles them through priced change requests, time and materials absorbs them as hours, pay after acceptance adds them to the specification with an estimate before they are built.

The full comparison covers further factors.

How 2good.dev works

2good.dev is the delivery model of Code Colonies Private Limited. It combines an hourly rate with pay after acceptance, so you get the transparency of hourly pricing and the protection of paying only for work you have tested.

Hourly rate in 150 hour blocks

Work is priced by the hour and bought in blocks of 150 hours. The Prime tier is USD 2 or INR 199 an hour, which makes the minimum block INR 29,850 or USD 300 before tax. The Plus tier is USD 5 an hour and the Pro tier is USD 10 an hour, with INR prices on request. Taxes apply as usual, including GST for Indian clients. The tiers differ in how much senior time goes into each block; pricing sets out the details.

A signed specification

Each engagement starts with a conversation and a scoping step. Together we turn your requirements into a signed specification, or Statement of Work, that says what done means and estimates the hours. That document is the test the work has to pass.

Pay after acceptance

There is no advance. The team builds in increments and shows you progress. When a piece of work is delivered, you test it against the specification. If it meets it, you accept and pay. If it does not, it is put right first. Payment terms after acceptance are written into your agreement. Senior technical review, testing and project management are included at no extra charge.

Changes along the way

When you want something new, it is written into the specification with an estimate, and you agree it before the team starts.

Third party costs such as hosting, paid APIs, licences or app store fees are agreed in writing before work starts, so they never appear as a surprise at acceptance.

Choosing for your project

Four questions help:

• Can you describe the result clearly enough that someone outside your business could test it? If yes, fixed price or pay after acceptance will both work, and pay after acceptance keeps your money until you have seen the result.
• Do you have a technical lead who can direct a team day to day? If yes, and the work is open ended, time and materials may suit you best.
• Is your idea still forming? Then a short discovery phase, whatever the model, is worth more than a long contract signed too early.
• How much would it hurt if the vendor disappeared halfway through? The less you pay before you see working software, the smaller that risk.

Many buyers mix models over time. A London startup might start with one well defined feature on pay after acceptance to see how the team works, then move to larger blocks once trust is in place.

To apply the 2good.dev model to your project, the offer sets out the terms in one place, and pay after acceptance explains the acceptance process step by step.