A monthly website plan and a one-time website project are different ways to assign cost, responsibility, and risk. Neither is automatically better.

A monthly plan can fit a contractor that wants one accountable provider for the website, hosting, routine changes, and connected marketing systems. A one-time project can fit a business with internal capacity or separate specialists ready to own hosting, maintenance, security, content, and future improvements after handoff.

The useful comparison is not “rent versus own” or “cheap versus expensive.” It is: what is delivered, who controls each asset, who performs ongoing work, what happens when priorities change, and how can the business leave without losing critical operations?

This guide compares delivery models. Current Nexxen inclusions and prices remain owned by the contractor website pricing page, so they can be reviewed without duplicating commercial terms here.

Separate the build from the operating system

A website launch is an event. Website operation continues afterward.

The initial build may include:

  • discovery and requirements;
  • information architecture;
  • content planning and writing;
  • visual design;
  • front-end and back-end development;
  • forms and integrations;
  • search metadata and crawl controls;
  • accessibility and performance work;
  • analytics configuration;
  • migration and redirects; and
  • pre-launch testing.

Ongoing operation may include:

  • hosting and domain administration;
  • software and dependency updates;
  • monitoring and incident response;
  • backups and restoration tests;
  • content and service changes;
  • form, CRM, calendar, and call-flow checks;
  • accessibility regression testing;
  • search and analytics review;
  • vendor renewals;
  • account and permission management; and
  • new campaign or service support.

A proposal can price those responsibilities together, separately, or not at all. “Website included” does not explain the operating model. “One-time project” does not guarantee that every transferable asset is delivered.

Build a responsibility matrix before comparing totals.

| Responsibility | During build | After launch | Business owner | Provider owner | Evidence | | --- | --- | --- | --- | --- | --- | | Domain registration | Confirm registrant and renewal | Renew, lock, update contacts | Named person | Named person | Registrar access | | Hosting | Select and configure | Monitor, renew, restore | Named person | Named person | Account and runbook | | Content | Approve and publish | Keep facts current | Named person | Named person | Change log | | Software | Build and test | Patch and replace dependencies | Named person | Named person | Version inventory | | Lead capture | Configure and test | Monitor delivery and failures | Named person | Named person | Test submissions | | Search | Launch controls | Monitor and improve | Named person | Named person | Search Console access | | Analytics | Define events | Validate and report | Named person | Named person | Property access |

If a row has no owner after launch, the commercial model is incomplete.

Understand the monthly managed model

In a managed monthly plan, the provider typically combines an initial website with continuing services. The exact boundaries matter more than the label.

Where a monthly plan can fit

  • The business does not have an internal website administrator.
  • Service details, team information, offers, and project evidence change regularly.
  • Hosting, forms, domain work, and integrations need one coordinating owner.
  • The business values predictable operating cost over a large initial project invoice.
  • The plan includes work the business would otherwise need to source separately.
  • Ongoing SEO, reputation, follow-up, or content activity is part of the actual operating goal.

Where a monthly plan can fail

  • “Unlimited changes” is not defined by size, queue, turnaround, or exclusions.
  • The initial website is thin because the monthly fee is treated as a substitute for discovery and content.
  • Cancellation terms leave the business without its domain, content, data, or a usable transition path.
  • Hosting and maintenance are bundled, but no one monitors forms or restores backups.
  • Every meaningful improvement becomes an unquoted add-on.
  • The business keeps paying for services it does not use.
  • The provider controls accounts that should identify the business as the registrant or owner.

The monthly fee is only predictable when the service boundary is predictable. Ask how routine work differs from a project, what the queue target means, what third-party delays can affect delivery, and how scope changes are approved.

Understand the one-time project model

In a one-time project, the business pays for a defined set of deliverables and acceptance criteria. Ongoing services may be optional, separately contracted, or transferred to the business.

Where a one-time project can fit

  • Requirements are stable enough to define and approve.
  • The business can fund the work on the project schedule.
  • Internal staff or another provider will operate the website afterward.
  • Procurement requires fixed milestones, deliverables, and acceptance.
  • The business needs a custom application or integration that cannot be responsibly treated as a standard monthly inclusion.
  • A formal handoff and independent hosting environment are important.

Where a one-time project can fail

  • The price excludes content, migration, integrations, quality assurance, or launch support that the buyer assumed were included.
  • The project ends at visual approval rather than production acceptance.
  • No maintenance owner is appointed.
  • Software becomes outdated because the business interprets “finished” as “no longer needs work.”
  • Forms, calendars, tracking, and notifications fail without monitoring.
  • The business receives files but not the knowledge, accounts, or documentation needed to operate them.
  • Future changes require re-onboarding a provider who did not build the system.

The Canadian Centre for Cyber Security recommends that small and medium organizations patch operating systems and applications, back up and encrypt data, secure outsourced services and websites, manage access, and plan for incidents. A one-time invoice does not remove those ongoing responsibilities. It changes who must own them.

Consider a hybrid model

Many sensible arrangements are hybrid:

  • a paid discovery and build project followed by managed hosting and maintenance;
  • a monthly foundation with separately scoped redesigns, integrations, or campaigns;
  • a one-time website with a limited support retainer;
  • an internal content team with external technical maintenance; or
  • a managed website that can be exported or transitioned under documented exit terms.

The hybrid model is not automatically safer. It works when handoffs are explicit. If one provider owns hosting, another owns SEO, and staff own content, specify who can change templates, redirects, analytics, forms, and DNS—and who diagnoses a failure that crosses those boundaries.

Compare total responsibility, not just total payments

The business website cost guide explains the work that shapes a website budget. For delivery-model comparison, use a responsibility-based calculation.

Monthly plan total

For the comparison period, include:

  • setup or onboarding;
  • recurring plan payments;
  • domain or vendor charges not included;
  • work outside routine-change scope;
  • premium integrations or usage fees;
  • internal approval time;
  • migration or export cost at exit; and
  • services the plan replaces.

One-time project total

Include:

  • discovery, content, design, development, and launch;
  • hosting and domain renewals;
  • maintenance and security;
  • software licences and vendor subscriptions;
  • future content and development;
  • monitoring and support;
  • internal administration;
  • incident or restoration support; and
  • the next redesign or major upgrade.

Use the same period and the same service requirements. Comparing one month of a plan with a project invoice is meaningless. Comparing a managed plan that includes follow-up and reputation work with a build-only quote is also not like-for-like.

Do not invent savings by assigning zero value to work someone still must perform.

Protect domain and account control

The business should know who is named in each important account and what rights follow from that role.

For a .ca domain, CIRA's rules distinguish the registrant associated with the registration and provide processes for transfer and changes through the registrar. For many generic top-level domains, ICANN's transfer policy is designed to provide a process for holders to move registrations between accredited registrars, subject to policy requirements and applicable locks.

The practical procurement questions are:

  • Is the correct business or authorized person the domain registrant?
  • Which email receives renewal, security, and transfer notices?
  • Who holds registrar access and multi-factor authentication?
  • Is the domain locked appropriately?
  • Who can obtain the authorization code?
  • What happens if the provider relationship ends near renewal?
  • Are DNS records documented?

Repeat the exercise for:

  • hosting and deployment;
  • source repository or export;
  • content management;
  • analytics and tag management;
  • Search Console and Bing Webmaster Tools;
  • advertising accounts;
  • CRM and customer data;
  • phone numbers and call tracking;
  • email and text-sending services;
  • calendar and chat tools;
  • image and font licences; and
  • business profiles and social accounts.

“You own the website” is too vague. Ownership, licensed use, administrative control, export rights, and provider obligations are different concepts. Put the relevant terms in the agreement.

Define what leaves with the business

A workable exit plan should exist before the agreement begins.

Ask whether the business can receive:

  • current page content in a usable format;
  • original approved images and documents;
  • an export of the site or data, where the platform supports it;
  • source code or a documented substitute, if included in the agreement;
  • domain and DNS control;
  • redirect mappings;
  • analytics and webmaster access;
  • form and CRM data the business is permitted to retain;
  • configuration documentation;
  • a list of third-party services and renewal dates; and
  • reasonable transition assistance.

Some managed platforms cannot be moved unchanged to arbitrary hosting. That is not automatically improper if it is disclosed and the exit deliverables are useful. The buyer needs to understand whether it receives a portable application, a content export, a static copy, a licensed theme, or only continued access while subscribed.

Google's hosting-change guidance notes that moving a website may require transferring files, databases, forms, images, and downloads, then testing the new environment. When URLs change, the work expands to mappings, redirects, internal links, sitemaps, Search Console, and monitoring. Portability is an operational plan, not a checkbox.

Make maintenance measurable

“Maintenance included” should name activities, triggers, and evidence.

Technical maintenance

  • dependency and platform updates;
  • security and availability monitoring;
  • backups and restoration testing;
  • certificate and domain renewal;
  • error-log review;
  • performance checks;
  • account and access review; and
  • incident escalation.

Content maintenance

  • service, area, hours, team, and contact updates;
  • legal and privacy content routing to approved reviewers;
  • project and testimonial permission checks;
  • image optimization and alternative text;
  • broken-link repair;
  • redirect maintenance; and
  • removal of expired claims or offers.

Lead-flow maintenance

  • production test enquiries;
  • notification and CRM receipt;
  • form error and confirmation checks;
  • phone and tracking-number checks;
  • calendar availability and fallback;
  • consent-language updates; and
  • third-party outage handling.

For each activity, define frequency or trigger, owner, response target, exclusions, evidence, and escalation. A provider can target a routine-change turnaround without promising that every request, outage, integration, or third-party dependency will be resolved within that time.

Compare scope with an acceptance matrix

Before signing either model, ask both providers to complete the same matrix.

| Question | Required answer | | --- | --- | | What is delivered before launch? | Named pages, content, integrations, tests, and acceptance evidence | | What continues after launch? | Specific recurring activities and frequency | | What is excluded? | Examples of out-of-scope changes and how they are quoted | | Who controls each account? | Business and provider roles | | How are requests handled? | Channel, priority, response target, and approval | | How are failures detected? | Monitoring and test process | | How is data protected? | Access, backup, restoration, and incident responsibilities | | How can the agreement end? | Notice, final billing, export, transfer, and transition | | What survives cancellation? | Domain, content, data, accounts, licences, and redirects | | How is success reviewed? | Business and technical measures without guarantees |

Reject answers that rely on “standard,” “everything,” or “full ownership” without defining the underlying work.

Choose based on operating capacity

A monthly plan may be the better fit when:

  • one provider should remain accountable for routine website operation;
  • the included ongoing services are genuinely needed;
  • internal administration is limited;
  • the service boundary and exit path are acceptable; and
  • the recurring commitment is sustainable.

A one-time project may be the better fit when:

  • the deliverable can be specified and accepted clearly;
  • the business has competent post-launch ownership;
  • independent infrastructure or custom engineering is required;
  • the handoff is complete; and
  • ongoing costs and responsibilities have been funded.

Pause the purchase when:

  • the domain registrant is unclear;
  • the proposal omits post-launch ownership;
  • the provider cannot explain cancellation or export;
  • important integrations have no test owner;
  • “unlimited” has no operational definition;
  • the low price depends on unsupported content or claims; or
  • the business is comparing different outcomes as if they were the same product.

Use Nexxen's pricing page as the commercial owner

Nexxen's monthly systems combine a contractor website foundation with different levels of ongoing operational and marketing support. The current pricing and plan comparison is the canonical source for exact prices and inclusions. This guide does not change those terms or imply that every request, integration, result, or migration is included.

Before selecting a plan, map the actual business requirements against the responsibility and exit matrices above. A useful strategy call should identify the current website, priority services, lead flow, internal capacity, required systems, and ownership concerns before recommending a delivery model.

The correct choice is the one that makes responsibility visible. Whether payments occur monthly or by milestone, the business still needs a reliable website, controlled accounts, maintainable content, tested lead paths, and a credible way to continue when the original arrangement ends.