Fixed price or hourly rate for customisations?

When you have a customisation built for Business Central, the price can be agreed as a fixed amount or charged by usage. Both can be sensible, but they suit different tasks. This article explains when each model works best, what a fixed price requires of the specification, and which questions you should ask whoever gives the quote. It applies whichever supplier you use.

Fixed price

With a fixed price you know the price in advance, if the task is clearly defined. It suits tasks where you know what you want: a report, a new field with a rule, a defined integration.

The risk sits with the supplier, but only as long as the specification holds. If requirements change along the way, an addition typically follows. So the specification is the most important thing.

Ask also what a fixed price includes in project management and testing. If you have to test yourselves, write how many hours that is expected to take on your side and who does it.

If the specification is loose, a fixed-price quote will either be expensive, because the supplier prices in the uncertainty, or turn into change requests along the way. The specification is therefore your best negotiating tool. The more precise it is, the more comparable the quotes become.

Hourly rate

With an hourly rate you pay for the usage there is. It suits tasks where the scope is unclear: analysis, troubleshooting, exploring possible solutions or customisations that develop along the way.

The risk sits with you. Ask for an estimate, a cap and ongoing reporting of hours used, so you can stop in time.

Ask for a week-by-week report and an agreed point at which you assess whether the work continues. That gives control without requiring a complete specification first.

Ask also whether the hourly rate is the same for all roles. Consultants, developers and project managers can have different rates, and the mix determines the average price.

What a good specification should contain

Let someone who did not write the specification read it and ask questions. If they are in doubt, the supplier will be too.

Whichever model, a customisation should be described in writing before work begins. Check that the specification contains:

Purpose: which problem is solved, and for whom
What is included and what is not
How it should work, preferably with examples and screenshots
Which data and integrations it touches
Acceptance criteria: how you decide it has been delivered
Who tests, and when
What changes along the way cost

Questions that reveal differences

Ask whether the fixed-price work covers testing, documentation and fixing errors after delivery, and for how long. Ask also who owns the code and how updates are handled. Microsoft updates Business Central twice a year, and a customisation must keep working after the updates. See the article on customisation or standard.

Ask what happens if the task turns out to be larger. Who pays, and how is it agreed?

Ask also whether the price includes training the users and a walkthrough when the customisation is delivered. A customisation that nobody knows how to use does not create value.

A middle way

Many choose a fixed price for a defined analysis or a first step and then a fixed price or hourly rate for the rest. By then the specification has become more precise before the big decision is taken.

It can also help to divide the task into phases with approval in between. Payment can follow the phases, so you do not pay for everything up front.

At Addverk

Our services and prices are on the page about services and prices, where the pricing is open. Use the checklist above to compare.