For website and software operations, a fixed monthly fee against a clearly defined scope is usually better than hourly billing for both the business and the provider: the business knows its cost in advance and does not hesitate before every call, and the provider is motivated to make the system stable so that it needs fewer hours. Hourly billing suits work whose scope cannot yet be defined (assessments, unfamiliar incidents, one-off projects); operations, however, is repetitive and measurable, and what can be measured can be priced as a fixed fee.

The problem with hourly billing in operations

Hourly sounds fairest: pay for exactly what is done. In real operations it creates three problems:

  1. Reversed incentives. The provider earns more when the system breaks more. Nobody breaks things deliberately, but nobody hurries to invest in automation that reduces their own billable hours either.
  2. The business hesitates to call. Every question is an invoice, so small issues are left until they become large ones. The hidden costs of self-hosting describes the price of leaving things.
  3. No budget predictability. A quiet month is 2 hours, an incident month is 40. Finance cannot budget, and the 40-hour month is always the month the business is already struggling.

None of this is caused by bad people; the pricing model places both sides on opposite ends of the same number.

The 4 pricing models and when each fits

1. Hourly

Pay a rate for each hour worked. Fits: initial assessments, incidents on systems not yet onboarded, one-off work of unclear scope. Does not fit continuous operations, for the three reasons above.

2. Prepaid hour blocks

Buy 10 or 20 hours a month in advance at a lower rate; unused hours expire or roll over. Improves predictability but keeps the reversed incentive and still has the business counting hours. Usually a transition step before both sides know each other well enough to set a fixed fee.

3. Fixed fee by scope

One amount a month for a written scope: monitoring, backups, updates, incident handling within a service commitment, a set allowance of small changes. Work outside scope is quoted separately. This is the best fit for operations because:

  • The business knows the full-year cost from day one.
  • The provider benefits from stability, so invests in monitoring and automation.
  • Nobody counts hours; small questions are asked early, small bugs fixed early.

For this model to be fair: the scope must be explicit, there must be a measurable service commitment, and there must be a mechanism to adjust as the system grows.

4. Outcome-based

Pay according to metrics achieved: uptime, speed, orders through the system. Attractive in theory but hard to apply, because outcomes depend on many things outside the provider's control (content, marketing, market). It usually appears as bonus and penalty clauses tied to the service commitment in model 3, rather than as a standalone model.

How to read a fixed-fee price list

A trustworthy fixed operations price list has four parts:

  1. Scope of work: itemised, without "and related tasks". What is monitored, how often backups run and how long they are kept, what is updated on what schedule, which incident severities are handled within what time.
  2. Service commitment: response and resolution times by severity, minimum uptime, and what happens when they are missed. What is an SLA explains how to read this part.
  3. Out of scope and how it is priced: new features, redesigns, infrastructure migrations. Clear rates or a clear quoting process.
  4. Adjustment terms: how the fee changes when traffic, users or the number of systems grows. Without this, one side loses after a year.

A price list missing part 1 or 2 is not a fixed fee; it is hourly billing repackaged.

What must be in an operations scope

Whatever the price, a website or software operations scope should not omit:

  • Uptime and error monitoring with alerts routed to a responder.
  • Automated backups and periodic restore tests; see backup is not enough, you must be able to restore.
  • Security updates within a committed window.
  • Scheduled platform and library updates with a staging environment.
  • Incident handling per the service commitment.
  • A monthly report with numbers.
  • A small monthly allowance of minor changes (text edits, image swaps, configuration tweaks) so the business never needs a quote for 15 minutes of work.

A scope missing one of these is usually cheaper on the price list and more expensive on the year-end invoice.

How a fixed fee is calculated

A serious provider builds a fixed fee from three components: the cost of known recurring work (monitoring, updates, reporting), an incident reserve based on the history of similar systems, and shared tooling infrastructure. That is why two systems of similar size can carry different fees: legacy code, no staging environment, or many third-party integrations all raise the reserve. It is also why the first 90 days of intake usually carry a separate fee; the 90-day onboarding playbook describes that period.

For a business website, fixed operations fees typically start from a few million dong a month; business software is higher with complexity. In-house team or outsourced compares this level with the cost of an internal hire.

6 questions for comparing two quotes

  1. Does the scope list specific tasks and frequencies?
  2. Does the service commitment have numbers and a clause for when they are missed?
  3. Are restore tests from backup in scope, and how often?
  4. How is out-of-scope work priced, and are there rates?
  5. By what rule does the fee adjust as the system grows?
  6. Which numbers are in the monthly report, and can we see a sample?

The cheaper quote that answers two or more of these vaguely is usually the more expensive one after 12 months.

How Siri9 prices

Siri9 uses the fixed fee by scope model for website maintenance and software maintenance, with a written service commitment, a monthly report with numbers, and a separate intake fee for the first 90 days. Out-of-scope work is quoted as a fixed price before it starts, never by the hour. Send us your website address or a description of the software to receive a price list structured in the four parts above.

Frequently asked questions

Is a fixed fee more expensive than hourly?

More in quiet months, far less in incident months. Over a year, with a well-operated system, total spend is usually lower because incidents decline and there is no 40-hour month.

What if we never use the full allowance?

That is a sign the system is stable, which means the model is working. A fixed fee pays for the system not breaking, like insurance plus servicing, not for hours.

Can we start hourly and move to fixed?

That is the right approach when the system has not been assessed. After 1 to 3 months both sides have enough data to set a fair scope and fixed fee.

Is outcome-based pricing ever appropriate?

As bonus and penalty clauses tied to the service commitment: missing the uptime target reduces that month's fee. As a standalone model it is rarely fair to both sides.