An SME owner asks their IT vendor "how much will this cost?" and gets "it depends." That's how every misunderstanding starts, and every one of them ends badly for both sides. It's not about price — it's about a billing model each side reads differently.
There are three models that actually work in this business: fixed price (a set price for a scope), T&M (paying for hours actually worked) and retainer (a monthly fee including a defined pool of hours). Each fits a different type of work, and picking the wrong one gets expensive — even when the vendor's hourly rate is low.
Fixed price — pay for the scope
The client hears "fixed price" and feels relief. "I know what I'll pay." The vendor hears "fixed price" and thinks: "I need to pad this because anything that changes, I pay for out of my own pocket." The result: the quote is more expensive, and every small change during the project ends with an awkward "contract amendment" conversation.
Fixed price works well when the scope is genuinely closed and everyone reads it the same way. Deploying a standard module in an off-the-shelf system — yes. Building a "new customer portal with a few features, we'll agree the details" — no, however attractive the price looks.
At one of our clients, a 25-person distribution company, a "fixed price" integration between Comarch Optima and a courier system was bought for PLN 42,000. During implementation it turned out that some orders go to three different couriers, some require cash on delivery, some pallets have non-standard dimensions. Each of these was "out of scope." After three amendments the price grew to PLN 71,000 and the project took 5 months instead of the planned 6 weeks. The client felt cheated. The vendor felt they were losing money anyway. Both sides were right, because the billing model didn't fit the nature of the work.
- The scope must be written down — no "we'll figure it out."
- The Definition of Done in writing too.
- Change requests priced separately, up front — e.g. "PLN 500 net for each additional document in the integration."
- Penalties for their delays, but also a fair "stop the clock" when the client doesn't deliver materials.
Time & Materials — pay for real work
T&M means billing for hours or days actually worked, at an agreed rate. Clients fear this model because "we don't know what it'll cost." In reality, it's the most honest model — as long as both sides play fair.
T&M fits perfectly for work with a fuzzy scope, for R&D, for modernising old systems (where you don't know what you'll find in the code until you look), and for integrations with systems whose documentation is incomplete. It's exploratory work — and exploratory work can't be honestly quoted up front.
To stop T&M from becoming a bottomless pit, you need hard rules. A weekly report of hours — with what was done and why. A monthly or milestone budget as an alarm signal — not a hard cap, but a moment where you sit down and talk "how much is left and what do we change." And most importantly: the right to stop the project at any time, without penalties.
In one project an 18-person metal components manufacturer moved into T&M for modernising their quote-generation system. The initial plan called for 250 hours. After 120 hours we realised the problem was different from what was originally diagnosed — and instead of finishing the original plan, we redirected the remaining hours to a completely different module. Under fixed price this would have meant renegotiation, two amendments and weeks lost to discussions.
Retainer — monthly subscription
A retainer is a fixed monthly amount that includes a defined pool of vendor hours (e.g. 20 hours a month), plus usually an SLA for minor fixes. Overtime billed at T&M rates; unused hours don't necessarily carry over.
This model fits when you already have a deployed system and want "someone on the other end" to polish, add small features, fix bugs, help with staffing changes. In other words — after the initial rollout.
A retainer doesn't work when you try to squeeze large projects into it. "We'll order 40 hours a month and in six months we'll have a new warehouse module" is a road to disappointment — nobody plans dev work that way.
- 20–40 hours a month is the amount our clients typically need for maintenance and small changes.
- Define what's "in the subscription" (small fixes, consultations) and what's "out" (new features above X hours).
- Set response times for tickets — otherwise the retainer becomes "we'll do it when we have a moment."
How to choose in an SME
There's no single right model for everything. It usually looks like this:
- Deployment with a clear scope — fixed price.
- New app, integration, migration with a fuzzy scope — T&M.
- After the rollout, ongoing maintenance and small changes — retainer.
In practice, most mature collaborations with our clients are hybrids: start on T&M until the scope stabilises, then a retainer for the maintenance phase. We use fixed price surgically — where you genuinely know what, how and why.
The worst decision you can make as an SME owner is to pick the billing model the vendor prefers. Pick the model to match the work. A vendor who can't flexibly propose a model that fits your situation is telling you indirectly how the whole engagement will go.
What to watch in the contract
Regardless of the model, a few things in an IT contract are worth watching that SMEs often overlook:
- Copyright to the code produced — who owns it, when the rights transfer (ideally after payment for the given phase).
- Source code — do you have access, or is the vendor "holding a hostage"?
- Exit clause — what happens when you want to change vendor. How long the handover takes, at what rates.
- Confidentiality — mutual, not just from you.
- Liability — a sensible cap (typically up to the value of the last 12 months of the contract), not "unlimited" and not "excluded."
If the vendor refuses to discuss any of these — that's a signal that in a crisis you'll be left alone with the problem, and they'll be left with your code.
Pick the billing model to match the nature of the work, not the vendor's preference. A vendor who doesn't get that is telling you indirectly how the whole engagement will go.