Motta Industries Blog

Most website support decisions are made in a hurry. A form stops sending, a plugin update breaks the checkout, or a warning appears in the browser, and the owner calls whoever can help fastest. That is break-fix support: paying for help when something goes wrong. The alternative is a website support retainer, where a provider is paid in advance for ongoing care and a defined level of availability.

Neither model is automatically better. A brochure site that changes twice a year has different needs from a bakery taking online orders every morning. The useful question is which model matches how much the business depends on its website, how often it changes, and who will notice when something quietly stops working.

This guide compares the two approaches, explains what ongoing care actually involves, and lists what to put in writing before choosing either.

What each model actually buys

Break-fix support buys expertise on demand. The business pays for time when a problem appears, usually with no ongoing commitment. It can suit sites that rarely change, have few moving parts, and would not lose much revenue during a short outage.

A retainer buys continuity. The provider typically handles agreed routine tasks, such as updates, backups, and monitoring, and commits to responding within defined times. Many retainers include a bank of hours for small changes. The business pays whether or not anything breaks, in exchange for predictability and a provider who already knows the site.

Hybrid arrangements are common too. A business might pay a modest monthly fee for updates and backups, then pay separately for larger changes or incidents. What matters is not the label, but the specific tasks, response commitments, and exclusions.

The routine work does not disappear under break-fix

Choosing break-fix support does not remove maintenance tasks. It moves them to the owner, or leaves them undone. Someone still needs to apply updates, confirm backups work, renew services, and notice problems.

NIST’s February 2024 Cybersecurity Framework 2.0 Small Business Quick-Start Guide is useful here. Among its suggested actions, it encourages businesses to regularly update and patch software, enable automatic updates to help, and regularly back up data and test those backups. It also suggests creating and maintaining an inventory of hardware, software, systems, and services. The guide is voluntary and written for whole businesses, not just websites, but those habits apply directly to a website’s plugins, hosting, domains, and integrations.

The guide also describes itself as a possible discussion prompt with whomever a business has chosen to help reduce cybersecurity risk, such as a managed security service provider. That is a sensible way to use it in a support conversation: as a checklist of questions, not as a certification.

Consider a fictional bakery with online pre-orders. Under break-fix, the owner may not notice that backups stopped running months ago until the day they are needed. Under a retainer, a provider should be checking that routinely. Either way, the work exists. The decision is about who does it, how reliably, and at what cost.

Keep the inventory current as part of the arrangement. A support provider cannot maintain what nobody has listed. Record the domain registrar, hosting account, content management system, plugins, payment and booking integrations, email delivery service, and any scheduled tasks. Note who owns each account and when each paid service renews. That single document makes both models work better, and it shortens any handover.

Updates need judgment, not just a switch

Automatic updates help, but they are not the whole answer. WordPress’s July 2020 developer note on auto-update controls explained that WordPress itself was configured by default to update automatically for minor versions, and that version 5.5 introduced a dashboard interface for plugin and theme auto-updates, which were disabled by default and required site owners to opt in.

That history is a reminder that update behavior depends on configuration, and it can differ between core software, plugins, and themes. Settings can also change with later versions, hosting platforms, and individual site setups, so check what is enabled on your own site rather than assuming. An e-commerce plugin that updates automatically overnight might also change checkout behavior before anyone has tested it.

A good support arrangement, whichever model you choose, should explain which components update automatically, which are reviewed first, how updates are tested, and how a problematic update is rolled back. Ask how the provider would handle an update that breaks a critical feature during business hours.

Decide who notices problems first

Many website failures are quiet. A contact form stops delivering messages, a payment integration rejects some cards, or a scheduled job stops running. Customers may simply leave without saying anything, and the owner discovers the problem weeks later.

Under break-fix support, the owner is usually the monitoring system. That can work if someone checks key functions regularly: submitting a test inquiry, placing a test order where practical, and confirming that notification emails still arrive. Under a retainer, ask exactly what the provider monitors, how often, and how alerts reach a person who can act.

Monitoring is only useful when someone owns the alert. Agree who receives notifications, who is the backup when that person is away, and how quickly the business expects a first response.

Planning for incidents before they happen

The difference between support models becomes obvious during an incident. With a retainer, the business already has a contact, an agreed response time, and a provider with access and context. With break-fix, the owner may spend the first hours finding someone available, granting access, and explaining how the site works.

CISA’s Spring 2021 Cyber Essentials Starter Kit encourages organizations to plan for incidents as they would for a fire, to employ backup solutions, to enable automatic updates where possible, and to test and deploy patches quickly. It frames many actions as items to discuss with IT staff or service providers, which fits small businesses that rely on outside help.

The NIST guide makes a related point: understand what your incident response plan is and who has authority and responsibility for implementing different parts of it. For a website, that means knowing who can take the site offline, who contacts the hosting company, who communicates with customers, and who decides when the problem is resolved.

Write those answers down regardless of the support model. Break-fix can work reasonably well when the owner has a clear plan, current backups, and a trusted provider identified in advance. It works poorly when the plan is improvised during the outage.

Compare costs honestly

Retainers are often judged by asking whether the business “used” its hours. That misses part of the value. A retainer also pays for prevention, availability, and a provider who already understands the site. Those benefits are real but hard to see in a month when nothing breaks.

Break-fix often looks cheaper until something serious happens. Emergency work, unfamiliar code, and missing backups can make a single incident expensive. Lost orders and staff time matter too.

A simple comparison can help, as long as it uses your own numbers. Estimate how many routine maintenance hours the site needs each year, how many incidents are plausible, how long each might take to resolve with and without prior familiarity, and what an hour of downtime costs the business. Compare that rough total with retainer proposals. The result is a planning estimate, not a prediction, but it makes the trade-off visible.

Consider budget predictability as well. Some businesses value a stable monthly cost; others prefer paying only when needed and accept occasional larger bills.

Put the arrangement in writing

Vague support agreements cause most of the disappointment on both sides. Whichever model you choose, write down the essentials.

Define the scope. Which sites, plugins, integrations, and hosting accounts are covered? Which tasks happen routinely, and how often? What counts as a change request rather than maintenance?

Define response. What response time applies to an urgent problem, and what counts as urgent? Distinguish between acknowledging a report and resolving it. Clarify business hours, weekends, and holidays.

Define access and ownership. The business should control its own domain, hosting, and administrator accounts, granting the provider appropriate access rather than handing over ownership. The NIST guide suggests assessing risks posed by suppliers and third parties before entering formal relationships, which includes understanding what access a provider will hold.

Define reporting and exit. Ask what the provider will report each month, how unused hours are handled, and what happens when the arrangement ends. A clean handover, including documentation and removal of access, protects the business if it changes providers later.

Questions that reveal fit

When comparing providers or deciding between models, a few questions are especially revealing.

How do you know backups work, and when were they last tested? Which updates do you apply automatically, and which do you review first? What happens if an update breaks the site during business hours? Who will actually work on our site, and what do they need to know about it? How will we know what you did this month? What is excluded?

Clear, specific answers suggest a provider who has thought about ongoing care. Vague assurances about “keeping everything secure” suggest the opposite. No arrangement removes all risk, and a responsible provider will say so before any agreement is signed or any work begins on the site.

Motta Industries explains its approach on its why choose Motta Industries page, and the full range of support and development work is listed on the services page. Use questions like those above when comparing any provider, including Motta Industries.

Choosing the right model for now

A practical rule of thumb: the more revenue, bookings, or customer contact flows through the website, and the more often it changes, the stronger the case for planned, ongoing support. Simple sites with little change and low dependence can often manage with break-fix help, provided someone owns the routine tasks and a trusted provider is identified before trouble starts.

Revisit the decision as the business grows. A site that begins as a brochure may later add online ordering, appointment booking, or customer accounts, and the support model should change with it.

Watch for signs that the current arrangement no longer fits. Repeated emergencies, updates postponed because nobody has time, uncertainty about whether backups exist, or staff working around broken features all suggest the site needs more planned attention. In the other direction, a retainer that consistently goes unused for routine work and small changes may be larger than the site requires, and a lighter arrangement could be more sensible.

If you are weighing a website support retainer against paying for help as needed, contact Motta Industries to talk through how your site is used, what it depends on, and which arrangement would give your business the right balance of cost, reliability, and peace of mind.