It depends on whether you can describe the work
Can you write down what “done” looks like? If yes, fixed scope usually fits. If the work is an ongoing flow of small requests nobody can predict a month ahead, a retainer may suit better. If nobody knows the answer yet, as in a technical investigation, time and materials with a cap is the honest option.
The three models
With fixed scope and a fixed price, a written scope says what gets built and the price covers it. If the work takes longer than planned, the team absorbs that. New requests are priced separately.
With a retainer, you pay a set amount each month for agreed time or capacity, and the team works on your priorities. Terms vary: a block of hours, a dedicated person, or simply availability.
With time and materials, you pay for hours or days actually worked, usually against a rate card and often with a monthly cap.
Where fixed scope works well
It works when the result can be described: a first product version, a customer portal, an integration between two systems, a rebuild.
It helps when someone needs a fixed number to approve. Many Indian businesses need one for a partner, a board, a bank or a purchase order, and an open monthly figure is harder to sign off.
It makes vendors comparable. Quotes against the same scope can be compared side by side. Hourly rates can’t, because teams need different hours.
And both sides know when the work is finished.
Fixed scope’s risks, and fixes
| Risk | How to handle it |
|---|---|
| Rigid when you learn something mid-build | A clear change process: new requests get quoted and you decide |
| Teams price in uncertainty | The clearer the scope, the less uncertainty to price |
| Arguments over what’s included | A detailed scope with an out-of-scope list (what a scope should contain) |
| Corners cut under time pressure | Agreed checks for each feature, and working software shown along the way |
Where a retainer works well
A live product that needs frequent small changes, fixes and tweaks is the classic case. So is a business that needs ongoing development capacity without a full-time hire, or a complex system that benefits from the same people staying close to it. Retainers also suit arrangements where responsiveness matters more than a list of outputs, such as someone on hand for a system your operations depend on.
A retainer’s risks, and fixes
| Risk | How to handle it |
|---|---|
| Unclear output | A monthly list of completed work |
| Paying in quiet months | Agree whether unused time carries over |
| Small tasks polished beyond their value | Written priorities at the start of each month |
| Big projects slipping in without a scope | Pull large items out and scope them separately |
| Hard to leave | A clear notice period, with code, repository access and credentials in your hands throughout |
Time and materials
This suits exploratory work where the answer isn’t known yet: a proof of concept, a performance investigation, an unexplained bug. It’s flexible, but your cost depends on the team’s efficiency. Set a cap and ask for regular reporting of hours against tasks.
Side by side
| Fixed scope | Retainer | Time and materials | |
|---|---|---|---|
| You pay for | A defined result | Monthly time or capacity | Hours worked |
| Cost certainty | High for the agreed scope | Predictable per month; output varies | Low unless capped |
| Flexibility | Changes quoted one at a time | High within the time bought | High |
| Best for | Defined projects and phases | Steady, unpredictable small work | Exploratory work |
| Main risk for you | Gaps in the scope | Low productivity | Cost running over |
Combining them over time
A common path looks like this. The first version gets a fixed scope. After users give feedback, the next set of features gets its own scope and quote. Individual changes in between are priced one at a time. A retainer comes in only if small work becomes steady and predictable enough to justify one.
Before we quote a fixed price, we ask what the exceptions are. The normal path is usually easy to describe in a sentence or two; it is the cases a business handles differently that decide how much there is to build.